タグ付けされた質問 「testing」

自動化された一連の回帰テストを含む、完全なプログラムを検証するテスト（収束テストなど）を使用することの価値を強く確信しています。プログラミングの本を読んだ後、ユニットテスト（つまり、単一の関数の正確性を検証し、問題を解決するためにコード全体を実行するテストではない）を作成する必要があるというしつこい気持ちになりました。。ただし、単体テストは常に科学的コードに適合しているとは限らず、結果的に人為的または時間の無駄に感じます。 研究コードの単体テストを作成する必要がありますか？

89 programming-paradigms  testing 

解決すべきいくつかの挑戦的な非凸のグローバル最適化問題があります。現在、MATLABのOptimization Toolbox（特にfmincon()algorithm ='sqp'を使用）を使用していますが、これは非常に効果的です。ただし、私のコードのほとんどはPythonで作成されているため、Pythonでも最適化を行いたいと考えています。競合できるPythonバインディングを備えたNLPソルバーはありfmincon()ますか？ちがいない 非線形等式および不等式の制約を処理できる ユーザーがヤコビアンを提供する必要はありません。 グローバルな最適化を保証していなくても構いません（保証fmincon()しません）。私は、困難な問題や、それよりもわずかに遅い場合でも、ローカル最適にロバストに収束するものを探していfmincon()ます。 OpenOptで利用できるソルバーをいくつか試しましたが、MATLABのソルバーより劣っていfmincon/sqpます。 強調するために、私はすでに扱いやすい定式化と優れたソルバーを持っています。私の目標は、ワークフローをより合理化するために、単に言語を変更することです。 Geoffは、問題のいくつかの特性が関連している可能性があると指摘しています。彼らです： 10-400の決定変数 4〜100の多項式等式制約（1〜8の範囲の多項式次数） 決定変数の数の約2倍に等しい合理的な不等式制約の数 目的関数は決定変数の1つです 不等式制約のヤコビアンと同様に、等式制約のヤコビアンは密です。

77 python  optimization  nonlinear-programming  linear-algebra  linear-solver  sparse-matrix  ode  automatic-differentiation  efficiency  matrix  symbolic-computation  pde  multiphysics  operator-splitting  fluid-dynamics  pde  multigrid  pde  hyperbolic-pde  quadrature  precision  numerical-analysis  fluid-dynamics  interpolation  c  ode  testing  data-sets  pde  fluid-dynamics  hyperbolic-pde  pde  finite-element  fluid-dynamics  stability  incompressible  pde  hyperbolic-pde  fluid-dynamics  pde  precision  floating-point  convex-optimization  conditioning  pde  hyperbolic-pde  stability  implicit-methods  explicit-methods  fluid-dynamics  accuracy  pde  hyperbolic-pde  petsc  linear-algebra 

計算作業で使用しようとしているソフトウェアの品質を評価する際に（それがあなたが書いたものであるか、缶詰のパッケージであるかを問わず）、標準のデータセットまたは問題でどの程度うまく機能するかを確認することはしばしば良い考えです。計算ルーチンを検証するためのこれらのテストはどこで入手できますか？ （回答ごとに1つのウェブサイト/本をお願いします。）

41 testing  data-sets 

数値的手法の文献では、多くの研究論文は、新しいアルゴリズムのバリエーションの説明と、それに続く1つまたは2つの既存の手法と比較するいくつかのテスト問題で構成されています。これにより、判断が困難になります 関心のある他の問題に対する新しい方法の実行方法 新しい方法がさらに他の既存の方法と比較する方法 もちろん、これらの質問の両方は、通常、新しい方法を採用するかどうかを決定する誰かにとって重要です。この状況を改善するには、可能であれば、メソッドを使用して多数のテスト問題（この質問を参照）を実行し、他のメソッドと比較するためにデータベースに結果をカタログ化することが望ましいと思われます。科学者またはエンジニアは、データベースに対してクエリを実行し、おそらくそれらにとって最も重要なソリューション/問題の特性（精度、効率、定性的特性など）を示し、データベース内のすべてのメソッドのパフォーマンスを定量的に比較できます。 このアイデアの実装には多くの困難があることを認識しています（主に、人々にこれらすべての問題を実際に実行させ、計算コストを測定します）。しかし、私の質問は次のとおりです。結果のそのようなデータベースは存在しますか？（特定のサブフィールドなど）またはこのようなアプローチはどこでも実装されていますか？ これまでに投稿された回答はどちらも、問題のデータベースに関するものです。私は結果のデータベースについて尋ねています。

