Para-view(or Visit)によるpolylineデータ可視化のためのXDMFファイル(.xmf)の作成(HDF5)

polylineデータ可視化のためのXDMFファイルを作成した。
以前紹介したサンプルデータよりもシンプルに書ける。vtkフォーマットと作成の労力は全く変わらないと思う。

下記では2点で構成されているline要素を4つ表示する。

<?xml version="1.0" ?>
<!DOCTYPE Xdmf SYSTEM "Xdmf.dtd" []>
<Xdmf Version="2.0">
<Domain>
	<Grid Name="Lines" Type="Uniform">

 	<Topology TopologyType="Polyline" NumberOfElements="4">
        		<DataItem Format="HDF" Dimensions="4 2">
         		test.h5:/element
	       		</DataItem>
  	</Topology>
    	<Geometry Type="XYZ">
        		<DataItem Format="HDF" Dimensions="5 3">
         		test.h5:/vertex
	       		</DataItem>
    	</Geometry>
	</Grid>
 </Domain>
</Xdmf>

xdmfファイルでは座標などのデータをxml上にべた書きするのではなく、hdf5ファイルなどの外部ファイルの設定が可能である。データの保存用にhdf5ファイルを使用し、可視化にあたりxdmfファイルを作成すれば、ほとんど手間をかけずに結果を確認することができる。もちろん以前のエントリであるようにattributeを設定すれば、スカラー、ベクトル、マトリクスの値を節点もしくは要素のそれぞれに無制限に設定することができる。

test.h5ファイル内のelementでは、各要素で使用している節点番号を下記のように記入している。
0 1
1 2
2 3
3 4

また、vertexでは、節点番号の順に節点の座標を記入している。

Text Parserのインストール

VCAD関連のソフトウェアの件でちょっとガッカリ感が否めなかった理研フリーソフト群だが、面白そうなものを見つけた。
利用者向け公開ソフト | 理化学研究所 計算科学研究機構(AICS)

ちゃんと今年も保守作業をしている。これは期待できるか。地味に便利そうなText Parserの導入をまず検討してみたい。
これは数値計算の最初の条件設定のIO処理を簡易化してくれるものらしい。
たしかにXMLの読み込みをいちいちやるのは面倒だったし、どうしたものか考えあぐねていたのでちょうどよかった。


下記のGithubから取得できる。
Text Parser by avr-aics-riken


VCADシステムは登録制にもかかわらず、申請用フォームを送信しても登録用のメールがいつまでたっても届かない困った状態になっていたが、Githubで公開とは気が利いている。


インストールも簡単だし、exampleもすごく豊富にある。これはすぐに導入できそうな気がする…!


しかも紹介用スライドまで計算工学ナビにあった。
http://www.cenav.org/kdb/wp-content/uploads/2014/07/c9eb416eeba7f98ebc4f2b6c256e52fa.pdf



おみそれしました。

2015年11月におけるAWSでのリージョン変更

アメリカで使用していたAWSインスタンスを日本で使おうと思うと、sshが非常に重くてデータの通信に相当な時間を消費する。

原因はインスタンスのリージョンをアメリカにしているからで、物理的に遠いのだから仕方ない。リージョンを東京に変更すればマシになると思われた。


しかしながら、ググってみると古い情報はすでにAWSの仕様が変わっていて使えず、新しい情報を試してみるもエラーが吐き出されインスタンスが起動しない。仕方ないのでトライアンドエラーでいろいろやっていたら、結果として非常に簡単な方法でできた。

・移動したいインスタンスを右クリックし、イメージ→イメージの作成をクリック
・少し待っていればAMIにイメージのコピーが作成されるので、それを右クリックして、コピーを選択。このときリージョンの選択が求められる。
・コピーしたリージョンに移動し、インスタンスの作成を選択。
・AMIとしてマイAMIからコピーしてきたAMIを選択。

終わり。



スナップショットを使用する方法もあるらしいが、これを使うとなぜかインスタンスが起動しない。エラー的なメッセージも出力されないので今のところ原因不明。とにかく上記の方法で対応できるのでよいことにする。

FileZillaでの同時並列転送処理

恥ずかしながら、知らなかった…。

FileZillaにてファイル転送を高速にする方法 | バシャログ。 | 横浜でWeb制作を行うシーブレインスタッフによる技術情報ブログ

しかし同時にこんな処理やると、それぞれのファイルの転送効率が落ちるのでは…?

openFOAM-2.3.1における結果出力の際の圧縮の是非

もう時代はopenFOAM-3なので、書いたところで誰も得しないが…。

controldictで出力するファイルをtar.gz形式で圧縮するか選べる。ストレージの圧縮を最低限に抑えるため使用していた。

本日、これを使うとmapfieldsなどのオプションでまともに読み込めず、間違った値が入力されることが発覚。他にも問題があったような気がするし、とにかく安全を考えるとasciiかつ圧縮無しが一番無難なよう。
しかし、同じようなことを考える人はかなり多いと思うのだが、改善されないもんだろうか?出力形式を変えたら問題なく動いたのでたぶんバグだと思うのだが…。

openFOAMでこれなので、やっぱりIO処理は難しいんだなあと再認識した。自分のコードでは、自分で頑張らずHDF5さんに全て任せようと改めて強く思う次第。

openFOAMってそこまで便利か?

タダより高いものはない。非構造格子でのメッシュ作成を必要とする実用的な問題が解きたい場合、商用ソフトのほうが絶対に良い。

使用するまでにかかる時間やメッシュ作成・修正の手間を考えると、ちょっと必要な時間のロスが大きすぎる。使い方を一通り覚えるまでの辛抱かと思っていたが、メッシュを変えるたびに計算の破綻におびえる日々はストレスがやばい。


有限体積法による非構造格子の取り扱い方自体が格好悪くてあまり好きになれないということもある。境界適合格子ならばまだ許せるが…。
理論の美しさは有限要素法の足元にも及ばないし。自作のFEMソルバーのほうが安定するような気さえする。計算時間が大きくなるのはやむを得ないとして。


openFOAMがちょうどいい問題って、メッシュが構造格子な、わりとprimitiveな問題に限られる気がする。計算手法の基礎的な研究目的にはいいかもしれないが…。