2010/6/5 1295歩 [日記・雑感]
日本人ユーザには全く関係のない話だが、OpenFOAM Forumでは有名なParaViewのトラブルに、小数点として "." 以外の記号を使う、仏、独、西などの言語環境(ロケール)で、ASCII形式のデータファイルの小数点以下の数値が悉く読み飛ばされてしまう、というものがある。OpenFOAM Forumでしばしば見かける「export LC_ALL=Cを実行しなさい」という書き込みは、このワークアラウンドである。
原因は簡単で、PV3FoamReader、vtkOpenFOAMReaderともに使用している、strtod()ほかの文字列を数値に変換する関数の動作が、プログラムの実行されるロケールの影響を受けるためだ。ただし、C/C++プログラムは実行環境のLANGやLC_*環境変数の設定によらず、デフォルトではCロケールで実行されることになっているので、今までは問題なかった。それがQt 4.5からの仕様変更で、LinuxではQCoreApplicationの初期化時に、プログラム自体のロケールが実行環境のロケールに設定されるようになり(こちらのDetailed Description末尾参照)、ParaViewをユーザがコンパイルする際にQt 4.5以降の利用が広まるに伴って問題が顕在化した。
以上の点を去年8月にParaView MLで指摘したのだが、その時はどなたの関心も引くことができなかった。それが昨日、この問題があるユーザによってMLで話題になったので、すかさず私も便乗して昨年のメールを引用して再考をお願いしたところ、今度は1時間もしないうちにフィックスがコミットされた。
OpenFOAMリーダ内でstrtod()を、ロケールの影響を受けない、例えばistreamオペレータに変更して修正するのは簡単だが(実際SourceForge版では、このワークアラウンドを入れている)、やはりそれは根本的な解決ではない。影響を受ける国のユーザには致命的に重要な問題について、その問題に関しては痛くも痒くもない国の人間がパーシステントに修正を迫るのは一見いささか妙だが、自分自身の目標とするところはあらゆるユーザのユーザ体験を向上させる事なので、当然これはやるべき事のスコープに入る。
enGrid 1.2.0リリース。
原因は簡単で、PV3FoamReader、vtkOpenFOAMReaderともに使用している、strtod()ほかの文字列を数値に変換する関数の動作が、プログラムの実行されるロケールの影響を受けるためだ。ただし、C/C++プログラムは実行環境のLANGやLC_*環境変数の設定によらず、デフォルトではCロケールで実行されることになっているので、今までは問題なかった。それがQt 4.5からの仕様変更で、LinuxではQCoreApplicationの初期化時に、プログラム自体のロケールが実行環境のロケールに設定されるようになり(こちらのDetailed Description末尾参照)、ParaViewをユーザがコンパイルする際にQt 4.5以降の利用が広まるに伴って問題が顕在化した。
以上の点を去年8月にParaView MLで指摘したのだが、その時はどなたの関心も引くことができなかった。それが昨日、この問題があるユーザによってMLで話題になったので、すかさず私も便乗して昨年のメールを引用して再考をお願いしたところ、今度は1時間もしないうちにフィックスがコミットされた。
OpenFOAMリーダ内でstrtod()を、ロケールの影響を受けない、例えばistreamオペレータに変更して修正するのは簡単だが(実際SourceForge版では、このワークアラウンドを入れている)、やはりそれは根本的な解決ではない。影響を受ける国のユーザには致命的に重要な問題について、その問題に関しては痛くも痒くもない国の人間がパーシステントに修正を迫るのは一見いささか妙だが、自分自身の目標とするところはあらゆるユーザのユーザ体験を向上させる事なので、当然これはやるべき事のスコープに入る。
enGrid 1.2.0リリース。
2010/6/2 6179歩 [日記・雑感]
今更だが、ParaView 3.8.0リリース。RC1ではパッケージングミスでディセーブルされてしまっていた、拙作のOpenFOAMリーダもちゃんと使えるようになっている。ダウンロードはこちら。
それに合わせて、CentFOAMも、ParaView 3.8.0に対応。CFD-Onlineに投稿されたアナウンスメントには、拙作のリーダの方がPV3FoamReaderよりsuperiorだから、ParaViewのプラグインは拙作のリーダのみにしてparaFoamをパッケージから外しました、とある。先日のLive DVDといい、アンオフィシャルなパッケージでは、そのようなドラスティックな判断をする例が増えてきた。
Netgen 4.9.13リリース。
特にアナウンスは出ていないが、enGridが1.2 rc4まで来ている。
それに合わせて、CentFOAMも、ParaView 3.8.0に対応。CFD-Onlineに投稿されたアナウンスメントには、拙作のリーダの方がPV3FoamReaderよりsuperiorだから、ParaViewのプラグインは拙作のリーダのみにしてparaFoamをパッケージから外しました、とある。先日のLive DVDといい、アンオフィシャルなパッケージでは、そのようなドラスティックな判断をする例が増えてきた。
Netgen 4.9.13リリース。
特にアナウンスは出ていないが、enGridが1.2 rc4まで来ている。
2010/5/24 1682歩 [日記・雑感]
VTKのポリヘドラ開発ブランチを、ついにVTKとParaViewのメインのGitレポジトリにマージしたとの連絡をデベロッパ氏から頂いた。先日も書いたとおり、OpenFOAMリーダは既にポリヘドラ対応となっているので、OpenFOAMユーザの方はGit版VTKないしParaViewをそのままビルドすれば、ポリヘドラ関連機能を試すことができる。ただし、ParaViewから使用する場合は、"Decompose Polyhedra" のチェックボックスをオフにすること。興味のある方は是非、御利用頂きたい。
OpenFOAM-extendプロジェクトからリリースされたKubuntu 10.04ベースのOpenFOAM-dev Live USB DVDを試してみた。お定まりのcd cavity; blockMesh; icoFoamとやって、paraFoamを起動したらPV3FoamReaderの代わりに拙作のOpenFOAMリーダの画面が出てきたのには驚いたが、パッケージャの方がこのようにされたということは、PV3FoamReaderより拙作の方が良いと何らかの判断をされた訳で、ともあれそのような判断をされたことを有難く思うこととしよう。惜しいのは32bit版であるところか。
OpenFOAM-extendプロジェクトからリリースされたKubuntu 10.04ベースのOpenFOAM-dev Live USB DVDを試してみた。お定まりのcd cavity; blockMesh; icoFoamとやって、paraFoamを起動したらPV3FoamReaderの代わりに拙作のOpenFOAMリーダの画面が出てきたのには驚いたが、パッケージャの方がこのようにされたということは、PV3FoamReaderより拙作の方が良いと何らかの判断をされた訳で、ともあれそのような判断をされたことを有難く思うこととしよう。惜しいのは32bit版であるところか。
2010/5/19 2447歩 [日記・雑感]
2010/4/29 4386歩 [日記・雑感]
VTKのポリヘドラ開発は進展中。以前はSliceもClipもクラッシュするだけだったのだが、最近はSliceはかなり動くようになってきた。Clipもポリヘドラをクリップする時のトポロジがまだ少々怪しいが、これも動くようになりつつある。面白いのはSliceもClipも、普通の六面体などのセルはご存知の通り切断面がtriangulate (三角形分割) されてしまうのに対し、ポリヘドラについてはちゃんと多角形として切断してくれることだ。ポリヘドラでこれが出来るなら、原理的には普通のセルでも難なく同じことが出来るはずだが、はたしてそこまでやってくれるか？
さらに、このポリヘドラ開発者氏から、私をコラボレータとして追加しました、との連絡を頂いた。なので私も、今は直接この開発レポジトリにコミット(Gitなので、正確にはpushか)させて頂ける立場にある。それ自体は大変に光栄なことだが、ただ残念なのは、私のような門外漢でも直せるようなトリビアルなバグは、ここ数日の急速な開発進展でほとんど直されてしまったことだ。とりあえずこの連休にでも、協力できることがあるか、つらつらコードを眺めながら、アルゴリズムを勉強するところから始めさせて頂こうと思う。
Salome-Meca 2010.1がリリースされている。2009.1版からの違いは、64bit版が追加されたこと、Salome 5ベースになったことだが、後は？
Code_Saturneに関してはほとんど普段ノーマークなのだが、いつの間にかこちらに専用サイトが出来ていた。Code_Saturne 2.0 rc1、Salome 5.1.3へのプラグインモジュール、webフォーラム等があるようだ。さらにそのフォーラムへの書き込みで知ったのだが、EnSight CFDのフリー版があるのだそうだ。ただし制限としては、メッシュサイズは200万セル以下であること、CEIからのサポートが無いなどの点があるとのこと。
ParaView 3.8 RC1 (リリース候補版)のバイナリがリリースされている。残念ながらOpenFOAMリーダが欠落してしまっているのだが、欠落の原因となった問題のコードは既にリリースブランチからは除去されているので、次のリリース候補版では治る筈だ。
ParaView、VTKの開発レポジトリがCVSからGitに移行した。MLでは「Gitサッパリ判らん！！」とのデベロッパ各氏の悲鳴で溢れている状態。落ち着くにはもう少し時間がかかりそうだ。
Salomeの方も、ついにGitレポジトリがこちらで公開された。
先日、Mac版は起動すらせずと書いたVisIt 2.0.0beta、その数日後にOS X 10.6用バイナリ(MPI並列版)がリリースされ、こちらはちゃんと起動してひととおり試すことができた。
さらに、このポリヘドラ開発者氏から、私をコラボレータとして追加しました、との連絡を頂いた。なので私も、今は直接この開発レポジトリにコミット(Gitなので、正確にはpushか)させて頂ける立場にある。それ自体は大変に光栄なことだが、ただ残念なのは、私のような門外漢でも直せるようなトリビアルなバグは、ここ数日の急速な開発進展でほとんど直されてしまったことだ。とりあえずこの連休にでも、協力できることがあるか、つらつらコードを眺めながら、アルゴリズムを勉強するところから始めさせて頂こうと思う。
Salome-Meca 2010.1がリリースされている。2009.1版からの違いは、64bit版が追加されたこと、Salome 5ベースになったことだが、後は？
Code_Saturneに関してはほとんど普段ノーマークなのだが、いつの間にかこちらに専用サイトが出来ていた。Code_Saturne 2.0 rc1、Salome 5.1.3へのプラグインモジュール、webフォーラム等があるようだ。さらにそのフォーラムへの書き込みで知ったのだが、EnSight CFDのフリー版があるのだそうだ。ただし制限としては、メッシュサイズは200万セル以下であること、CEIからのサポートが無いなどの点があるとのこと。
ParaView 3.8 RC1 (リリース候補版)のバイナリがリリースされている。残念ながらOpenFOAMリーダが欠落してしまっているのだが、欠落の原因となった問題のコードは既にリリースブランチからは除去されているので、次のリリース候補版では治る筈だ。
ParaView、VTKの開発レポジトリがCVSからGitに移行した。MLでは「Gitサッパリ判らん！！」とのデベロッパ各氏の悲鳴で溢れている状態。落ち着くにはもう少し時間がかかりそうだ。
Salomeの方も、ついにGitレポジトリがこちらで公開された。
先日、Mac版は起動すらせずと書いたVisIt 2.0.0beta、その数日後にOS X 10.6用バイナリ(MPI並列版)がリリースされ、こちらはちゃんと起動してひととおり試すことができた。
2010/4/15 2338歩
VisIt 2.0.0betaリリース！永久に出ないとすら思われたVisIt 2.0だが、あと一歩のところまで来ているようだ。ただ、パッケージングはまだ課題が多いようで、OS X版は起動画面すら拝めずクラッシュ、Linux版もかなりディストロを選ぶ状況。何とか頑張ってほしい。
さて、ポリヘドラVTKの件。Kitwareデベロッパの方が、前回エントリで書いたOpenFOAMリーダへの実装とOpenFOAMデータのテストケースが欲しいということで、むろん差し上げたら、リーダの方は、このコミットでGitHub上の開発版に反映して頂いた。従って現在は、GitHubからダウンロードしてくれば、OpenFOAMリーダは即ポリヘドラ対応である。
現在はまだ一般ユーザがテストするにはやや尚早だが、現在の開発ペースが続けば、あと1か月もすればかなり行けるのではないか、という期待を感じる。差し上げたテストケースも、明らかにこのケースで初めてテストされるようなコードパスがどんどん直されていくので、まんざら当方の親切の押し売りでもなく、かなり使って頂いているようだ。
ところで、Kitwareのこのような個々の開発テーマの開発ブランチが、このようにオープンに外に出てくるのは珍しい(通常、おおかた固まってからCVS HEADにまとめてコミットされる)。今回はコミュニティの関心が高い開発テーマであるのも、オープンとした一因であろうと推察するのだが、今後もこうやって頂けるためには、やはりそのようにして良かったと思わせ、次もそのようにしようとモチベートさせるだけのコミュニティからのリワードが必要だと考える。それが今回、パッチやテストケースをわざわざ当方からコントリビュートした理由でもある。
さて、ポリヘドラVTKの件。Kitwareデベロッパの方が、前回エントリで書いたOpenFOAMリーダへの実装とOpenFOAMデータのテストケースが欲しいということで、むろん差し上げたら、リーダの方は、このコミットでGitHub上の開発版に反映して頂いた。従って現在は、GitHubからダウンロードしてくれば、OpenFOAMリーダは即ポリヘドラ対応である。
現在はまだ一般ユーザがテストするにはやや尚早だが、現在の開発ペースが続けば、あと1か月もすればかなり行けるのではないか、という期待を感じる。差し上げたテストケースも、明らかにこのケースで初めてテストされるようなコードパスがどんどん直されていくので、まんざら当方の親切の押し売りでもなく、かなり使って頂いているようだ。
ところで、Kitwareのこのような個々の開発テーマの開発ブランチが、このようにオープンに外に出てくるのは珍しい(通常、おおかた固まってからCVS HEADにまとめてコミットされる)。今回はコミュニティの関心が高い開発テーマであるのも、オープンとした一因であろうと推察するのだが、今後もこうやって頂けるためには、やはりそのようにして良かったと思わせ、次もそのようにしようとモチベートさせるだけのコミュニティからのリワードが必要だと考える。それが今回、パッチやテストケースをわざわざ当方からコントリビュートした理由でもある。
2010/4/5 1483歩
昨日は9996歩だったんですが。。。嗚呼
新年度となった。このブログも最近更新が滞り気味だが、何とか続けたい。
このブログでも度々書いているParaView/VTKのポリヘドラ対応について、実はVTKの開発ブランチがGitHub上に存在することがアナウンスされている。で、この開発状況がどんな感じなのか見てみたくなったので、実際的なポリヘドラ関連APIの使用方法について質してみた。すぐにCEO氏直々に回答が得られたので、そのとおりにOpenFOAM readerに実装し、ついでに生のVTKでは何かと不便なので、このVTKを使ってポリヘドラ対応ParaViewをビルドしてみた(その1、その2)。
結論としては、スライスもクリップも何も行わない状態のメッシュデータはちゃんと表示してくれるので、ジオメトリ・フィルタについてはほぼ完成の域にあると考えてよさそう。だが、その他ほとんどのフィルタは適用するとParaViewがクラッシュしてしまった。開発工程の先はまだ長いと考えた方が良いようだ。とはいえ、ポリヘドラ対応版ParaViewがどうなるかを垣間見るには十分だった。ビルド方法は上記「その1」「その2」のリンク先に書いておいたので、我もと思われん方は試してみられたい。
ところで、このような「試してみた」をわざわざMLに投稿するのには、2つの理由がある。ひとつは無論、ポリヘドラの実装方法を教えてもらって、たまたま見つけたバグもついでに報告という、メールに書いた文面の文字どおりの意味である。もうひとつは、OpenFOAM readerでの実際の実装結果、検証用テストケース＆パッチの投稿という、行動の結果としての産物を示すことで、OpenFOAMコミュニティの一員としてポリヘドラ関連機能開発を支持する姿勢を明確に打ち出すことだ。このように示すことで、単に言葉で「期待しています」と述べるより、大幅に説得力のあるメッセージを開発者に送ることができる。幸い、CEO氏には後者の意図を理解していただけて、OpenFOAMコミュニティを支持する旨のリプライを頂くことができた。コードをガリガリ書くばかりでなく、開発者をコミュニティにとって望ましい方向に誘導することも、オープンソース・コミュニティへの貢献である。
[追記] Calculix 2.1 リリース。
新年度となった。このブログも最近更新が滞り気味だが、何とか続けたい。
このブログでも度々書いているParaView/VTKのポリヘドラ対応について、実はVTKの開発ブランチがGitHub上に存在することがアナウンスされている。で、この開発状況がどんな感じなのか見てみたくなったので、実際的なポリヘドラ関連APIの使用方法について質してみた。すぐにCEO氏直々に回答が得られたので、そのとおりにOpenFOAM readerに実装し、ついでに生のVTKでは何かと不便なので、このVTKを使ってポリヘドラ対応ParaViewをビルドしてみた(その1、その2)。
結論としては、スライスもクリップも何も行わない状態のメッシュデータはちゃんと表示してくれるので、ジオメトリ・フィルタについてはほぼ完成の域にあると考えてよさそう。だが、その他ほとんどのフィルタは適用するとParaViewがクラッシュしてしまった。開発工程の先はまだ長いと考えた方が良いようだ。とはいえ、ポリヘドラ対応版ParaViewがどうなるかを垣間見るには十分だった。ビルド方法は上記「その1」「その2」のリンク先に書いておいたので、我もと思われん方は試してみられたい。
ところで、このような「試してみた」をわざわざMLに投稿するのには、2つの理由がある。ひとつは無論、ポリヘドラの実装方法を教えてもらって、たまたま見つけたバグもついでに報告という、メールに書いた文面の文字どおりの意味である。もうひとつは、OpenFOAM readerでの実際の実装結果、検証用テストケース＆パッチの投稿という、行動の結果としての産物を示すことで、OpenFOAMコミュニティの一員としてポリヘドラ関連機能開発を支持する姿勢を明確に打ち出すことだ。このように示すことで、単に言葉で「期待しています」と述べるより、大幅に説得力のあるメッセージを開発者に送ることができる。幸い、CEO氏には後者の意図を理解していただけて、OpenFOAMコミュニティを支持する旨のリプライを頂くことができた。コードをガリガリ書くばかりでなく、開発者をコミュニティにとって望ましい方向に誘導することも、オープンソース・コミュニティへの貢献である。
[追記] Calculix 2.1 リリース。
2010/3/30 2916歩 [日記・雑感]
Radiance 4.0リリース。リリースノートにParallel rendering, multiprocessingの語が見えるところからして、マルチプロセッサ対応が目玉？
Discretizerの新バージョンリリース。Linux用バイナリが用意されている。
衝突解析パッケージのImpactの開発が活発なようで、週刊以上のペースでのリリースが続いている。
Salome/Code_Aster User's Day 2010のプレゼンテーションスライド集。2015年に向けたロードマップ、なんていう講演もある。全てフランス語で、じっくり読んで紹介する時間がないのが残念だが、何となく斜め読みした中で興味深いのがこちら。以前紹介した、SalomeへのParaView統合の開発版と思しきスクリーンショットを14枚目に見ることができる。現在、Geometry/Mesh/Post等があるSalomeのモジュールに加えて、PARAVISという名のモジュールとして搭載されるようだ。
ParaView 3.8、VTK 5.6それぞれのリリースに向けたブランチが切られた。あと1～2箇月もすればリリースされると思われる。
Discretizerの新バージョンリリース。Linux用バイナリが用意されている。
衝突解析パッケージのImpactの開発が活発なようで、週刊以上のペースでのリリースが続いている。
Salome/Code_Aster User's Day 2010のプレゼンテーションスライド集。2015年に向けたロードマップ、なんていう講演もある。全てフランス語で、じっくり読んで紹介する時間がないのが残念だが、何となく斜め読みした中で興味深いのがこちら。以前紹介した、SalomeへのParaView統合の開発版と思しきスクリーンショットを14枚目に見ることができる。現在、Geometry/Mesh/Post等があるSalomeのモジュールに加えて、PARAVISという名のモジュールとして搭載されるようだ。
ParaView 3.8、VTK 5.6それぞれのリリースに向けたブランチが切られた。あと1～2箇月もすればリリースされると思われる。
2010/2/21 1429歩 [日記・雑感]
企業秘密クラスという程の機密ではないのだが、「やっつけ仕事の汚いソースコードなので見られると恥ずかしい」「そのうちしっかりドキュメントを書いてコードを整理してオープンソースにしてもいいけど、とりあえず今はプライベートに持っておきたい」みたいな程度に人に見られたくない、でもやっぱりプロジェクトホスティングサービスを利用して出先などからもアクセスできるといいなぁ、というプロジェクトを幾つか抱えるようになった。プロジェクトホスティングサービス代表格のSourceForgeは残念ながらオープンソース専用だが、最近はプライベートなリポジトリを持てるホスティングサービスもあるようで、例えばGitHubは$7/monthで5つまで、bitbucketはフリーで1つ、$5/monthで5つまでのプライベートリポジトリを持てるようだ。
そんな中で目を引いたのがOrigoという、ETH Zurich (スイス連邦工科大学チューリッヒ校) の運営しているサービス。完全無料で、レポジトリの数、容量ともに明確な上限が設けられていない、ある種いい加減な所が特徴だ。とはいえレポジトリの作成は申請制なので、あまり大量に作るとお叱りが来るのかもしれないが、とりあえずOrigoを使ってみることにした。今のところ、レスポンスもSourceForgeより良く上々だ。
ParaView MLに投稿されたメールに引用されて漏れてきたプライベートなメッセージに、ParaViewをSalomeのポストプロセッシング・エンジンとするため統合作業中、とのEDFデベロッパの方の一文が。もともとSalomeのポストプロセッシング・モジュールはVTKベースだし、ParaViewの最近の開発テーマはParaViewベースのカスタムアプリケーション開発や埋め込みモジュールとしての利用容易化にあるのは確かだが、Salomeのような巨大なシステムにParaViewを統合するような荒技が一体どうやって出来るのかサッパリ見当がつかない。とはいえ、今までやると言ったことは悉くやってきたEDFの方々だから、今度も何としてでもやってしまうのだろう。
ParaView/VTKのポリヘドラサポートは少しずつ進んでいるようだ。VTK Wikiには、スケジュールも書かれた専用のページも作られた。スケジュールを見る限り、今月下旬から来月上旬に見込まれるParaView 3.8/VTK 5.6のブランチには間に合わないようだが、その次のバージョンには含まれる可能性が高い。
Code_Aster最新版の10.1をWindowsにポーテイングされた方が居られるようだ。最後にポーティングされたのは9.1だったから、ひさびさの更新だ。
そんな中で目を引いたのがOrigoという、ETH Zurich (スイス連邦工科大学チューリッヒ校) の運営しているサービス。完全無料で、レポジトリの数、容量ともに明確な上限が設けられていない、ある種いい加減な所が特徴だ。とはいえレポジトリの作成は申請制なので、あまり大量に作るとお叱りが来るのかもしれないが、とりあえずOrigoを使ってみることにした。今のところ、レスポンスもSourceForgeより良く上々だ。
ParaView MLに投稿されたメールに引用されて漏れてきたプライベートなメッセージに、ParaViewをSalomeのポストプロセッシング・エンジンとするため統合作業中、とのEDFデベロッパの方の一文が。もともとSalomeのポストプロセッシング・モジュールはVTKベースだし、ParaViewの最近の開発テーマはParaViewベースのカスタムアプリケーション開発や埋め込みモジュールとしての利用容易化にあるのは確かだが、Salomeのような巨大なシステムにParaViewを統合するような荒技が一体どうやって出来るのかサッパリ見当がつかない。とはいえ、今までやると言ったことは悉くやってきたEDFの方々だから、今度も何としてでもやってしまうのだろう。
ParaView/VTKのポリヘドラサポートは少しずつ進んでいるようだ。VTK Wikiには、スケジュールも書かれた専用のページも作られた。スケジュールを見る限り、今月下旬から来月上旬に見込まれるParaView 3.8/VTK 5.6のブランチには間に合わないようだが、その次のバージョンには含まれる可能性が高い。
Code_Aster最新版の10.1をWindowsにポーテイングされた方が居られるようだ。最後にポーティングされたのは9.1だったから、ひさびさの更新だ。
