オープンＣＡＥコンサルタントOCSE^2

（本記事は執筆予定本の下書きにて、工事中の内容である点ご承知おき下さい）

7-2. DAKOTA

DAKOTAというのは、Paraviewと同じく、SNL（米国、サンディア国立研究所）で開発されたオープンソースの最適化システムで、最適化や感度解析、パラメータ同定、信頼性解析など、計算パラメタを自動変更する仕組みが多数搭載されているソフトウェアである。

現在公開されているホームページは2014年に開設されたもので、それ以前の情報は今となっては見当たらないが、筆者がOpenFOAMを使い始めていた頃にはすでにこのDAKOTAも公開されていたような記憶があり、この最適化の分野のソフトウェアが数少ない中でも老舗的存在である。

その後も、ほぼ半年に一度の更新で、執筆時点では、Ver-6.12に至っている。DAKOTAの本体は、基本的にコマンドライン操作で使用するツールであるが、GUIツールも併せて公開されている。とはいうもの、このGUIツールに関しては、一貫性がなく、数年に一度のタイミングで、大きく使い方が異なってしまっているという印象である。

古くから公開されていたGUIツールは使い方がよくわからなかった。一時は、GUIツールの公開が途絶え、CUIでしか使えないツールとあっては、見送るしかない時期もあった。しかし、6.7（2014/11）以降で公開されたGUIツールで、ようやく使えそうな感触が得られて、DEXCS2018をベースにその時点での最新ヴァージョンを構築した環境で講習会などで活用方法を紹介してきた（講習会1, 講習会2）。

しかしながら今回、DEXCS2019をベースに最新ヴァージョンでの更新を試みたが、6.10以降のGUIは大きく（？）更新されたようであり、一部のGUIが正しく動作しないことが判明した。

特にグラフのプロットツールが変化したようであるが詳細は不明である。というのも、公開されているhtmlマニュアルによれば、

Note: Currently, the Dakota GUI fully supports Chartreuse plotting on Windows and Mac. On Linux, Chartreuse plotting is limited to 2D and only supported on recent Fedora-based distributions, such as RHEL7/CentOS7.

と、Linuxも、CentOS系で2Dプロットしか動かないとあり、DEXCSで試したところ、やはり動かない事が確認されたからである。因みに、CentOS7、Windows10、Macでも動作確認したが、これらの環境でも若干の相違はあったものの同様であった。そもそも、プロットツールを起動する方法（メニュー）が、6.10以降は、6.9以前とは明らかに異なっていた。マニュアルの目次内容も大きく変化していたのに対し、細部の項目（たとえばプロットツールを起動する方法）で見ると、内容が古いヴァージョンのままであるとしか思えない状況であった。ひょっとして単なるマニュアルの不備で、記載されていない正しい使い方があるのかもしれないが、公開情報もなく、現時点では探りようがない。

したがって、現時点では最新版のGUIを使えるという状況ではないが、その後の調査で、GUI版と、DAKOTAの本体のヴァージョンを合致させる必要はなく、異なるヴァージョンの組み合わせであっても動作する事は確認できた。

そこで、本項では、DEXCS2019に、DAKOTA本体の最新版（6.12）をインストールし、GUIは6.9を使ったシステムを構築し、その活用例を紹介することする。

ダウンロード〜インストール（DAKOTA本体）

DAKOTAダウンロードのページより、DAKOTA本体のソースコード（UI付き）最新版（dakota-6.12.0-release-public.src-UI.tar.gz）をダウンロードして、任意のフォルダ（本例では、~/work）内で解凍しておく。解凍方法は、ファイルマネージャーでダウンロードしたファイルを選択して右クリック⇒「ここで展開する」で良い。

インストールの方法は、Build (compile) from Source Codeのページに記してあるが、DEXCS2019では、インストールに必要なツールやライブラリーは全て実装されているので、直ちにConfigure作業（cmake）に取り掛かって良い。

ここでオプション、-DCMAKE_INSTALL_PREFIX=/opt/dakota は、インストール先を指定するもので、その場所は好みに応じて任意に変更して良い。

cmakeに成功したら、引き続きmakeコンパイル

オプション-jの後に続く数字はプロセッサの数で、これも環境に応じて変更する。コンパイルに必要な時間は10分程度で、成功したら、念の為、testフォルダにて、テストコマンド（ctest）を実行する。

上記のように出力されれば問題いので、インストールして完了である。

DAKOTA-GUI

DAKOTA-GUIはJAVAプログラムなので、Linux用GUIオンリー（dakota-6.9.0-release-public-linux.x86_64-GUI-only.tar.gz）をダウンロードして、任意のフォルダ（本例では、~/work）内で解凍すれば、そのまま実行できる。

但し、JAVAとひとくちにいっても様々なヴァージョンがあって、DEXCS2019に搭載されているJAVA（openjdk-11-jdk）では、6.9.0以前のGUIはエラーになってしまうので、動作可能なヴァージョンをインストールして切り替える必要があった。事前の調査で、openjdk-8-jdkで動作確認できていたので、これを使うことにする。

まずは、java のヴァージョンを確認する。

openjdk-11-jdk　が使われているとわかるので、

として、openjdk-8-jdk　をインストールする。但し、インストールしただけでは有効にならないので、

（注）上記1行目は、–config となっていますが、– –config　（ハイフンは2つ）です。

java の優先順を切り替える作業が必要である。これによって、以下確認できればOKである。

javaの切り替えが完了したら、ダウンロードして解凍して出来るフォルダ中にあるDakotaUIをファイルマネージャにてダブルクリックすれば、以下のようにしてDakota-GUIのオープニング画面が現れるはずである。

このまま続ける事も出来るが、一旦終了（③⇒④）して、DEXCS的な使い方が出来るように、起動用ランチャーを作成しておこう。

まずはプログラム本体の置き場所であるが、以下のようにして、DAKOTA本体のインストール場所にマージするようにした（これは、CentOSでバイナリーインストールした際の収納イメージと同じ構成になる事を意識したもので、必ずしもこうする必要はない）。

これをアプリケーションとして登録するには、

として、dakota.desktop というアプリケーションファイルを作成する。その内容は、

[Desktop Entry]
Type=Application
Name=Dakota GUI
Exec=/opt/dakota/gui/DakotaUI
Icon=/opt/DEXCS/dakota.png
Terminal=false

としておく。5行目にて、アイコンファイルを定義しているが、見分けがつくものであれば何でもよい。こうすると、dockランチャー最下段の①「アプリケーションを表示する」をクリックすれば、登録したアイコンが表示されるようになる。これをクリックして起動する事も出来るし、②右クリックして、③「お気に入りに追加」すれば、dockランチャーに新たなメニュー「Dakota GUI」として登録されるので、このメニューボタンを押して起動する事も出来る。

