計算科学

ゼロから並列科学計算ソフトウェアを開発したいです。どの言語から始めるべきかを考えてみたい。このプログラムは、txtファイルへのデータの読み取り/書き込みと、多くのLU分解およびスパース線形ソルバーの使用を伴う大量の計算を並行して実行します。私が考えていたソリューションの候補は、OpenMPまたはco-arrayを備えたFortran 2003/2008、openmp cilk +またはTBB、pythonを備えたC ++です。その他の文書化された提案は大歓迎です！私はC、Fortran、Javaを（この順序で）よく知っています。私はPythonでいくつかのスクリプトを作成しましたが、基本的なものです。 fortranは非常に高速ですが、保守や並列化が難しいことは知っています。私が好きなPythonなどの外部ライブラリを使用しない限り、C ++は遅いと言われていますが、フルスケールの産業レベルのソフトウェアを書くことは現実的ですか？ ソフトウェアは、大量のデータを処理でき、科学計算で効果的である必要があります。パフォーマンスが重要です。 背景については、Fortranで書かれた動作するソフトウェアが既にあります。多くの人々が長年にわたって開発に関わっており、コードは本当に汚れています。コードの維持と並列化は悪夢であることが証明されており、代替案を考えています。 ペトロス

18 python  hpc  c++  fortran  simulation 

流れの中に存在する生物学的物質を使用して、流れをシミュレートするコードを開発しています。これには、いくつかの追加の生物学的モデルに結合された標準のナビエ・ストークス方程式が含まれます。多くのパラメーター/定数があります。 私は主要な計算を処理する関数を作成しましたが、私が抱えている問題は、これらの計算が依存する多数の定数/パラメーターです。関数に10〜20個の引数を渡すのは面倒です。 1つの代替方法は、すべての定数をグローバル変数にすることですが、これはC ++では嫌われていることは知っています。 関数への多くの入力を処理する標準的な方法は何ですか？構造体を作成し、代わりに渡す必要がありますか？ ありがとうございました

17 c++ 

2つの異なるBLAS実装を考えると、まったく同じ浮動小数点計算を行い、同じ結果を返すと期待できますか？または1つのようにスカラー積を計算することは、例えば、起こることができる そしてような一つ そうおそらくIEEE浮動小数点に異なる結果を与えます算術？（（x1y1+ x2y2）+ x3y3）+ x4y4（（バツ1y1+バツ2y2）+バツ3y3）+バツ4y4 ((x_1y_1 + x_2y_2) + x_3y_3) + x_4y_4 （x1y1+ x2y2）+ （x3y3+ x4y4）、（バツ1y1+バツ2y2）+（バツ3y3+バツ4y4）、 (x_1y_1 + x_2y_2) + (x_3y_3 + x_4y_4),

17 floating-point  blas 

私は、航空宇宙工学の分野に興味のある機械工学の学生で、Fortranがまだ一般的に使用されていると言われています。 どのバージョンのFortranを学習するために時間を費やすべきですか？

17 fortran 

高次（つまり4を超える）Runge–Kuttaメソッドが（少なくとも私の知る限り）議論されたり、雇用されたりすることがほとんどない理由について、私は興味がありました。ステップあたりの計算時間が長くなることは理解していますが（たとえば、12次の埋め込みステップを含むRK14）、高次のルンゲクッタ法を使用することには他の欠点（安定性の問題など）がありますか？極端な時間スケールで高度に振動する解を含む方程式に適用される場合、そのような高次の方法は通常好まれませんか？

17 ode  runge-kutta 

オブジェクト指向プログラミングを最大限に活用する方法を習得する方法として、スパース行列計算用の小さなライブラリを作成しています。パーツ（疎行列と、それらの接続構造を記述するグラフ）が非常に緩やかに結合されている素晴らしいオブジェクトモデルを作成するために、私は一生懸命取り組んできました。私自身の見解では、コードははるかに拡張性があり、保守が容易です。 ただし、鈍いアプローチを使用した場合よりも多少遅くなります。このオブジェクトモデルを使用することのトレードオフをテストするために、基になるグラフのカプセル化を破る新しいスパースマトリックスタイプを作成して、実行速度を確認しました。 最初は、かなり暗いように見えました。私がかつて誇りに思っていたコードは、洗練されたソフトウェア設計のないバージョンよりも60％遅くなりました。しかし、APIをまったく変更せずに、関数をインライン化し、ループを少し変更するという、いくつかの低レベルの最適化を行うことができました。これらの変更により、競合よりもわずか20％遅くなりました。 それは私の質問に私をもたらします：それが私が素晴らしいオブジェクトモデルを持っていることを意味する場合、どのくらいのパフォーマンス損失を受け入れるべきですか？

