persistent diagram

https://github.com/scikit-tda/scikit-tda
Scikit-TDA is a home for Topological Data Analysis Python libraries intended for non-topologists.
はい。私のような non-topologist でも persistent diagram を簡単に作ることができました。
Mapper よりも Topology って感じです。

https://github.com/GUDHI/
The GUDHI library is a generic open source C++ library, with a Python interface, for Topological Data Analysis (TDA).
Tutorial がたくさん。こちらは触っていませんが、バーコードもかけるようですね。機能豊富です。

persistent diagram ではデータセットで対比するので、個々のデータをあてはめて予測、という使い方ができません。高次元のデータや図の比較、時系列データなどが対象になるのでしょうか。 

時系列データへの適用例です。
https://arxiv.org/abs/1803.00208 

これなら機械学習と同じ枠組みが使えます。動画での異常検知にもきっちりハマりますね。既存の手法と比較し良い方を選択するか、両方使うかでしょう。今後の動向に注目です。

 

KeplerMapper 2.0,0

Kepler Mapper を試行。
https://github.com/scikit-tda/kepler-mapper

example を動かしたのですが、そのままでは Version 違いで動きませんでした。最新版の API reference を参照し、修正したら動きました。ついでに mapper.visualize で html に。

図はできました。が、思っていたほど topology が主体ではないですね。コードを見る限り、UMAP で次元を圧縮してから DBSCAN でクラスターを作成してます。これだと機械学習分野の前処理と変わらないのですが、その後、クラスター間の線をつないで図ができています。つなぐぐか、つながないかの判断が topology なんでしょうね。

感覚的には分かったので、説明を検索。
Mapper の説明。3人目の方が話されています。
https://aip.riken.jp/video/aip-open-seminar-2/?lang=ja

Mapper
・ Extract the "shape" of complicated data.
・ Local clustering + global information
・ Generalization/"discretization" of Reeb graph.
・ Tool for exploratory (topological) data analysis.

0. prepare the data
1. Choose filter function
2. Partition (with overlap) using filter and cover
3. Perform Clustering in each partiton
4. Create Mapper graph
 Each cluster is represented by a vertex.
 Draw an edge if there's a non-empty interaction between two clusters.

上の例では UMAP が filter function に該当するのでしょう。動画ではＰＣＡが紹介されています。

Reeb graph って何だろう、と探してみたら、良い動画がありました。比較により、Mapper の特徴がよくわかります。
https://www.youtube.com/watch?v=_tiv0qYcM3U

この動画の冒頭で紹介されている文献は Kepler-mapper でも参照されています。よくわからない部分が多いのですが、動画の解説部分は理解できましたので必要に迫られるまで寝かしておきましょう。

***********************************************************
202010827追記
実際のデータ（10,000,000＊3）を入れたら、MemoryError。クラスタリングに sklearn を使っているからでしょう。実務での利用は難しいかな。

概念モデルの不確実性

「地下水モデル―実践的シミュレーションの基礎― 第2版」より

2.4 概念モデルの不確実性
・全ての概念モデルは定性的で不確かなものである。（すべての複雑性を表現できない）

・その不確実性に対して２つのアプローチがある
１．新しい情報を入手した時に、概念モデルを更新・訂正する。（進化する仮説）
２．概念モデルの代替え案を作成する。（複数作業仮説）

・好ましいモデルはモデリング過程で更新・改定されたもの。
・好ましいモデルが十分にキャリブレーションされ、不確実性解析で良い結果を与えると判断されて最終的に使用する概念モデルとして生き残る。

・実際には、プロジェクトの予算とモデリングの目的によって、アプローチにどれだけの労力を割けるかが決まる。

エンジニア

複数のエンジニアと話をする機会がありました。

感動しますね。プロは想像以上に理解が早い。私が１週間かけて理解した数式やコードを、２、３日で完全に読破されています。問題点やそのレベルの評価も一致。このような人材が揃っている会社って、素晴らしいの一言です。
話していると知らなかった知見があふれてくるようで、それも面白い。一緒に仕事をしてみたいなと思わせる方々でした。

私も、お客様にそのように思っていただいたことはあるのでしょうか？自信がないですね。
仕事内容の変化に伴い話す機会は減りましたが、できることを続けておきましょう。

V&V

お客様より V&V を記載するようお願いされていた先輩。
Verification と Validation を逆に回答されていました。

V&V は数値計算の分野で聞きます。最近読んだ図書では既に古くなった考え方ともとらえられますが、どうなんでしょう。

土木分野では、設計時に決められた手法で決められたものを作ることを繰り返すためか、暗黙的に保有する設計ツールを受け入れているように感じます。そのためか、稀に計算ソフトの Verification 不足に起因した不具合が発生していますし、ある程度は「仕方がない」と許容されている部分があるようにも感じます。照査時に V&V を要求している会社も少ないでしょう。
（照査以前の問題ですが、解析を知らない executives が解析業務を照査して見逃しを生むような危機感のない会社もありますし、適当な報告書を出している会社も散見します。V&V のような考え方に至るまで程遠いのが実情かもしれません。）

