制約とパフォーマンス

制約を設定したのに、制約を満たさない Trial があるのはなぜですか？

Tunny がソフト制約（Soft Constraints）を使用しているためです。

ソフト制約とは、「できるだけ満たすべきだが、必ずしも満たす必要はない」という最適化問題の制約です。 制約を必ず満たすことを求めるハード制約（Hard Constraints）とは異なり、違反した解も探索の過程に残ります。

主な特徴

1. 違反の許容
   1. 制約に違反できます。
   2. 違反した場合は、ペナルティによって制約を満たす方向へ解を導きます。
2. ペナルティの仕組み
   1. 制約違反の度合いに応じて、ペナルティスコアが割り当てられます。
   2. このペナルティは目的関数に組み込まれ、最適化の際に考慮されます。
3. 実用上の利点
   1. 現実の問題では、すべての制約を完全に満たすことが難しい場合も多くあります。
   2. ソフト制約を使うと、より実用的な解を見つけられます。
   3. 探索空間が広がり、より良い解を見つけられる可能性が高まります。

制約を満たした Trial だけを取り出したい場合は、Output タブの Feasible を使用してください。 Tunny では Constraint に入力した値がすべて 0 以下のときに実行可能と判定されます。 たとえばある評価値を 100 以下に収めたい場合は、その値から 100 を引いたものを入力することで、制約を満たすときだけ 0 以下になります。

Wallacei や Galapagos などの他の最適化コンポーネントと比べて遅いのはなぜですか？

デフォルトでは、Tunny は Rhino がクラッシュしても最適化を再開できるように、各 Trial の結果をそのつど結果ファイルへ書き出します。 この I/O 処理のため、他の最適化コンポーネントより遅くなります。

より高速に動作させたい場合は、InMemoryMode の使用をおすすめします。 最適化の途中ではなく最後にすべての結果をまとめて保存することで、この I/O 処理を減らせます。

ただし最適化中は結果が保存されないため、途中で中断した場合はそれまでの結果を確認できなくなります。

モデリングなどが意図通りに動作しない場合に、最適化の Trial を無効にすることはできますか？

Construct Fish Attribute コンポーネントで、IsFail という名前の Attribute を作成できます。 これに True が含まれている場合、その Trial は失敗として扱われるため、値が求められなかった変数の組み合わせを最適化の評価から切り離せます。 属性名は大文字に変換してから比較しているため、ISFAIL のように大文字と小文字が違っていても同じ属性として認識されます。

注意点として、BO-GP のように次の探索点を決めるためにサロゲートを使う手法では、失敗しても同じ点を繰り返し探索することがあります。 これは、失敗が最適化ソルバーに情報を与えず、その Trial が良かったのか、悪かったのか、失敗したのかの手がかりが得られないためです。