17 linear-algebra  sparse-matrix  oop 

不連続ガラーキン法で解を表す一般的なアプローチには、ノードとモーダルの2つがあります。 モーダル：解は、モーダル係数の和に多項式のセットを掛けたもので表されます。たとえば、ここで、ϕ iu （x 、t ）= ∑Ni = 1あなたは私（t ）ϕ私（x ）あなたは（バツ、t）=∑私=1Nあなたは私（t）ϕ私（バツ）u(x,t) = \sum_{i=1}^N u_i(t) \phi_i(x)ϕ私ϕ私\phi_iは通常、直交多項式、たとえばルジャンドル。この利点の1つは、直交多項式が対角質量行列を生成することです。 節点：セルは、ソリューションが定義される複数のノードで構成されます。セルの再構築は、補間多項式のフィッティングに基づきます。たとえば、ここで、l iはラグランジュ多項式です。この利点の1つは、ノードを直交点に配置して積分をすばやく評価できることです。u （x 、t ）= ∑Ni = 1あなたは私（x 、t ）l私（x ）あなたは（バツ、t）=∑私=1Nあなたは私（バツ、t）l私（バツ）u(x,t) = \sum_{i=1}^N u_i(x,t) l_i(x)l私l私l_i 大規模の文脈では、複合（ - 10 910610610^610910910^9のDOF）3Dは、柔軟性、実装の明瞭さ、および効率の目標と構造化/非構造化並列アプリケーションを混合し、各方法の比較長所と短所は何ですか？ すでに優れた文献が存在していると確信しているので、誰かが私にも素晴らしいものを教えてくれるとしたら。

17 fluid-dynamics  discontinuous-galerkin 

計算からいくつかのデータを書き込む必要があり、後でParaview（.vtuまたはvtkファイル）によって読み込まれます。 ファイルサイズに関して言えば、ASCII形式とバイナリ形式のどちらを使用すべきですか。

17 visualization  paraview  vtk 

私はメッシュ生成ソフトウェアを探しています 無料でオープンソースです。 ドメイン指定のための健全なスクリプトインターフェイスを提供します。 複雑な形状に機能し、 2Dおよび3Dメッシュを生成できます。 どのようなオプションがありますか？

17 mesh-generation 

どちらが良いですか：FORTRANまたはPython？そして、どちらの場合もGnuplotが必要だと思います。 現在、Windowsマシンで作業しています。 モンテカルロシミュレーション、数値積分と微分、分子動力学などを含む物理問題の数値解を得るために使用したいと思います。 FORTRAN（私が信じる77）とPythonの両方を紹介する計算物理学のコースを見ました。私は一方から始めて、もう一方を学ぶことを計画していますが、どの遷移が最も簡単かはわかりません。 また、どのコンパイラをお勧めしますか？ 私にとっての基本的な質問は、学習するのが最も簡単なもの、最も速いもの、最も使いやすいもの、そして何よりも最も使用されているものです（これら4つの比較）。そして、その次に使用されている最も一般的な（無料または有料）コンパイラは何ですか？現在、古いラップトップ（初期のIntelデュアルコア）をLinuxに変換することを検討しています。うまくいけば、それは十分に高速です。 これまでの回答に感謝します！私が探しているものと一致する答えはLKlevinとSAADのものです。 私はC ++、Mapleの基本を知っており、MATLABとMathematica9をマスターすれば、それが助けになります。

17 python  fortran 

共役勾配がGMRESメソッドよりもはるかに優れている場合に興味があります。 一般に、CGは多くのSPD（対称正定値）の場合に望ましい選択であり、必要なストレージが少なく、CGの収束率の理論的限界がそのGMRESの2倍であるためです。そのような率が実際に観察される問題はありますか？GMRESが同じ数のspmv（スパースマトリックスベクトル乗算）でCGより優れているか、CGに匹敵する場合の特性はありますか。

17 linear-solver  conjugate-gradient  gmres 