ミスをなくすためにどこまでやるか？
最終的には先日のように同じ計算を異なる手法で実施しないと駄目でしょうね。長期的経営に危機感を持つ会社、力を入れている会社の取り組みは照査内容も一味違います。

8年前の資料ですが、JAXAさんから V&V を独立した第三者で実施するためのガイドラインが出ています。
https://jaxa.repo.nii.ac.jp/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=4174&item_no=1&page_id=13&block_id=21

土木分野では、設計・施工別発注により事業全体を通し設計ミスを見逃さない仕組みはできているともいえるでしょう。さらに、施設の重要度に応じ IV＆V に似た仕組みをお客様側でも取り入れていただくことで各段階のミスを早期検出できるでしょう。
いずれも時間と費用が必要な、マネージメントとしての判断・対応になります。

 

データチェック

なぜか結果が合わない、ということで原因を探りに探ると、出発点のデータにミスが見つかりました。

決定的だったのは、データの一部に異物が混じっていたこと。日本全国、30年強のデータの中の数日分が異なっていても、なかなか気づくことはできません。

結果が合わないと気づいたのは、異なる手法で２回計算したことによります。
以前はチェックに可視化が有効でした。が、最近は可視化すら難しいデータ数になりつつあります。今のところ、チェックするには異なる手法で2回計算するしか思いつきません。計算過程のチェックだけではダメ。大量データの組み合わせなど、全ケースを想定できるほど賢い頭を持っていませんので。

時間のない中、大量のデータの加工からやり直しとなると、数年前では絶望的でした。今は何とかリカバリー可能です（たぶん）。個人的にも処理能力は数段上がったと思います。が、処理能力が上がると、それに応じて負荷がかかる状態。いつの時代も変わりません。量的な生産性向上のみではダメなのでしょうね。

もう少し、頭を使ってみましょう。

地下水の熱輸送計算 その2

1D の続きです。

 地下水の熱輸送算結果は以下の通り。50度の地下水を間隙率10％の地盤に1m/sec で注入しました。図の見方は先日と同じです。

 

 最初、100秒程度では、境界付近しか温まらない計算結果が出ました。遅すぎて驚きましたが、そういうものかもしれないと気を取り直し、100,000秒計算。でも遅い。

dtを1000秒にしていたのであまりにも飛ばしすぎたかと細かくしましたが、結果は同じ（同じなのも意外ですが）。うーん、あやしい。

段ボールに戻り、再度本探し。次に見つけたのがコチラ↓。

David E. Radcliffe「Soil Physics with HYDRUS: Modeling and Applications」

式4.56が移流拡散方程式です（ちなみに有機物量や不飽和にも対応しています）。
よく見ると、利用していた登坂「地圏水循環の数理」式8.35に比べ輸送項の係数が異なります。
どちらが正しいのか？と思いながら単位を確認すると、「Soil Physics with HYDRUS」があっていました。内部エネルギーのT-T0の部分が時間項の差分化部分と捉えると、係数は残る比熱に密度をかけて体積熱容量になっているので、全体でJ/m3/sになる必要があります。そうすると、流速に比熱を乗ずるのは納得。誤植でしょうか？というか、式見て気づけよ、私！

二重に誤っていたのが流速。実流速かと思いきや、ダルシー流速と書かれています。これはどちらの図書にも導出が記載されていませんので、あとでチェックですね。

気を取り直して再計算。

流速1m/s、間隙率100％。濃度と同じ、流体のみの計算です。境界条件も濃度と同じように時系列変化させました。

OKです。定常で均一に近くなるというのも正しかったようです。次は間隙率10％に。

熱輸送速度をみると単純に10倍にはなっていませんが、速くはなりますね。

ダルシー流速1/10とみなして0.1m/s、間隙率10％。

 

遅い気がしますね。実流速、ダルシー流速のチェックをしておかないと心底納得できないかも。 

次は2D断面。
コチラ↓の方と同様ですが、左端の流体部分は地盤を考慮して係数を修正しています。
http://penguinitis.g1.xrea.com/study/FiPy/FiPy.html

左端に断層をイメージした高透水帯を設け、下から温泉を注入。地表部（上端）の境界はこれまで同様に適当な温度勾配を設定しただけです。その他も適当なので得られた値に厳密性を期待していませんが、なんとなくイメージが湧いてきました。

 今回はココまで。地下水の熱輸送計算にFiPyを利用てみました。個人的にはHydrus 1D よりも拡張性が高いと感じています。PHREEQC の COM 版とあわせると面白そうですが、それはPHREEQC 単体の方が簡単ですね。1～2次元の計算で候補といったところでしょうか。簡単な試算か、土石流や河川、浸透流の結果を取り込んで計算する使い方が主体になりそうです。3次元なら Dtransu を修正した方が良いでしょう。

わからないところや設定方法を詰めないといけないところ（境界条件）も出てきました。あらためて調べておき、納得できる答えを出せるようにしましょう。