17 pde  testing 

科学的アルゴリズムの開発は非常に反復的なプロセスであり、多くの場合、実験デザインの一部として、またはアルゴリズムのパフォーマンスの調整の一環として変更する多くのパラメーターを変更する必要があります。これらのパラメーターを構造化して、反復間で簡単に変更したり、新しいパラメーターを簡単に追加したりするには、どのような戦略をとればよいですか？

17 algorithms  testing  programming-paradigms 

私は、科学コンピューティングのテスト駆動開発の大擁護者です。実際のところ、このユーティリティは驚異的であり、コード開発者が知っている古典的な問題を本当に軽減します。ただし、一般的なプログラミングでは発生しない科学的コードのテストには固有の困難があるため、TDDテキストはチュートリアルとしてそれほど有用ではありません。例えば： 一般に、与えられた複雑な問題に対する正確な答えはアプリオリにわからないので、どのようにテストを書くことができますか？ 並列度が変化します。最近、MPIタスクを3の倍数で使用すると失敗するが、2の倍数で動作するというバグに遭遇しました。さらに、一般的なテストフレームワークは、MPIの性質上、MPIにあまり適していません。タスクの数を変更するには、テストバイナリを再実行する必要があります。 科学コードには、多くの場合、密結合され、相互に依存し、交換可能なパーツが多数あります。私たちは皆、レガシーコードを見てきましたが、良いデザインを放棄してグローバル変数を使用することがどれほど魅力的かを知っています。 多くの場合、数値的手法は「実験」であるか、コーダーがその方法を完全に理解しておらず、理解しようとしているため、結果を予測することは不可能です。 科学コード用に書いたテストの例： 時間積分器については、正確な解をもつ簡単なODEを使用し、積分器が所定の精度内でそれを解くかどうかをテストします。さまざまなステップサイズでテストすることにより、精度の順序が正しいです。 ゼロ安定性テスト：境界/初期条件が0のメソッドが0のままであることを確認します。 補間テスト：線形関数が与えられた場合、補間が正しいことを確認します。 レガシー検証：正しいことがわかっているレガシーアプリケーションのコードのチャンクを分離し、テストに使用するためにいくつかの離散値を引き出します。 手動での試行錯誤は別として、特定のコードチャンクを適切にテストする方法がわからないことがよくあります。数値コード用に記述するテストの例や、科学ソフトウェアをテストするための一般的な戦略を提供できますか？

16 testing 

