1

私が取り組んでいる Fortran で書かれた熱水力学のコードがあります。私のデバッグ バージョンでは、-check boundsコンパイル時に ifort 11.1 のオプションを使用します。過去にこの方法で配列境界エラーをキャッチしました。しかし最近、特定のケースでソリューションが急速に爆発しているのを見ました。奇妙な点は、コードのリリース バージョンでうまく収束していたことです。案の定-check bounds、デバッグ makefile からフラグを削除すると問題が解決しました。

奇妙なことは、以前に使用した他の多くのテスト ケースでデバッグ バージョンが正常に動作し、コード内の配列境界の外に出てもエラーが発生しなかったことです。この動作は私には非常に奇妙に思えます。コードに何らかのバグがあるのか​​ 、それとも何なのかわかりません。この種の動作を引き起こしている可能性のあるアイデアはありますか?

リクエストに応じて、リリースとデバッグに使用するフラグは次のとおりです。

リリース：-c -r8 -traceback -extend-source -override-limits -zero -unroll -O3

デバッグ：-c -r8 -traceback -extend-source -override-limits -zero -g -O0

もちろん、元の質問が示すように-check bounds、デバッグの場合はフラグのオンとオフを切り替えます。

4

1 に答える 1

0

ここでの数値アルゴリズムは、Fortran コードよりも疑わしいと思います。収束と安定性の基準がすべて満たされていることを確認しましたか?

どうやら、丸め誤差が原因で解が収束しないようです。安全な収束の端にいる場合、コンパイラの最適化は間違いなく物事を何らかの形で変える可能性があります。

私はgfortranmore thanを使用ifortしているので、-unroll オプションのすべての詳細はわかりませんが、ループを展開すると、計算が同じままであるように見えても、いくつかの丸めが変更される可能性があります。また、デバッグにより、メモリとレジスタへのアクセスの正確な順序が確実に変更されます。数値が何らかの内部表現でプロセッサにある場合、メモリに書き込まれ、再度読み取られると、値が変わる可能性があります。これは、慎重に選択することである程度軽減できますkind。その性質上、これは移植可能ではなく、プロセッサ固有のものになります。

理論的には、IEEE 754 に完全に準拠することで浮動小数点演算が再現可能になりますが、常にそうとは限りません。コード内の他のバグではなく、デバッグが実際にこれらの問題を引き起こしている場合は、プロセッサの内部動作に関連する他の不思議なことが原因で爆発する可能性もあります。

コードのさまざまなキー ポイントに write ステートメントを追加して、データ マトリックス (または使用しているデータ構造) を出力します。必ずバイナリ出力を使用してください。form='unformatted'とで開きaccess='direct'ます。

于 2013-02-27T08:48:25.007 に答える