私自身の仕事の多くは、アルゴリズムのスケーリングを改善することを中心にしています。並列スケーリングおよび/または並列効率を示す好ましい方法の1つは、アルゴリズム/コードのパフォーマンスをコア数にわたってプロットすることです。 ここで、軸はコアの数を表し、軸は何らかのメトリック（単位時間ごとに実行される作業など）を表します。異なる曲線は、64コアでそれぞれ20％、40％、60％、80％、100％の並列効率を示しています。yバツバツxyyy しかし残念なことに、多くの刊行物に、これらの結果がでプロットされている対数で結果例えば、スケーリング本またはこの論文。これらのログ-ログプロットの問題は、実際の並列スケーリング/効率を評価することが非常に難しいことです。たとえば、 上記と同じプロットですが、log-logスケーリングを使用しています。60％、80％、または100％の並列効率の結果に大きな違いはないことに注意してください。ここでこれについてもう少し広範囲に書いた。 そこで、ここに私の質問があります：log-logスケーリングで結果を表示する理由は何ですか？私は定期的に線形スケーリングを使用して自分の結果を表示し、レフリーから定期的に私のスケーリング/効率の結果は他の人の（ログ-ログ）結果ほど良く見えないと言っていますが、私の人生ではプロットスタイルを切り替える必要がある理由がわかりません。

17 parallel-computing  hpc  scaling  plotting 

24個のIntel Xeon CPUを含むノードで構成されるUbuntu Linuxクラスターで分子動力学（MD）コードGROMACSを実行しました。私の特定の関心のある点は、浮動小数点演算の精度に多少敏感であることが判明したため、GROMACSは、倍精度の計算コストが高いにもかかわらず、単精度ではなく倍精度で実行する必要がありました。そのため、クラスターでは、GROMACSを倍精度でコンパイルしました。 CPUに対して相対的な高速化（「GPUアクセラレーション」）が行われる可能性があるため、GPUの購入を検討しています。ただし、倍精度演算を実行できるGPUが必要です。そのようなハードウェアが市販されているかどうか知っていますか？GROMACSメーリングリストの最近の投稿は、倍精度のGPUは市販されていないことを示唆しています： ハードウェアはそれをサポートしていません[倍精度演算]まだ知らない。 このウィキペディアのページは、倍精度GPUは非効率的である可能性があるため、一般的でないことを示唆しているようです。 Nvidia GPUでの浮動小数点の実装は、ほとんどがIEEEに準拠しています。ただし、これはすべてのベンダーに当てはまるわけではありません。これは、いくつかの科学的応用にとって重要であると考えられている正確さに影響を及ぼします。CPUでは64ビット浮動小数点値（倍精度浮動小数点数）が一般的に使用可能ですが、これらはGPUでは普遍的にサポートされていません。一部のGPUアーキテクチャはIEEE準拠を犠牲にし、他のGPUアーキテクチャは倍精度を完全に欠いています。GPUで倍精度浮動小数点値をエミュレートする努力がありました。ただし、速度のトレードオフは、そもそもGPUに計算をオフロードする利点を無効にします。 このNVIDIA Teslaページは、チャートの「ピークの倍精度浮動小数点パフォーマンス」を参照する際に、実際には、GPUで倍精度計算を実行できることを示唆しているようです（計算コストは​​高くなりますが）。 だから、私は何を信じるべきですか？この問題の経験はありますか？

17 hpc  floating-point  molecular-dynamics  gpu 

私はデスクトップにNvidia GT660グラフィックカードをインストールしましたが、苦労してRとのインターフェイスを管理しました。 GPU、特にgputoolsを使用するいくつかのRパッケージで遊んでおり、GPUとCPUが基本的な操作を実行するのにかかる時間を比較していました。 行列の反転（CPU高速） qr分解（CPU高速） 大きな相関行列（CPU高速） 行列乗算（GPUがはるかに高速！） 私は主にgputoolsで実験しているので、他のパッケージの方がパフォーマンスが良いかもしれません。 大まかに言うと、私の質問は次のとおりです。CPUではなくGPUで実行する価値のある日常的な統計演算は何ですか？

17 r  gpu 

両方の行列がCSCまたはCSR形式であると仮定して、スパース行列の乗算演算で事前に非ゼロの数を見つけるための高速で効率的な方法があるかどうか疑問に思いました。 smmpパッケージにあるものは知っていますが、CまたはC ++で既に実装されているものが必要です。 任意の助けをいただければ幸いです。前もって感謝します。

17 matrix  sparse-matrix