Dakota GUI の初期設定

ランチャーが作成出来たら、改めてこのランチャーを使って起動しよう。図7-2-1.で示したのと同様の起動画面が立ち上がるはずである。

具体的な例題演習の前に、初期設定作業が必要である。③「Window」メニューから、④「Preferences」を選択すると「Preferences」画面が現れる。

最小限必要な設定項目が２点ある。まずは、Dakota本体のPathを指定する（図7-2-4）。

もう１点は、Dakota例題の検索場所（Examples Search）の指定である。

これがデフォルトのままだと、非公開のサンディア研究所内のサーバーとなっており、アクセスできない（アクセス中にフリーズしてしまう）ので、local filesystem に変更しておく。

なお、以上の設定は、起動時のWorkspace毎に保存されるので、Workspaceを変更しなければ引き継がれる。

簡単な例題演習

Dakota GUI の操作方法については、window操作やメニューが複雑で、直感的に理解するのは容易でなく、もう少し後で操作方法の要点概要を説明するが、まずは簡単な例題にて、Dakota GUI の動作を確認してみよう。オープニング画面から、Dakotaに同梱されている様々な例題をインポート出来るようになっているので、これ①「Search the Dakota examples repository」を活用しよう。

検索画面が現れるので、とりあえず②「rosen」と入力して③「Search」ボタンを押してみよう。rosen.. というのは、rosenbrock関数という最適化問題のベンチマーク問題としてもっとも代表的なものを想定したもので、Dakotaにも多数のサンプルがあってヒットする、このうち、「rosen_multidim」を選択して⑤「Import」ボタンを押そう。

画面左欄の「Project Expl」画面に、インポートした「rosen_multidim」が表示され、左端の▶をクリックすると展開されて、rosen_multidim.inが現れる。これをダブルクリックすれば、その内容が表示されるようになる。ちなみに、この拡張子が、.inとなっているのがDakota制御ファイルであり、この内容に基づいてDakotaが自動計算するという仕組みになっている。

この内容については、全部で以下の6つのブロックから成っており、その内容は英語を読む感覚で理解できると思うが、以下簡単に説明しておく。

• environment
  • 結果の出力方法を定義
  • 本例では、tabular_data　とし、’rosen_multidim.dat’という名前が付けられる。
• method
  • 最適化や感度解析、パラメータ同定、信頼性解析など何をしたいのかを定義
  • 本例では多次元（2変数）パラメタスタディを 8 x 8 水準で実施
• model
  • モデル（Single, Surrogate, Adapted Basis）を定義
  • 本例ではSingle
• variables
  • 入力パラメタを定義
  • 本例では、x1,x2について、-2.0 から2.0の間
• interface
  • 計算ソルバーとの間のインターフェースを定義
  • 本例では、rosenbrock関数がdakotaの内部関数として使えるようになっており、これを直接使用する。
• response
  • 応答関数を定義
  • 本例では、関数出力のみ

要約すれば、入力、x1,x2について、-2.0 から2.0の間で各8水準のパラメタスタディをrosenbrock関数にて実施し、結果をtabular_data形式で、’rosen_multidim.dat’に保存せよ。というものである。

GUIを使わない場合には、上から3行目にコメント行（#で始まる行）で記してある、

という形でコマンド入力して実行するというものである。制御ファイルの名前（rosen_multidim.in）に加えて、出力ファイル名（rosen_multidim.out）や、計算ログファイル名（rosen_multidim.stdout）も指定する必要がある。

これをDakota GUI で実行するには、下図（図2-4-8）に示すように、

制御ファイルを①選択してマウス右クリックメニューから、②「Run as」⇒「Dakota」を選択するだけでよいということになる。結果は、Window下段に「Console」画面に出力される。Console画面の最初に、

