問題タブ [scalapack]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - scalapackまたは他の並列行列ライブラリで使用するためのgsl線形代数の変換
私はGNUScientificLibrary(GSL)行列演算に深く埋め込まれたコードを持っています。このコードの主な計算は、シリアルで非常に長い時間がかかる線形方程式の大規模なシステムを解くことであり、GSLおよびBLAS関数を使用する方法があります。この計算を並列化するか、ScaLAPACKのようなすでに並列化されたライブラリで使用するために変換しますか?
c++ - C++からScaLAPACKを呼び出す
こんにちは、C++からScaLAPACKを呼び出すためのMakefileの例を教えてください。問題が発生しています。
すべてのテストに合格して、最新バージョンを正しくコンパイルしました。FedoraでGCCとOpenMPIを使用してコンパイルしました。また、リポジトリからビルド済みのバイナリを使用してみましたが、運が悪かったです。
c - Cでmpiとlapackを使用するとセグメンテーション違反が発生する
Blacのpdgemmを使用して行列の乗算を実行しようとしています。私が使用している行列乗算の正確なサブルーチンは、http: //www.netlib.org/scalapack/html/pblas_qref.html#PvGEMMにあります。
ただし、私のコードは、pdgemm呼び出しで「スレッドローカルデータにメモリを割り当てることができません:ABORT」を返します。私のコードでは、行列を単独で乗算しており、それは正方行列であるため、結果の行列は同じ次元になります。これが問題のコードです
私はScaLapacsの経験があまりありませんが、私が調べた例から、なぜセグメンテーション違反が発生するのかわかりません。助けていただければ幸いです。
c++ - コレスキー分解ScaLapackエラー
次のエラーが発生しましたが、理由がわかりません。
エラーメッセージの意味はわかっていますが、Webで入手できる古いドキュメントに可能な限り従い、Webで動作するサンプルコードから並列コレスキー分解を組み合わせようとしました。どこが間違っていたのかわかりません。
以下のコードで私がどこで間違っていたのかを誰かが説明できますか?コードの概要は次のとおりです。4つのプロセッサでテストし、8x8マトリックスを2 x 2プロセッサに分割します。ブロックグリッドはファイルからマトリックスをロードします。ここでは、8x8マトリックスファイルの例を示します。
例に従って、マトリックスを4つのノードのそれぞれに1つずつある4つの個別の4x4ローカルアレイに分散しました。次に、関連するルーチンを実行descinit_
して呼び出します。これにより、上記のエラーが発生します。pdpotrf_
どこが間違っていたのかわからず、できる限りドキュメントに従おうとしました。fortranでの並列コレスキー分解の実例も大いに役立ちます
関数呼び出しのリファレンス
実行パラメータ
上記のパラメータをすべてのノードに出力しましたが、同じです
system - LAPACK の DGBSV を使用して C からバンド システムを解く
このトピックに関連する同様のスレッドを検索しようとしましたが、誰もバンド システムを気にしていないようです (...)。
C コードから LAPACK/ScaLAPACK を使用してバンド行列を解くことに興味があります。まず、ScaLAPACK で何かを試みる前に、LAPACK で逐次的なソリューションを実現したいと考えています。
問題: 両方の言語の行優先/列優先の違いが、ソリューション プロセスに影響しているようです。私が解決しようとしているシステムは次のとおりです。
次のコードは、そのマトリックスを、ここで指定された LAPACK のバンド データ構造に変換します。
私が言ったように、私の解決策が得られるので、行列を翻訳する方法が間違っているのではないかと心配しています。
Fortran からの戻り値はinfo = 1
、因数分解が完了したことを意味しますがU(1,1) = 0
、A = LU
.
c - ScaLAPACK、Cblacs_gridinit() の呼び出し中に「セマフォのタイムアウト期間が切れました」
Windows 7 コンピューターのネットワーク上に MPICH2 がインストールされた Intel MKL の ScaLAPACK を使用しています。次のように、単一のマシンでジョブを実行すると正常に動作します。
さらに、実行するとネットワーク経由で正常に動作しますcpi.exe
(テスト プログラムは MPICH2 と共に提供されます)。
私のコード (大きな一次方程式の解) も、単一のマシンで正常に動作します。ただし、次の場合は失敗します。
メッセージは次のとおりです。
私が今知っていることから、問題は私のCコードの早い段階で発生します:
助けやアドバイスをいただければ幸いです。この問題を解決することは、私にとって非常に重要です。
編集: 以下のコードは機能するので、私の MPI インフラストラクチャは問題ないようです..?
c - 奇妙な方法でMPI/ScaLAPACKセグメンテーション違反を使用するC/Fortranハイブリッドコード
このコードをFortranからCに変換しようとしています。
これは私がこれまでに持っているものです:
コメントアウトされた変数の量を許してください、しかし私が言ったように、私は基本的に最初から参照ドライバーを翻訳しています。
私の問題は、forループを作成するとすぐに、突然seg-faultingが開始されたことです...以前は機能していました。これは、ファンキーなメモリ操作の問題の明らかな兆候です。これは、CとFortranのメモリ管理の違いに関連する問題からおそらく発生します。
少なくとも、それは私の推測です。
誰かが何がうまくいかないかについての手がかりを持っていますか?
よろしくお願いします!
fortran - 使用されているよりも多くのプロセスで BLACS を呼び出す
SCALAPACK を多用する並列プログラムを作成したいと考えています。SCALAPACK の基礎は BLACS であり、BLACS 自体はプロセス間通信を MPI に依存しています。
定義された数のプロセス (マシン上のコアの数など) でプログラムを開始し、これらのプロセスを計算に使用する方法をアルゴリズムに決定させたいと考えています。
テストケースとして、10 個のプロセスを使用したいと考えました。これらのプロセスのうち 9 つをグリッド ( BLACS_GRIDINIT
) に配置し、10 番目のプロセスは他のプロセスが終了するまで待機する必要があります。
残念ながら、最後のプロセスが BLACS から MPI コンテキストに入らないため、OpenMPI はクラッシュします。
質問:必要以上のプロセスで BLACS を使用する正しい方法は何ですか?
MPI_INIT
additionalとMPI_FINALIZE
呼び出しを使っていくつかの実験を行いましたが、どれも成功しませんでした。
インテル® MKL のサンプル・コード (少し短縮) から始めました。
更新:のソース コードを調べて、BLACS
そこで何が起こっているのかを確認しました。
これが以前に発生しなかった場合、呼び出しBLACS_PINFO
は MPI コンテキストを で初期化します。MPI_INIT
これは、この時点ですべてが期待どおりに機能することを意味します。
最後に、 への呼び出しはBLACS_EXIT(0)
からすべてのリソースを解放する必要がBLACS
あり、引数が0
の場合は も呼び出す必要がありますMPI_FINALIZE
。残念ながら、これは期待どおりに機能せず、最後のプロセスは を呼び出しませんMPI_FINALIZE
。
回避策として、必要に応じて質問MPI_FINALIZED
して電話することができますMPI_FINALIZE
。
更新 2:以前の試みは と で行われIntel Studio 2013.0.079
ましOpenMPI 1.6.2
たSUSE Linux Enterprise Server 11
。
ctheo の回答を読んだ後、Ubuntu 12.04
( gfortran 4.6.3, OpenMPI 1.4.3, BLACS 1.1
) で指定されたツールを使用してこの例をコンパイルしようとしましたが、成功しました。
私の結論は、Intel の実装にはバグがあるように見えるということです。の最新のサービス リリースで、そう遠くない将来にこの例を再試行しますがIntel Studio
、変更は期待できません。
ただし、他の(そしておそらくより良い)ソリューションをいただければ幸いです。