通常、シリアルコードを記述し、その際に、xUnitスタイルのテストフレームワーク（MATLAB xUnit、PyUnit / nose、またはGoogleのC ++テストフレームワーク）を使用してユニットテストを記述します。 Googleの大まかな検索に基づいて、実務家がMPIを使用するコードを単体テストする方法についてはあまり見ていません。そのためのベストプラクティスはありますか？ ユニットテストとテスト駆動開発の戦略と比較して、テストフレームワークに使用するソフトウェアに関する答えを探しています（存在する場合-答えは「独自のコードをロール」することができます）カスタムテストコードの事例が参考になります）。 私がテストしようとしているもののほとんどは、右側の関数評価と半離散化PDEを統合するタイムステッパーのヤコビ行列アセンブリルーチンです。私はPETScを使用するので、PETSc固有のものがあれば、より一般的なテストフレームワークに加えて役立ちます。 明確化の編集： 例はにあり${PETSC_DIR}/src/ts/examples/tutorials/ex2.c、ここでRHSFunction（右側の関数評価）などのテストを行います。RHSJacobian（ヤコビ行列の評価）。私は、組み立てられた右側と組み立てられたヤコビ行列の既知の値に対してテストします。いくつかの単純な問題の場合、これらの値を分析的に取得できます。これらの関数は、他のアプリケーションレベルの関数を実行しないアプリケーション固有の関数ですが、関数内でベクトルまたは行列のアセンブリが実行されると、MPIを呼び出すことができます（上記のリンクされたPETScの例のように）。プロセッサにローカルなベクトルまたは行列の一部のみを計算する関数を作成する場合、可能な場合はグローバルなアセンブルバージョンに対してテストする必要があります。これは、パラレルプログラミングが初めてなので、グローバルなベクトルとグローバルについて考える方が直感的だからです。マトリックス。これらのテストは、小さな問題サイズと少数のプロセッサーで実行されます。 これを行うためのいくつかの戦略を考えることができます。 このトピックで行ったGoogleの検索に基づいて、おそらくうまく機能しない戦略は、既知の出力を構築し、相対/絶対エラーを並行して見つけ、単純な比較を行うことです。MPIを使用して「Hello、world」プログラムを作成した人なら誰でも、出力が文字化けする可能性があります。これは、単体テストの実行の有用性を制限します。（これが質問をするきっかけになりました。）単体テストフレームワークの呼び出しには、潜在的なトリッキーさもあるようです。 出力をファイルに書き込み（たとえば、PETScでVecViewand を使用してMatView）、ndiffまたはのような既知の出力と比較しnumdiffます。ファイル比較を使用して単体テストを行った以前の経験から得たこのメソッドの直感は、細心の注意が必要であり、フィルタリングが必要になるということです。ただし、上記のユーティリティをプレーンdiffに置き換えることができ、テキスト形式の一致を心配する必要がないため、この方法は回帰テストに優れているようです。この戦略は、WolfgangBangerthとandybauerが提案しているものと多かれ少なかれだと思いました。また、PETScは、一部のテストで同様のアプローチを使用しているようです。 単体テストフレームワークを使用して、MPIランク0のプロセッサにすべてを収集し、プロセッサランクが0の場合にのみ単体テストを実行するように依頼します。標準で同様のことができます（おそらく、その方が簡単です）返されたエラーは、計算に問題があることを示しますが、どの要素にエラーがあるかはわかりません。そうすれば、ユニットテストの出力が文字化けすることを心配する必要はありません。単体テストフレームワークを正しく呼び出すことだけを心配する必要があります。PETScは、正確なソリューションが利用可能な場合、サンプルプログラム内で標準的な比較を使用するように見えますが、それらの比較を行うときにユニットテストフレームワークを使用しません（必ずしもそうする必要はありません）。

13 parallel-computing  petsc  mpi  testing  reproducibility 

最近、私は自分のグループにコードを書く際により多くのテストを含めるよう促しています。適切なテスト体制が整っていなかったため、おそらく話すのに必要な時間よりもはるかに長い時間がかかる、いくつかの大きなバグがありました。 ただし、プロセスを自動化（または合理化）するための適切なツールがあれば、きっと役に立つと思います。一方、C ++テストスイートのさまざまなオプションがわからず、それらをどのように決定するのですか？ 何を探すべきかについてのガイドラインはありますか？また、数値アプリケーションに特化したものはありますか？

13 testing 