/opt/dakota/bin/dakota.sh: 19: [: Linux: unexpected operator

というエラーメッセージが表示されているが、これはOSが使用しているシェルの問題で、ubuntuの標準シェルがdash になっているのに対し、bash を使う設定になっている為と思われる。エラーメッセージがあっても実害は無いと思われるが、気になる人は、以下のようにして標準シェルを変更して使うとよい。

計算が終了すると、「Project Expl」画面に、「run_results」 というフォルダが出来ており、これを展開すれば、「rosen_multidim.dat」というファイルを確認できる。これは、制御ファイル中の、enviromentブロック内で定義したもので、tabular_dataであるので、ダブルクリック表示でその内容を確認できるとともに、以下に示す方法で簡単にグラフ化も出来る。

「rosen_multidim.dat」を選択して右クリックメニューにて、「New」⇒「Plot template from this file」を選択すると、テンプレート選択画面が現れるので、ここでは③「iteration History」を選択した。引き続き「Plotting Template」画面が現れる。中段のChoose an orientation が未選択状態なので、これを④「Horizontal」にすれば、最下段の⑤「OK」ボタンが有効になるのでこれを押せば、下図、Plot Window Managerが現れ、①「Plot」ボタンを押せばグラフ化される。

②全画面表示をクリックすれば、グラフの全体が下図のように現れるはずである。

Dakota GUI とは

一通りの動作確認が出来たところで、ここで改めてDakota GUI とは何か？について、使い方の要点も含めて整理しておこう。但し、これはあくまで筆者の主観であり、マニュアルや公式ページ等に記載されたものでない点は留意されたい。

プロジェクトの作成・実行支援

先に、拡張子（.in）のファイルを制御ファイルと読び、Dakota GUI はこのファイルがあれば、これを対象に実行するのにコマンドラインでなく、ボタン・メニュー操作で実行制御し、グラフ化などの結果の後処理もしてくれたという機能を紹介した。

先の例題では、もっとも簡単な例題として、制御ファイルが存在するだけで実行可能なプロジェクトであったのに対し、実行ファイルや入力ファイルが必要なプロジェクトもある。むしろそれが通常である。そういったプロジェクトを作成するのに様々なウィザード式の支援ツールが用意されている。但し、このウィザードには入口も選択肢もたくさんありすぎるので（図7-2.12〜14）却って使い難くなっている面もあるが・・・

制御ファイル（.in）作成支援

一方先の例題では、既存の制御ファイルを対象にしたが、この制御ファイルが存在しない場合や、作り替えたい場合などに、作成支援の機能も豊富に備わっている。すなわち、元々テキストファイルであるが、これを専用エディタで編集作業する事により、構文を解釈し配色を変えて表示したり、文法間違いなどあればエラー表示してくれたりもする（図7-2-15.）。

また、Settings画面（図7-2-16.）と併用する事により、代替コマンドを探したりする事や（図7-2-17.）、マニュアルを参照することも出来る（図7-2-18.）。

インタフェース作成支援

先に制御ファイルの説明で6つのブロックから構成されるとしたが、それらの中で、他のアプリとの連携という点で問題となるのが、interfaceブロックであろう。先の例題では、dakotaの内部関数を直接使用していたのに対して、通常の課題ではそうはなってくれないからである。特にdakotaと連携アプリ間で、入出力ファイルをどう取り扱うかを定義しておく必要があり、これは個別の問題に応じてカスタマイズするしかない部分でもある。

筆者の知る限りではあるが、このやり方に大きく4つの方法があり、一つは先の例題でみた内部関数を直接使う方法であるが、その他に、

1. drivers.sh
2. python -m DakotaDriver.py
3. SAW_DRIVER

といったものがあり、1番目の方法は、シェルスクリプトで、入出力ファイルを処理するものであり、名前は何でも良い。次節で、簡単な例題（片持梁の問題）で具体的に紹介する。

2番目の方法は、python処理によるもので、DakotaDriver.pyというモジュールを作成してそれを使うものであるが、このモジュールを作成するのに、Dakota GUI はウィザードで作成支援してくれるというものであり、ヴァージョン6.7まではこの方法がGUIの主流であった。

しかしながら、ヴァージョン6.8以降、ワークフロー（ブロック図）方式のプロジェクト制御出来る仕組みが用意される事となり、その仕組みを使ったインタフェースをブロック定義し、これを使うというのがSAW_DRIVERである。

DEXCS的な使い方を考えれば2番目か3番目の方法となるところであるが、そもそもインターフェスを作るというのはどういう事なのかを具体的に理解する事が重要であるので、まずは、簡単な例題（片持梁の問題）で1番目の方法を演習する。

その後、同じ例題のinterfasce をDakota GUI で作成する事を試みるが、紙面の関係と、今後の動向として3番目の方法が主流になると考えられるので、ワークフロー方式の作成法について演習する。

今後の動向として2番目の方法でなく、3番目の方法が主流になるとしたのは、作業全体の概要や個々のブロックの役割が直感的に理解しやすいのと、一度このワークフロー方式の雛形を作っておくと、その使い回しが簡単である点が最大の理由である（と筆者は考えている）。

本書の主眼である、OpenFOAMのジョブを制御するに際しても、上記で作成した雛形を使って一部分を改変するだけで、ジョブ制御を実施できるように工夫してある点を理解できるであろう。

簡単な例題演習その2

それでは早速、簡単な例題（片持梁の問題）を実施してみよう。この例題も標準例題として用意されているものであり、具体的な実行内容は後で詳しく説明するとして、まずは以下の手順で動作出来る事を確認されたい。

プロジェクト作成は、「File」メニューの「New」⇒①「DakotaProject」にて、

②空欄のProjectNameに、適当な名前（本例ではcantilever）を付けて、③「Next」ボタンを押すと、ウィザードにて、drivers,等のフォルダを作成するかどうかの確認画面が現れる。これらのフォルダは、インターフェースのpythonモジュールをウィザード形式で作成する場合に使われるもので、本例では使わないので、④「No,…」とし、⑤「Finish」ボタンを押す。

これで、Project Exploler 上には、cantilever というプロジェクトフォルダだけが追加された事になるが、これを①選択してマウス右クリックメニューから、

②「Import」を選択すると、何をインポートするのかを選択する画面が現れるので、「General」⇒③「File System」を選択して、④「Next」ボタンを押す。そうすると具体的なファイル選択画面が現れるので、⑤「Browse」ボタンを押して現れるファイルフォルダ選択ダイヤログから、⑥/opt/dakota/share/dakota/examples/training/drivers/cantilever のフォルダを選択する。上記フォルダ中には、cantileverを始めとして全部で6つのファイルが存在するが、この内 driver.ps1 を除いて（注記1）⑦選択し、⑧「Finish」ボタンを押す。

指定したファイルがProject Exploler 上にインポートされるのを確認出来たら、最初に実施した例題と同じで、拡張子（.in）の付いたDakota制御ファイル（dakota_cantilever_center.in）をそのままでも実行出来るが、後の説明を分り易くする為、その内容を少々変更しておこう。

dakota_cantilever_center.inを①ダブルクリックして、内容表示させ、interface/analysis_drivers/forkブロックの最下行に、以下の2行を追加する。

file_tag
file_save

追加したら、③ファイル保存し、Dakotaを、ここでは④の「Run dakota_cantilever_center_in」ボタンを押して実行している（図7-2-8.の右クリックメニューからのやり方でも構わない）。

実行が始まると、⑤Console画面に実行ログが表示され、ほんの数秒で実行完了、Project Exploler 上では、赤色の矢印で示したフォルダやファイルが生成される。

本例でも、結果のまとめは、tabular形式のデータとして、dakota_tabular.datが作られているので、

これを選択して①マウス右クリックメニューから、図7-2-9.で実施したのと同様（但し選択メニューは異なる）に、プロットウィザード（②〜⑤）を使って下図の図化例が得られた。

例題2の解説

まず本例の対象としている計算モデルであるが、材料力学のもっとも基本的な公式で計算される片持ち梁である。

これらを入力変数とした場合の、mass（梁の質量）、stress（最大応力）、displacement（最大変位）を計算するもので、計算はcantileverというpythonプログラムが担っており、132行目以降にその内容を確認できる。

area = params["thickness"] * params["width"]
mass = area * params["density"] * params["length"] / 123.0 
stress = 6.0params["length"] / (areaparams["thickness"]) * params["vertical_load"] + \ 6.0params["length"] / (areaparams["width"]) * params["horizontal_load"] 
displacement = 4.0params["length"]3.0/(areaparams["youngs_modulus"]) * \
math.sqrt(
(params["vertical_load"]/params["thickness"] ** 2.0)**2.0 +
(params["horizontal_load"]/params["width"] ** 2.0)**2.0
)

一方、dakota_cantilever_center_in のDakota制御ファイル（Dakota Study）中では、variablesブロック中で、

として変数名とその初期値を定義し、responseブロックで、

3つの目的変数を定義している。

パラメタスタディの方法は、methodブロックにて、

初期値を中心として、各変数毎に片側増分ステップ数（steps_per_variable）と、増分値（step_vector）を定義し、結果をtabular_data 形式にて出力する（environmentブロック）というもので、結果をグラフ化（縦軸が目的変数、横軸は増分ステップ）したものが、図7-2-23.になったという次第である。

問題は、計算プログラム（cantilever）とDakota間のインタフェースをどうやって関連づけるかであり、interfaceブロックにて定義されている（見易くする為、Windows環境用のコメント行は削除してある）。

最下行の、asynchronous… は同時に実行するジョブの数を指定するもので、指定がなければ、逐次実行されるだけである。

最初の行で、analysis_drivers　として、driver.shを使うとの指定があり、これはインポートした際に同梱されていたもので、その内容は後でまた詳しく説明するとして、その下のfork以下は、driver.shを実行する際のオプションともいってよい設定で、

• work_directory として’wokdir/run’ というディレクトリ内で実行
• directory_tag（そのディレクトリには実行順番号を付与する）
• directory_save（ディレクトリを残す）
• link_files ‘cantilever.template’ ‘cantilever’（シンボリックファイルを作成）
• parameters_file ‘params.in’（Dakotaが出力する変数ファイル）
• results_file ‘results.out’（Dakotaが受け取る結果ファイル）
• file_tag（上記２つのファイルには実行順番号を付与する）
• file_save（上記２つのファイルを残す）

という意味になり、Project Explore にて、workdirフォルダを展開すれば、上記の指定した通りに、run.# フォルダや、params.in.#, results.out.# （#は実行順番号）といったファイルが出来ており、それらの内容も確認できよう（図7-2-25.）。

最後に、analysis_driversのdriver.shであるが、英文のコメント行を省くと、以下の10行程度のスクリプトになっていることが判る。

$1, $2 というのは、このスクリプト（プログラム）が実行された時に、引数として与えられたテキストの内容で、このスクリプトが実際にどういう形でコールされているのかという明示的な説明は見当たらないが、多分、

として、<parameter_file>, <results_file>の具体的内容は、先の制御ファイル中のinterfaceブロック内で定義された内容が使われているものと推察される。これにより、本例では、$paramsの部分をparams.in、$resultsの部分をresults.out と読み替えて解釈できる事になる。

つまり、次の、dprepr…の行は、

• dprepro params.in cantilever.template cantilever.i

を実行するという意味になる。この内容について興味の有る方は注記2を参照して頂きたいが、DEXCS的にはGUIで使用できるようになる事を最終目標にするのでこの処理内容を具体的に理解できなくともよい。ここではDakotaが出力したparams.inというパラメタファイルから、cantilever.iというcantileverプログラムに対する入力ファイルを作成しているものしておけばよい。その後、

• ./cantilever cantilever.i > cantilever.log

によって、cantileverプログラムが実行され、結果はcantilever.logに出力される。

mass=… 以下の行も少々ややこしく詳細の説明は省略するが、cantilever.logの内容を読み取って、目的変数の計算結果の値の部分を切り出して、echo…以下の行で、その値を、results.outというファイルに出力するという内容になっているという理解で良い。この部分も、GUIで使う場合には代替手段で出来るようになる。

以上見てきたように、インターフェースをスクリプト処理にて実行するには、説明を割愛した部分、すなわちDakotaのパラメタファイルをシミュレーションの入力ファイルに変換する部分と、シミュレーションの計算結果のログからDakotaへ結果として渡す部分で、シェル等に関する高度な知識が必要になる点を理解していただけよう。

逆に云えば、シェルを高度に使いこなせる人であれば、この方式を使うのが最も簡単になる事も間違いないので、その方向を目指すのも有りだとは申し添えておく。

この部分を、GUI操作で出来るようにしてくれるのが Dakota GUIであり、以下本題材をベースに、ワークフロー方式GUIで実施する方法について説明する。

ワークフロー方式GUIの例題説明

まずは先に実施したのと同じ方法（図7-2-19,20）で空のプロジェクトフォルダ（本例では、cantileverWF）を作成しよう。作成したら、先に実施したプロジェクトフォルダ中の3つのファイル

• cantilever
• cantilever.i
• dakora_cantilever_center.in

をコピーしておこう。

引き続き、dakora_cantilever_center.in　の制御ファイルを開いて、interfaceブロックの、analysis_drivers が、’driver.sh’とあった部分を’SAW_DRIVER’に変更して保存しておこう（図7-2-27.）。

以上で準備完了。つまりシミュレーションモデルの本体（本例ではcantilever）とそれを実行できる周辺モジュール（本例では入力ファイルとなるcantilever.i）、それにDakota制御ファイルがあって、interfaceブロックの、analysis_drivers が、’SAW_DRIVER’になっているという状況であり、これから、SAW_DRIVERをGUIで作成しようということである。

なお、このGUI作業を実施するに際しては、Perspectiveと呼ばれる作業環境の中、Next Gen Workflow を有効にする必要がある（図7-2-28.）。

2通りのやり方があるが、①「Windows」メニューから、「Perspective」⇒「Open Perspective」⇒「Other…」または、画面右上方の②「Open Perspective」ボタンを押して、「Open Perspective」の画面が立ち上がったら、③「」を選択して④「Open」ボタンを押す。そうすると、画面右上方に、⑤「Next Gen Workflow」のアイコンが表示され、これが使えるようになった事がわかる。

そして、これが使える状態になったら、新しいワークフローの作画画面を立ち上げ（図7-2-29, 30）、SAW_DRIVERの作成作業に入る事が出来るということである。

また、ワークフローを作成するに際しては、以下の作図法の基本を抑えておこう。

1. Palette にて作図用の部品を選択
2. 作図画面でクリック⇒上記で選択した部品が配置
3. 部品ブロックはマウスクリックで選択、部品以外の部分をクリックして非選択
4. 選択ブロックの配置場所やサイズはマウス操作で任意に変更可能
5. 選択ブロックに応じたSetting画面にて詳細設定

なお、このSAW_DRIVERを使ってDakotaによる計算制御を実行するには、Dakotaの計算そのものを、Next Gen WorkflowのPerspective上で実行する事になるので、SAW_DRIVERそのものを作成する前に、Dakota制御ファイルに基づくDakotaの計算を実行（RunDakota）するワークフローを作成しておく必要があるので、まずはこれ（RunDakota.iwf）の中味を作成する。

まずは、①Pipes/Files　と、③Dakota/dakotaを作図画面に配置する（図7-2-31.）

Fileには、Dakota制御ファイルを割り当てる。

Run Dakota のブロックでは、dakotaのpathと、これから作成するドライバーの名前③NestedWorkflow.infを入力する。また、④のexpertMode にチェックも必要（詳細は不明だが、これにチェックしておかないと、うまく実行されない）。

最後に、２つのブロックを①マウスドラッグにて結線すれば完成である。

これで、ワークフロー上で、

を実行出来る事になる。但し、現時点では、SAW_DRIVERの実体（NestedWorkflow.inf）が何も無いので、エラーで終了する。

引き続き、SAW_DRIVERの実体（NestedWorkflow.inf）を作成しよう。新たに①Workflow画面を②「cantileverWF」プロジェクト中に、③「NestedWorkflow.inf」という名前でということになる（図7-2-35.）。

SAW_DRIVERの実体（NestedWorkflow.inf）は、dakotaで生成したparams.inファイルを受け取ってから、シミュレーションで実行結果からdakotaへ受け渡すファイルresults.out を生成するまでの手順をワークフローのダイヤグラムで作成する事になる。個別のブロック作成に際しては、先に完成状態（図7-2-45.）をイメージした上で、個々の役割について理解しながら作業するのが良いであろう。

各ブロックの名前と役割を以下に整理しておく。

1. params.in
   • Dakota が生成したパラメタファイル
2. DakotaParametersMap
   • パラメタファイルをマップ化
3. PositionalPreProcessor
   • パラメタマップ⇒入力ファイルの変換方法定義
4. cantilever
   • シミュレータのプログラム本体
5. cantilever_processed_i
   • シミュレータの実行時自動作成される入力ファイル
6. pythonScript
   • pythonScipt でシミュレーション方法を定義
7. QOIExtractor
   • 計算ログから評価結果取得方法を定義
8. DakotaResultsfile
   • 取得した評価結果をDakota用に変換
9. results.out
   • Dakota が受け取る結果ファイル

以下に、各ブロックの詳細作成手順を示しておくが、レイアウトやサイズは後で自由に変更可能であり、ブロック間の結線もすべてのブロックを作成し、レイアウトやサイズを決めた後で良い。

params.in

Dakota が生成したパラメタファイルであり、Dakota制御ファイル中　interfaceブロックの、parameters_file で定義されたファイル名で出力される。SAW_DRIVERはこれを受け取って、次の結線先ブロックでの処理を進める事になる。

ポイントは。③のファイル名であり、「Browse」ボタンも使えるが、これだけだと「特定ディレクトリ下のparams.in」としかならないので、ディレクトリの表記を「${workflow.workdir}/」とする必要がある点である。これは、Dakota制御ファイル中　interfaceブロックの、work_directory で定義されたディレクトリを意味する事になる。

DakotaParametersMap

Dakotaが生成したパラメタファイルを受け取って、様々な出力を可能にするブロックである。

出力ポートは各種用意されており詳細はよく判らないが、ここでは一番上のvaliablesを使う。具体的にどういう形で出力されるのか（どこかにマップ化して出力するという説明があった）詳細は不明であるが、Dakota制御ファイル中で定義したパラメタの変数名とその値が出力されるものと考えて良さそうである。

PositionalPreProcessor

受け取ったパラメタマップを使って、テンプレートファイルを書き直す。

テンプレートとするファイルは、cantileverプログラムに対するデフォルトの入力ファイル（cantilever.i）であり、これは③「Browse」ボタンを押して、ファイル選択ダイヤログから取得すれば良い。

次にSetting画面の最下段左端の①「Add Pre-processor」のボタンを押す。そうすると、先ほど選択したテンプレートファイルが、「Positional Parameter Selecter」という画面内に表示される。ここでたとえば、width を定義した行の②数値部分をマウスで選択する。そうするとParameter Default Value: の欄にその選択内容が表示されるので、選択に問題なければ、③Parameter Label:の欄に「w」を入力して、④「OK」ボタンを押す。

ここで、「w」としたのは、Dakota制御ファイル中、variableブロックで定義した変数名である。つまり、dakotaの出力するパラメタは、これらの変数名で出力されるので、それぞれの変数内容（ここでは数値）をパラメタファイルの何処に埋め込むのかを指定している。本例（w）では、widthの行のマウスで選択した部分に、ということになる。

本演習例題では、パラメタが全部で7つあるので、残りのパラメタについても同様のやり方で指定する。指定が完了したものは、表形式で一覧表示されるので全変数がリストアップされている事を確認しよう。1行毎に選択可能で、間違えたものは「Remove Pre-processor」ボタンで削除してやり直しても良いし、「Edit Pre-processor」のボタンを押せば「Positional Parameter Selecter」画面での設定内容がそのまま再現されるので、間違いの箇所を修正しても良い。

dakotaとソルバー間で、変数の受け渡しを具体的にどうやって実施するかで、一番面倒なのがこの部分である。シェルドライバーでは、dpreproというコマンドを使えるべく、cantilever.templateというファイルを予め用意しておく必要があったが、SAW_DRIVERでは、デフォルトの入力ファイル（cantilever.i）をベースに、かように手作り出来るということである。

cantilever

シミュレータのプログラム本体である。これも③「Browse」ボタンを押して、ファイル選択ダイヤログから取得すれば良い。

cantilever_processed_i

シミュレータが実行時に使用する入力ファイルである。PositionalPreProcessorで処理した内容が、このファイルに書き込まれる事になる。

名前（cantilever_processed_i）はこの通りである必要は無いが、work_directory内に作成しないと意味が無いのでディレクトリの表記に③${workflow.workdir}/を付加する必要がある。

pythonScript

シミュレータをpythonスクリプトで実行する方法を定義している。

③scriptの内容としては以下入力する。

pythonの知識が無いと意味不明かもしれないが、subprocess という別のプロセスを呼び出してプログラムを実行している。ほとんど決まり文句のようなものだと思ってコピペして使えば良い。要点は赤太字で記した部分（’python’,f1,f2）で、

pythonでf1というプログラムをf2というパラメタで実行する

という意味になる。したがって、f1, f2 という２つの受け口が必要で、④「Input Ports」のタグ画面にて、⑤「Add」ボタンにて、２つのPortを追加した。これにより、⑦ブロック図の左側ポートに、f1,f2２つの受け口が追加されている。f1にプログラム本体のファイル（cantilever）、f2に実行時の入力ファイル（cantilever_processed_i）の名前（FileReference）が結線されれば所定のプログラムが実行される事になる。

なお、念の為記しておくが、シミュレータが代わった場合に、プログラム本体が必要な事は変わらないが、パラメタについては必要の無い場合もあれば、2つ以上必要な場合もある。ケースに応じてf2以下の部分は変更が必要である。

また、本プログラムはpythonプログラムであったので、’python’であったが、そうで無い場合には別の方法になるという点も留意されたい（OpenFOAMの例で後述）。

QOIExtractor

シミュレータの実行ログから、評価結果（応答関数）の値を切り出す作業をするブロックである。

本例での応答関数は３つ（’mass’,’ stress’,’displacement’）あったが、各々切り出し方法は異なる。図7-2-42-1.は’mass’について示したもので、③「Add QOIExtraction」ボタンを押して、④「mass」について、ログファイル中、「MASS」というキーワードを見つけたら、⑥2行下のフィールド値を取得するようにしている。

なお、本プロジェクト単独では実行前にログファイルがどうなるのかは想像するしかないかもしれないが、ここでは先のプロジェクト例題（cantilever）で実施した結果を参考にしている。これも無い場合には、別途プログラムを実行してログファイルを確認するという作業は必要になろう。

以下、残りのパラメタ（’ stress’,’displacement’）についても同様に実施する。

DakotaResultsfile

QOIExtractorで取得した評価結果をDakotaが受け取りできるよう変換するブロックである。

results.out

実際に受け取った内容を結果ファイル（results_file）に落としこむブロックである。

これもDakota制御ファイル中　interfaceブロックの、results_file で定義されたファイル名（results.out）である点と、③${workflow.workdir}/を付加する必要がある点が要所である。

結線

ポートが複数あるブロックでは、それぞれのポートの使い方が異なるので、その意味・役割を考えて間違いのないように結線することが重要である。

計算の実行（ワークフロー方式GUI）

結線が完了したら、ワークフロー（NestedWorkflow.inf）を保存して、①メインのワークフロー（RunDakota.iwf）に戻って実行開始である（図7-2-46.）。

実行が正常に開始されると、実行中のブロックが④黄色で表示され。完了すれば⑤薄緑色に変わる。ワークフローが正しく作成出来ていない場合などは、エラーとなったブロックが赤色表示され、エラーメッセージも併せて表示される。エラーとなった場合の対処法については、後段の補足事項で取り纏めておいたので参考にされたい。

計算が正常に実行されれば、work_directoryで指定したフォルダ内に指定した名前のフォルダ（run.#）が作成され、各ケース毎のパラメタファイルや実行ログが出力されると共に、ルートディレクトリには、結果の総覧となる、tabular_data（dakota_tabular.dat）やworkflow.で始まる様々なファイルも作成される。

実行結果の確認と可視化

結果の総覧ファイル（dakota_tabular.dat）をダブルクリックすれば、各ケース毎に設定したパラメタ変数の値と応答関数の値を読み取る事ができる。また、③マウスの右クリックメニューから、様々なグラフを作成する事も可能になる。

なお、グラフを作成する方法は、詳細は後段の補足事項に取り纏めてあり、基本的に図7-2-22.で説明したのと同じ方法になるが、ワークフロー方式で実行する場合、plotting templates の設定画面において、図7-2-22.の場合と、若干異なり、Plot Data が特定されない。これは実行後のProjectフォルダ内の構成を見れば判るのだが、制御ファイル（拡張子が.inのファイル）が新たにもう一つ（internalDakotaInput.in）出来ている為、どちらに含まれるtabular_data を使うのか指定する必要があるということを示す内容である。

少々面倒だが、図7-2-49-1〜2.の①〜⑦の操作にて、プロット対象となる⑥Tabular Data_Set 1 を教えてやる必要がある、という事である。

OpenFOAMのジョブ制御演習

OpenFOAMのジョブ制御演習の例題としては、OpenFOAMの標準チュートリアル（$FOAM_TUTORIALS/incompressible/simpleFoam/airFoil2D）を改変した課題にて実施する。

このチュートリアルは、二次元翼周りの流動解析を実施するもので、メッシュは他のメッシュソフトで作成したものをそのまま使っており、概要を図7-2-50.に示す。

標準チュートリアルでは、風の向きと大きさが固定されているが、これらをdakotaでパラメタ制御出来るよう流入条件（0/U）を変更し、目的変数として抗力係数などの空力係数を計算できるよう、system/controlDict中に、forcesCoeffのfunctionブロックを追加した。さらにdakotaとのインタフェースを考慮してAllrunも少々改変した。

この改変はconstant/params.in ファイル中で定義したパラメタ（Uin, alpha）の値をdakotaで制御する事を想定したもので、codeブロックを使って、ある。。

流入条件（0/U）

本チュートリアルは流入、流出ともに、境界全域がfreeStreamVelocityの境界条件になっており、その速度（$internalField）を、Uin（主流速度）, alpha（迎角）を変数としてcode形式で記述した。

（Uin, alpha）の値は、constant/params.inp 中で定義してあり、dakotaでこのファイルの内容を書き替える事を想定している。

system/controlDict

標準チュートリアルでは空力係数を計算していなかったので、controlDict中に、functionsブロックを追加して、forceCoeffsを計算するようにした。

その際に、流入条件（迎角）が変わればドラッグやリフトの方向も変わるので、これら（70, 71行目）もconstant/params.inp 中で定義した変数を使ったcode形式で記述した。

Allrun

Allrunスクリプト変更の要点は、

• 2行目
  • OpenFOAMの環境を明示的に指定
• 6行目
  • 実行ログを指定しない（dakotaの仕組みで標準出力が保存されるので）
• 8，9行目
  • postProcessing/forceCoeffs/0/coeffcient.dat の最終行からCd,Cl の値を読み取って、出力する。

している点であり、特にCd,Cl値を正しく取得できているかどうか、実際にケースファイルを実行して確認されたい（図7-2-54.）。

なお次に説明するdakotaプロセスではこのケースファイルをそのままコピーして使う事になるので、実行ログを確認できたら、同梱のAllcleanスクリプトを実行しておくことを推奨する。計算結果やログのコピーは必要無いので。

ワークフロー方式プロジェクトの作成

先にも記したように、ワークフロー方式プロジェクトを作成しておけば、問題が変更された場合でも、作成したプロジェクトファイルをコピーして改変するという使い回しが出来るようになる。コピーして改変が必要になるのは、以下の3つのコンポーネントである。

• dakota制御ファイル（.in）
• RunDakota.iwf（dakotaをワークフロー上で動かす本体プログラム）
• NestedWorkflow.iwf（上記で使うSAW_DRIVERの実体）

まずは先に実施したのと同じ方法（図7-2-19,20）で空のプロジェクトフォルダ（本例では、airFoil2D）を作成し、制御ファイルを作成しよう。

本例では、先に実施したdakota_cantilever_center.inをコピーして改変しているが、パラメタスタディーの方法（method）を、centeredから、multidimに変更しているので、制御ファイルの名前も相応に変えてから内容を修正した。

制御ファイル（airFoil2D_multidim.in）の内容は以下の通りで、青字部分を変更してある。

method（制御方法）、variable（変数）, response（応答/目的） に関しては、一番最初に実施した演習例題（rosen_mutidim）を参考にして容易に推察できるであろう。つまり、Uin, alpha を変数として、Cd, Cl の変化を調べようというもので、変数範囲は、Uinが[10 〜30]を2分割（3水準）、alpha[-10 〜20]を8分割（9水準） 全27水準の計算を実施するものである。

interface の部分で、cantileverの例題では、計算に必要なファイル（プログラム本体と入力ファイル）をlink_files としてシンボリックリンク指定していたが、OpenFOAMの計算の場合には、ファイルの数が多いので、ここでは

copy_files ‘/home/dexcs/Desktop/airFoil2D/*’

として、ケースファイルの内容一式をコピーするよう指定した。先にケースファイルを実行確認した後、Allcleanにて初期化を推奨したのは、計算結果等までコピーしていたのでは余分な時間がかかってしまうからであった。

RunDakota.iwf

dakotaをワークフロー上で動かす本体プログラムは、制御ファイルの名前が変わったので、それに対応するだけである。

NestedWorkflow.iwf

SAW_DRIVERの実体に関しては、OpenFOAMの計算を実行する④pythonScriptと、その入出力周りで変数名や切り出し方法の変更に対応するだけで、結線はそのままの状態で使用可能である。

PositionalPreProcessor

dakotaから出力される変数をテンプレートファイルのどの部分の数値を置き換えるかを指定するブロックで、とりあえずはcantilever用に設定してあった条件を②「Remove Preprocessor」ボタンを使って全て消去する（図7-2-58-1.）。もしくは、このブロックを一旦削除して、新しく作り直しても良い。但し、その際には再結線の作業も必要になる。

テンプレートファイルとしては、テンプレートケース（Desktop/airFoil2D）に同梱した、constant/params.Template を使用する。このファイルの中味は、同梱のparams.inp と全く同じものである。

このケースでは、変数の名前をdakotaとOpenFOAMの間で同じにしているので、修正は容易であろう。

cantilever⇒Allrun

プログラムの実行スクリプトが、Allrunに変わったので、その名前を変更しているだけである。但し、Allrunはその実体が存在するケースファイルでしか実行できないようになっているので、②filname のところで、

${workflow.workdir}/Allrun

と、${workflow.workdir}を追加している（copy した、work_directory中で実行する）点が、cantilever の場合と異なっている。

cantilever_processed.i⇒params.inp

PositionalPreProcessorにて、params.Template の数値部を置換された内容が、constant/params.inp　ファイルに書き込まれる。これもcopy した、work_directory中で実行するので、②filename部では、${workflow.workdir}を追加している

pythonScript

OpenFOAMの実行ファイル（本例ではAllrun）を起動するpythonスクリプトである。cantileverの場合は、cantileverもpythonスクリプトであったが、Allrunはシェルスクリプトなので、パラメタ中、pythonの部分をbashに変更する。また、2番目の引数f2は不要なので削除する（残しておいても実害はない）。但し、Input Ports のf2は残しておいて、結線も残しておく事。そうしないと、dakotaによるf2（params.inp）の書き替えが終わる前にOpenFOAMが実行されてしまうので要注意である。

QOIExtractor

実行ログから目的変数を抽出するブロックである。これもPositionalPreProcessorと同様、cantilever用の設定を削除してから、

改めて、Cd, Cl について抽出方法を指定する。実行ログ（図7-2-56.）を参考にして容易に設定できるであろう（注記3）。

なお、Output Ports にcantileverで設定した変数が残っているが使用しないので実害はない。「Output Ports」のタグ画面で、削除する事も可能である。

修正後のワークフローイメージ

cantileverの場合と比べて、Fileブロックの名前が変更になっているだけである。

実行結果と可視化例

航空分野ではお馴染みの空力係数の特性図が得られ、流速依存性も少ない（迎角大の失速領域を除く）事が見て取れよう。

OpenFOAMのジョブ制御演習2

前項では、dakotaでOpenFOAMのジョブ制御といっても、単にパラメタスタディを自動実行しただけであったが、引き続き同じOpenFOAMのケースファイルを使って、Dakotaの本領とでも云うべき最適化問題についても演習してみよう。

先のパラメタスタディの結果から、Cl（揚力係数）について最大値の存在が予想されるので、この極値探索が課題として適切と思われる。

なお、物理的には最大値を探索する事になるが、数学的な極値探索問題は、最小値を探す事に帰着するのが一般的なので、本演習でも、Clの値そのものでなく、符号を反転させた値で評価する事とする。その為、system/controlDict中のCl値を計算する部分（図7-2-52.）において、以下のように、リフト方向（liftDir）を反転させておこう（朱字部分が追記変更箇所）。

まずは先に実施したのと同じ方法（図7-2-19,20）で空のプロジェクトフォルダ（本例では、airFoil2D-optCl）を作成し、先に作成したairFoil2Dプロジェクト中の３つのファイルをコピーしておこう。

• dakota制御ファイル（.in）
• RunDakota.iwf（dakotaをワークフロー上で動かす本体プログラム）
• NestedWorkflow.iwf（上記で使うSAW_DRIVERの実体）

dakota制御ファイル（airFoil_multidim.in）の名前はこのままでも構わないが、後学の際に名が体を表すようにしておくのが良いであろうから、ここでは、airFoil2D_optCl.in と変更した。

また、制御ファイルの内容そのものも、以下のように変更した（朱字部分）。

ちなみに、methodが、conmin_frcg となっており、初心者にとっては全く意味不明の用語であろう。公開例題等で比較的よく使われているものなのでここでも採用したのであるが、下図に示すように、Setting画面からプルダウンメニューを使って選択可能、またヘルプ画面も参照できるので活用されたい。

このSetting画面の情報から、Optimization Local, Delrivative-based（ 勾配法に基づく局所最適化手法）の一つである事が読み取れよう。

また、Delrivative-basedであるから、resposesブロックにおいて、先の例題では、no_gradientとなっていたが、そのままではエラーになる。その際のエラーメッセージでいくつか候補が表示されるので、そのうちの一つを採用したという事である。

また同じくresposesブロックにおいて、先の例題で、「response_functions = 2」であったのが、「objective_functions = 1」となり、descriptors が’Cl’だけになったのは、説明するまでもないと思うがどうであろう。

ワークフロー図で修正が必要になるのは以下の2箇所であるが、作業手順は先に実施した方法と同じであるので詳細説明は省略する。

• メインのRunDakota.iwfでは、制御ファイル名が変更しているので、それに応じてブロック名を変更する（図7-2-56.）
• NestedWorkflow.iwfでは、QOIExtractorのブロックで、Cdの切り出し部分を削除する（図7-2-61-1）

以下、実行結果と結果の可視化例を紹介しておく。

以上、DakotaGUIを使って、5つの例題演習を実施した。これによりDakotaGUIもある程度は使えるものになっていると判断しているのであるが、いかがであろうか。とは云ったもの本書に示した手順通りにすんなり実行できたかどうか、多分、ほとんどの人が途中でつまずく箇所があったんではないかという点も推察している。

補足事項

そこで、ここでは初心者がつまずきやすい点について、また不具合点もあるので、以下に取り纏めておく。

ワークフロー実行時エラーの対処法

本書の例題演習を実施したはずなのに生じてしまうという実行エラーの大半は、スペルミスか、結線の間違いに起因するものなので十分に確認されたい。

基本的には、エラーメッセージが表示されるので、それを読んで不具合箇所を調べると、スペルミスや結線間違いが見つかる事が多い。

エラーメッセージがjavaエラー…云々で意味不明な場合も多々あるが、そういう場合は、workflow.status.logや、workflow.engine.logを調べる事で不具合箇所が判る事もある。また、workdir/run.#フォルダが作成されるので、その内容を調べる事で、どこまで手順が進行しているか、またparams.inやresults.outの内容を調べて、意図した通りの値になっているかどうかを調べるというのも方法である。

Window操作

FreeCADの場合にもそうであったが、たくさんの画面があって、その配置はユーザーの好みによって自由に配置が可能である。但しその配置を変更する方法については、FreeCADの場合と比べると、いささか異なっており、こちらの方がやや判り難い点のある事も理解しておくと、戸惑う事もなくなると思われる。

「Window」メニューから、「Appearance」「Show View」といったあたりのメニューの使い方を実際にひとつずつ試しながら、どういう事になるのか確認する事を推奨する。また、それらの操作は、画面上のアイコンボタンの操作でも代用できるので、併せて確認するなど。

複数の画面レイアウトにおいて、画面サイズの変更（画面境界をマウスでドラッグ）は一般的なやり方と同じであるが、画面を移動する際にはFreeCADとはかなり異なる操作感（ドラッグ先でマウスアイコンが変化しないなど）がある点や、分離した画面を元に戻す際のドラッグ方法にも特徴があって、これに習熟することも必要であろう。

グラフ化法の要点

そもそもグラフ化する際のウィザードメニューがいくつもあって、何を選択すべきか戸惑う箇所も多い（図7-2-67.）。

かように、どこから始めるかによって多くのやり方があるように感じてしまうが、実体は複数のグラフをまとめて表示するか、単一のグラフだけを表示するかの違いであり、複数のグラフをまとめて表示したい場合に、ブランクの画面レイアウト（メニュー1）から始めるのか、それともグラフの種類（メニュー1’）から始めるかの違いでしかないという点を押さえておこう。

つまり、「メニュー１」から始めたとして、①「Choose a plotting template」のアイコンボタンを押して、「メニュー1’」を使う事になるだけの事である（図7-2-68.）。

また、「メニュー1’」にて選択したテンプレートに応じて、引き続き現れる設定画面もまた変化するので、これらの多様なメニューに戸惑う事もあろうかとは思うが、入口の多様性に惑わされないようにする事が肝要である。

「メニュー２」（単グラフ）から始める場合においても、こちらでは選択するのがTemplateでなく、Plot Type のプルダウンメニューになっているというだけの違いと思って使えば良い。

なお、Plot Type メニューの中には、…3D Plot の選択メニューがあり、公開マニュアルの何処かに記してあったが、Linux版では3次元グラフが機能しないとあった。実際に確認したところ、完全には機能しないというのが実情のようである。たとえば、色の濃淡が表示されないなど（図7-2-71.）。

また、Plot view の画面が小さい状態でグラフを表示させようとすると、クシャクシャの画面になってしまい何が何だかわからない。画面最大化ボタン、あるいは画面を独立画面とし適当なサイズにした状態から、再描画ボタンを使うという、もうひと手間が必要なものだと思って使用されたい（図7-2-72.）。

不具合事項

• ワークフローを使うプロジェクトにおいて、グラフ化後に、フォルダアイコンの左下隅に、ｘマークが付いて何らかの不具合を知らせてくれる。調べるとワークディレクトリ中の、params.inまでたどり着くが、意味不明である。また、これが出たからといって、実害もなさそうではあるが。

• パラメタの探索範囲などを変更した際に、tabular_datが更新されているのに拘わらず、グラフ化しても更新前のデータでグラフ化されてしまうことがある。
  • 「File」 ⇒ 「Restart」にて解消できる

注記

注記1：

driver.ps1は、Windows環境で使用する場合に使うファイルで、インポートしても実害は無い。

注記2：dpreproについて

dprepro params.in cantilever.template cantilever.i

の実行内容を、もう少し詳しく説明すると、Dakotaが出力したparams.inというパラメタファイルから、cantilever.templateを雛形としてcantilever.iというcantileverプログラムに対する入力ファイルを作成する。

cantilever.templateもテキストファイルなので、その内容を確認できるが、

となっており、cantilever.iの数値部分が中括弧で括られ{w=1.0}などに置き換えられた内容になっている。dakotaの出力したparms.inの中にwがあったら、その数値内容を、{w=1.0}の部分に置き換えて、cantilever.iを作成してくれるというものである。

なお、このプログラムはdakotaに同梱されたシェルプログラムで（perl版も）あるが、dakotaの環境でなくとも単独で動作する。簡単なパラメタの自動変更したい場合に、dakotaをインストールして使うほどでないとして、これをコピーして利用させてもらっている。

注記3：QOIExtractorについて

Cdを例にすると、①「Get 1 field(s) that are 1 field(s) after the text CdFinal」の方法で取得できる事は理解できるであろう。一方、Cdの値は計算のステップ毎に出力されており、②「Get 1 field(s) that are after 2 field(s) the text Cd」の方法でも取得できても良さそうではあった。

しかし、実際にこの方法を確認した所、以下2つの問題があって未解決である。

• Cdの値は、計算のステップ毎に出力されているが、最初のステップにおける出力値が取得されるだけであった。
• 数値の後のスペースがタブスペースとなっており、これ（タブスペース）を含めて次のフィールド値まで取得されて、数値と認識されずエラー終了となった。

これらの問題が解決できれば、Allrunの改造がほとんど不要になるはずであった。

この章の最初へ　全体目次