私の計算科学プログラミングの多くに、標準のテストフレームワークではカバーされないテスト要件があることがわかりました。 計算時間テスト アルゴリズムが遅くならないようにするため。私は次のようなことをすることができます assureSmallerEqual(RuntimeWrapper(algorithm),53)が、アルゴリズムに取り組んでいるときに53秒のしきい値を継続的に減らしたい、つまりassureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance') 性能試験 以前に分析解の良い近似を見つけたアルゴリズムが、少なくとも同じかそれ以上の解を見つけることを確認するため。繰り返しになりますが、これは標準の統合テストでエミュレートできますが、アルゴリズムが次第に良くなるにつれて、許容範囲を継続的に縮小したいと思います。交換assureAlmostEqual(foo(),1,places=3)することを考えるassureAlmostEqual(foo(),1,places='previousbest') 物理的要件のテスト アルゴリズムが突然より多くのメモリ/ハードディスク領域を必要としないことを確認するため。1に非常に似ています。 抽象要件テスト 二次近似でうまくいったアルゴリズムが突然3次近似を必要としないこと、またはタイムステップ0.1でうまく行ったアルゴリズムが安定性のために突然0.01を必要としないことを確認するため。繰り返しになりますが、これらは標準の統合テストでエミュレートできますが、目標は、特定の目標を達成した最小要件パラメーターを覚えておくことです。そのため、これには多くの手動更新が必要になります。たとえば、foo(10)以前に例外がスローされなかった場合は、フレームワークがfoo(10)引き続き機能することを確認し、現在機能するかどうかを試しfoo(9)ます（この場合、今後のすべてのテストで機能することを確認しfoo(9)ます）。 たとえば、ランタイムの増加は他の改善の見返りとして受け入れられる可能性があるため、私が求めているのはユニット/統合テストの意味でのテストについて記述していないと主張することができます。 ただし、実際には、上記のテスト機能があれば、導入したバグのために要件とパフォーマンスが95％失敗したため、デバッグ時間を大幅に節約できたと思います。実際、外部の数値ソフトウェアライブラリを使用して（多くの時間を自分のコードのチェックに費やした後で）見つけた多くのバグは、上記のテストを厳密に適用すれば、簡単に回避できたという事実を知っています。 PS 同様の名前の質問/programming/34982863/framework-for-regression-testing-of-numerical-codeは、標準の回帰テストフレームワークでより簡単に達成できる機能を説明しているため、重複していません。 質問ユニットテストとテスト駆動開発のための戦略、それらを実装する（とその答えで提供され、それは/を要求戦略が、私は私の意見では、ここで説明するものとは異なっている）ことができますフレームワークとは対照的に、戦略を要求します。

10 testing 

実際の物理システムを表す数値モデルがあり、それがカオスを示す場合（例：流体力学モデル、気候モデル）、モデルが期待どおりに動作していることをどのようにして知ることができますか？2つのモデル出力のセットを直接比較することはできません。初期条件の小さな変更でも、個々のシミュレーションの出力が劇的に変化するためです。モデルの出力を直接観測と比較することもできません。観測の初期条件を十分に詳細に知ることはできず、数値近似はいずれにせよシステム全体に伝播する小さな違いを引き起こすからです。 この質問の一部は、科学的コードの単体テストに関する David Ketchesonの質問に触発されました。私は、そのようなモデルの回帰テストをどのように実装できるかに特に興味があります。小さな初期条件の変化が大きな出力の変化につながる可能性がある場合（それでも、現実の適切な表現である場合があります）、パラメーターの変更や新しい数値ルーチンの実装による変化からこれらの変化をどのように分離できますか？

10 testing  numerics 

節点不連続ガラーキン法をすぐに実装し、メッシュと多項式データを前提として、計算する必要がある基本的なインデックス配列を知る前にこれを実行します。 前のコードで遭遇した問題は、内部/外部トレースのインデックス付けなどの計算で行った微妙な間違いでした。単純なテストケースでは発生しなかった問題が大きなメッシュで発生し、境界条件が適切に課されていないため、通常はこれにより不安定なスキームが生成されます（10ステップごとにシミュレーションを監視するだけで、局所的な問題が発生する可能性はありません）。 。 私は、経験豊富な人々が、インデックス配列に対して実行して、それらが正しいことを確信するための優れたテストを知っていることを望んでいます。求積法、導関数などは非常に簡単にテストできますが、他のことはわかりません。 私が過去に行ったいくつかのテストでは、内部法線を外部法線に追加しています。これにより、0または+ -2が得られます。コード変更の結果をすばやく確認できると便利ですが、インデックス作成でこれを行う意味のある方法は考えられません。 また、これらは四角形や六角形にも適用され、曲線要素の可能性があります。動作中のライブラリと比較する既存のコードはあまりありません。 比較するために既存の正解に依存しない、私が書ける優れた単体テストがある場合のボーナスポイント。私は多くの優れたヒューリスティックスで解決します。

8 software  testing  discontinuous-galerkin