SUMO Wiki
0 / 0
SUMO Wiki
SumoSlang は、独自の「カスタマイズした」プロセスモデルを開発するための非常に強力なツールです。この短いドキュメントの目的は、SumoSlang 言語を簡略化したバージョンを一巡りしながら紹介することです。プロセスモデリングとシミュレーションについて基本的な理解を持つ方になじみのある機能を取り上げ、「実践しながら学ぶ」ことができるよう、独自のカスタムモデルを構築する第一歩をお手伝いします。というわけで「SumoSlang for Dummies（初心者のための SumoSlang）」、あるいは「SumoSlang for Doers（実践者のための SumoSlang）」とでも、お好きなように呼んでください。[0]
チュートリアルは次のように構成されています。
SV をマッピングするモデルを開発します。SV コンポーネントは反応を伴わずに直接マッピングされます。あまり面白くはありませんが、出発点としては最適です。PAR と計算変数 CVAR の使い方を見ていきます。これらはモデルに何をもたらし、どのように追跡され、SUMO の Model Base をどのように活用するのでしょうか。これは決して SumoSlang でできることを網羅的に扱ったものではなく、SumoSlang の決定版リファレンスとしては BoSS[1] を参照してください。それでも、これら4つのチュートリアルが、独自のモデルを構築し始めるために必要な基礎知識と自信を得ていただくのに十分であることを願っています。[2] 以下に示す手順をたどりたくない場合は、チュートリアルのファイルをダウンロードし、自分自身のモデルに着手するためのテンプレートとして使うこともできます。
SUMO をインストールしたフォルダを探します。私のコンピュータでは C:\Users\cdhou\AppData\Local\Dynamita\Sumo21 にあります。ここに「My Process Code」という名前のフォルダがあり、その中に「Process Units」と「My Process Unit Category」が見つかるはずです。ここで作業を進めていきます。[3]
「基本的な CSTR」のために、次の3つのファイルを含む \TutorialOne basic CSTR という名前のフォルダを作成します[4]。
basic CSTR image.emf。SUMO のドローボード（drawing board）上でプロセスユニットを視覚的に表現するための画像ファイルです。TutorialOne basic CSTR Group Info.xlsx。このフォルダ内のファイルの構成と使い方を SUMO に説明するための Excel ファイルです。TutorialOne basic CSTR.xlsx。プロセスユニットモデルを記述する実際のコードを含む Excel ファイルです。
次に、「Group Info」ファイルを使って、このフォルダがどのように構成されているかを SUMO に指示します。最も基本的なレベルでは、TutorialOne basic CSTR Group Info.xlsx は次の要素で構成されている必要があります。
Symbol、Name、Value、Rule という列見出しを持つテーブルを含む、Unit という名前のワークシート。SortingPriority と DefaultUnit を指定する行。DefaultUnit は、Sumo Model Translator (SMT) がプロセスユニットモデルのコードを探しに行く、現在のフォルダ内の Excel ファイル名を指すことに注意してください。SMT は、この情報の提示方法についてかなり厳格です。テーブルのフォント・配色・スタイル（これらは任意）を除き、次のとおりに正確に見える必要があります。
TutorialOne basic CSTR.xlsx の中には、Unit と Code という名前の2つのワークシートを含める必要があります。Unit ワークシートには、次の3つのテーブルを含める必要があります。
Port テーブル。要素に対して行える接続の数や、それらの命名方法などを説明します。Model テーブル。このモデルファイルに関連付けられる有効・無効な生物反応速度モデル（biokinetic model）を指定します。Appearance テーブル。作業フォルダ内のどの画像ファイルをドローボードに表示するかを指定します。ここでも、SMT はこの情報の提示方法について厳格です。特に、テーブルは列 B から始まる必要があり、テーブルの列名と構造は守らなければなりません。以下に示す例に従うか、ここからダウンロードできるテンプレート \My Process Code\Process Units\My Process Unit Category\TutorialOne basic CSTR.xlsx を元に作業するのが最良です。
Code ワークシートはさらにシンプルにできます。このチュートリアルでは、2行を含む1つのテーブルにします。
$B$4 と $D$4。それぞれ、出力の流量 outp..Q の値を入力の流量 inp..Q の値に割り当てます。入口流量を出口へ単純にマッピングします。$B$5 と $D$5。それぞれ、出力の状態変数 outp..L.SV の値を入力の状態変数 inp..L.SV の値に割り当てます。何の変換も行わずに、入口の状態変数を出口へ単純にマッピングします。退屈なのは承知していますが、出発点としては最適です。焦らずいきましょう、若き弟子よ！ここで注目に値するのは、inp..L.SV が SumoSlang の、いわば……「スラング」であり、「basic CSTR」への入力ストリームに含まれるすべての状態変数を表しているという点です[5]。より正確に言えば、これは実際には液相の状態変数であり、ほとんどの場合 CSTR 間を移動しないと仮定される気相の状態変数（すなわち気泡やヘッドスペース）は除外されます。そしてもう1点、入力の定義とは、実際には Unit ワークシートのセル $D$5 で指定されたポート位置に接続されているもの全体を指します。とはいえ、こうした細かい点をすべて理解する必要はありません。テンプレートファイルを注意深くたどって手を加えるだけでも、多くのことが実現できます。
それでは SUMO を開いて、TutorialOne basic CSTR の作成に成功したかどうかを確認しましょう。新しいカテゴリ My Process Unit Category が、標準ライブラリの SUMO プロセスユニットと並んで SUMO のドローボードの左側に表示されているのがわかります。このユニットをドローボードにドラッグすると、フォルダ名 \TutorialOne basic CSTR が付与され、左下隅の Manual の下を見ると、参照されているプロセスユニットファイルも TutorialOne basic CSTR.xlsx という名前であることがわかります。[6] なお、TutorialOne basic CSTR.xlsx のコピーを \My Process Unit Category フォルダ内に作成していた場合は、以下に示すように、このリストにもそれが表示されます。これは、プロセスユニットコードの別バージョンを持ちたい場合に便利な機能です。
上記のモデルはビルドできますが、流入水（influent）と処理水（effluent）のフロー要素を接続しようとすると、effluent オブジェクトで XBIO を計算できないことに関連したビルドエラーが発生します。その理由は、SUMO の標準ライブラリの「Effluent」オブジェクトが、TutorialOne basic CSTR.xlsx で outp.. にマッピングされた Q と L.SV に加えて、さらなるパラメータを探しているためです。したがって、このチュートリアルでは標準ライブラリの Effluent オブジェクトは使用できません。代わりに、\My Process Unit Category 内に TutorialOne basic Effluent 要素を作成します。
「basic Effluent」オブジェクトの作成は、「basic CSTR」の作成とよく似ています。まず、以下に示すフォルダ構造から始めます。
Group Info ファイル TutorialOne basic Effluent Group Info.xlsx は、TutorialOne basic CSTR Group Info.xlsx とよく似ています。
basic Effluent.xlsx の Unit ワークシートも TutorialOne basic CSTR.xlsx とよく似ていますが、今回は入力ポートしか存在せず、やや皮肉なことに、それを「eff」と名付けます。
このように入力のみで出力がないため、effluent オブジェクトはあるポートから別のポートへ変数をマッピングする必要さえありません。したがって、Code ワークシートは完全に空のままで構いません。
ただしこの場合は、モデル変数を表示できるようにする Popup ワークシートを追加します。流量 Q とアンモニア SNHx を表示します。
もう一度 SUMO を開くと、Flow elements カテゴリの Influent を、My Process Unit Category の TutorialOne basic CSTR および TutorialOne basic Effluent とともに接続すると、モデルを正常にビルドできることがわかります。そして定常状態でシミュレーションを行い、effluent 要素の上にカーソルを置くと、ポップアップから、モデルが influent 要素からの流入流量を基本 CSTR を通して effluent 要素へ正常にマッピングしたことがわかります。
これで完成です。SumoSlang を使って、CSTR の入口から出口へ流量とコンポーネントをマッピングする新しいモデルが作成されました。最後の演習として、basic CSTR.xlsx の Code ワークシートに以下の変更を加えてみてください。SUMO で定常状態を実行したとき、outp..SNHx の新しい値は effluent オブジェクトに正しくマッピングされますか。セル $G$5 のルール Exempt(SNHx) を省略するとどうなりますか。
¶ チュートリアル 1 のまとめチュートリアル 1 では、SumoSlang を最も基本的な骨組みまで削ぎ落とす方法を示しました。その結果は取るに足らないモデルであり、流入水の流量とコンポーネントが、何の反応も変換も伴わずに反応槽を横断して処理水へとマッピングされます。それ以上のものは何もなく、In => Out だけです。これはあまり面白くありません。しかし SumoSlang の真価は、そのスケールのしかたにおいて明らかになります。一度コーディングされたモデルは、その後何度でも再利用して非常に複雑なモデルを構築でき、その規模は、Excel、Python、Matlab、あるいはお好みのプログラミングツールでプログラムできる範囲をはるかに超えます。加えて、SumoSlang は、関連する生物反応速度・水質化学・ガス移動プロセスを備えた膨大なコンポーネントライブラリを含む Model Base を活用します。SumoSlang が Model Base とどのように相互作用し、それを活用するのかは、次のチュートリアルで探っていきます。
プロセスシミュレーションの本質は、Process Units にわたる次の物質収支（mass balance）を解くことにあります。
Change in Mass of Component X with respect to time = Mass Flow of X in - Mass Flow of X out + Conversion rate of X
上記の式における Conversion rate of X（X の変換速度）こそ、「ASM」すなわち「活性汚泥モデル（Activated Sludge Model）」について語るときに思い浮かべるものです。多くの場合、これはモデルの最も興味深い部分であり、複雑さの大半が存在する箇所です。しかし、ASM のプロセス方程式を Process Units（私たちの場合は basic CSTR.xlsx）の Code ワークシートに直接コーディングすることは可能ではあるものの、これは SumoSlang の最良の使い方ではありません。SumoSlang では、ASM 型モデルのコードは Model Base と呼ばれ、Process Units のコードとは別に保管されます。これを捉える一つの見方として、上述の物質収支における Conversion rate of X が Model Base にコーディングされ、物質収支式の残りの部分が Process Units にコーディングされている、と考えることができます。
Model Base と Process Units のコードの分離は、以下のフォルダ構造に示されています。
この分離の利点は、Process Units のコードをさまざまな Model Base のコードとともに使用できることです。そして、たとえば PFAS を追加したいといった具合に Model Base に新しい構成成分を追加しても、それは自動的に Process Units のコードに取り込まれ、互換性が保たれます。Process Units のフォルダ構造にコーディングされた30以上のモデルのそれぞれについて、コードを更新する必要はありません。なんとありがたいことでしょう！では、基本 CSTR に反応を組み込む作業を始めましょう。
標準の SUMO の「Process code」フォルダ内で、「Mini_Sumo.xlsm」ファイルを探します。私のコンピュータでは C:\Users\cdhou\AppData\Local\Dynamita\Sumo21\Process code\Model base\Full plant models にあります。このファイルを、並列する「My Process code」フォルダ構造内の「Model base」フォルダにコピーし、TutorialTwo_Mini_Sumo.xlsx にリネームします。私のコンピュータでは C:\Users\cdhou\AppData\Local\Dynamita\Sumo21\My Process Code\Model base\My Model Category にあり、次のようになります。
このモデルファイルには、モデルコンポーネントの変換速度を記述するために必要な、すべての生物反応速度プロセス、化学量論、パラメータが含まれています。ただしまずは、できるだけシンプルにするという精神に則り、このモデルの複雑さを単純な硝化モデルの水準まで減らします。Model ワークシートで、行 4-6（r1、r2、r3 に対応）と行 9-29（r6 から r26 に対応）を削除します。これにより、硝化菌 XNITO の増殖と減衰（decay）を表す r4 と r5 のみが残るはずです。
列 B と C の番号を修正し、これら2つのプロセスがそれぞれ「1」「2」「r1」「r2」として識別されるようにします。次に、化学量論マトリックスのセルを編集し、シンボリックなパラメータの代わりにハードコードされた数値のみが表示されるようにします。こうすることで、モデルを「deparametize（脱パラメータ化）」しています[7]。
TutorialTwo_Mini_Sumo.xlsx です。化学量論マトリックスには、私たちが「脱パラメータ化」したい 1/YNITO のようなシンボリック（「パラメータ化された」）項が含まれています。
- 「脱パラメータ化」したバージョンを以下に示します。硝化菌 XNITO の増殖（+1）と減衰（-1）、および硝化菌の増殖に伴うアンモニア SNHx の消費（-6.667）と硝酸 SNOx の生成（+6.667）を表す、4つの化学量論項のみが残っています[8]。この単純化したケースでは、XB、XE、SALK、あるいは溶存酸素 SO2 のような他のすべての化学量論項は無視します。
- 最後に、プロセス速度式を次の式から、
- 状態変数 XNITO と SNHx の定義のみに依存し、その他にシンボリックなパラメータを含まない次の式へと簡略化します。
- ここまで操作してきたマトリックスの下には、化学量論マトリックスと反応項について「評価済み」の項、すなわち文字ではなく数値を含む2つ目の化学量論マトリックスがあります。この2つ目のマトリックスは「Check Continuity and Rates」ボタンをクリックすることで更新できます。ただし、これを行う必要はありません。SUMO Model Translator (SMT) はこの2つ目のマトリックスを無視します。
TutorialTwo basic CSTR を開発するための新しいフォルダを作成します。
\Tutorial One basic CSTR から3つのファイルを \Tutorial Two basic CSTR にコピーできますが、Excel ファイルの名前を次のように更新する必要があります。
「Group Info」ファイルの更新は、プロセスコードが置かれているファイル名を更新することです。
Code ワークシートを、4つのテーブルを含むように更新します。
SV を、その初期条件 SV_0 に割り当てます。このテーブルの見出しであるセル $D$3 が、この割り当てを Codelocation(ZeroTime) において一度だけ行うよう指定していることに注意してください。つまり、初期条件はシミュレーションのまさに開始時にのみ割り当てられます。rate_SV を、個々のプロセス速度 rMODEL.Model.j と化学量論マトリックス vMODEL.Model.j,SV の行列積として定義します。rMODEL.Model.j は、SumoSlang の「triplet notation（三つ組表記）」に従った Model Base の速度式への参照です。この表記法の詳細は BoSS に記載されています。[9] 私たちが作成した TutorialTwo_Mini_Sumo.xlsm ファイルの場合、これは Model ワークシートのセル $AN$4 と $AN$5 で定義された式を指します。同様に、vMODEL.Model.j,SV は、この同じワークシートのセル $E$4:$AM$5 に記述された化学量論マトリックスを表す SumoSlang の三つ組表記です。rate_SV を物質収支の一部として用いて、液相[10]状態変数の濃度の時間変化 dL.SV_dt を定義します。これがいわゆる微分方程式であり、SUMO の数値エンジンがモデルシミュレーション中に積分するものです。なお、この物質収支は、basic CSTR の液相体積を表す新しいパラメータ L.V を導入していることに注意してください。L.V は Parameters という名前の新しいワークシートで定義します。Parameters ワークシートについては後述します。inp..Q を反応槽の処理水 outp..Q へマッピングするとともに、反応槽コンパートメント内の状態変数の濃度 SV を反応槽の処理水 outp..SV へマッピングします。4つのテーブルを以下に示します。
Parameters ワークシートは、ユーザー定義のパラメータを定義したり、それらを Model Base から取り込んだりするために SumoSlang によって使用されます。この場合、液相体積 L.V を 24000 に、状態変数の初期条件 SV_0 を "MODEL.Components.Activated sludge" に定義します。式 "MODEL.Components.Activated sludge" は、Model Base の Components ワークシートで Activated sludge とラベル付けされた列を指します。私たちのファイル TutorialTwo_Mini_Sumo.xlsm では、列 F にあります。
Unit ワークシートは更新する必要はありません。
SUMO を開いたら、フローシートを作成し、Model Base から「TutorialTwo_Mini_Sumo」を選択します。
Model Base を「TutorialTwo_Mini_Sumo」に変更すると、モデルをビルドできるようになり、定常状態シミュレーションでは次のような処理水アンモニア濃度が示されます。
basicTwo CSTR.xlsx の Parameters ワークシートで定義した液相体積 L.V は、INPUT SETUP タブでユーザーが変更できます。反応槽の体積を 48000 m3 に倍増させると、予測される処理水アンモニアはどのように変化するでしょうか。
¶ チュートリアル 2 のまとめチュートリアル 2 では、基本 CSTR に反応を導入する方法を示しました。技術的な言い方をすれば、SUMO の数値エンジンがシミュレーション実行中に積分する物質収支の微分方程式です。反応を Process Units に直接コーディングする代わりに、「三つ組表記」を使って Process Units に取り込んだ Model Base を活用する方法を学びました。残念ながら、プロセスユニットファイル basicTwo CSTR.xlsx は、標準の SUMO の Process Units および Model Base とは互換性がありません。その理由は、Model Base のパラメータ PAR をインポートするコードが欠けているためです。また、他のプロセスユニットが私たちの基本 CSTR の ..outp ポートにマッピングされることを期待している特定の計算変数 CVAR を、計算してマッピングすることも行っていません。これらの欠点は、残りの2つのチュートリアルで対処します。
このチュートリアルの目的は、私たちの basic CSTR を、SUMO の標準 Model Base に含まれる Mini_Sumo と互換にすることです。
まず、My Process Unit Category 内に Tutorial Two basic CSTR のコピーを作成し、TutorialThree basic CSTR と名付けます。
次に、\TutorialThree basic CSTR 内のファイル名を次のように更新します。
Group Info ファイルが TutorialThree basic CSTR.xlsx を参照していることを確認します。
では、Flow elements の Influent、My Process Unit Category の TutorialThree basic CSTR および TutorialOne basic Effluent を使って、SUMO でシンプルなモデルを構築しましょう。また、MODEL SETUP ステップの Advanced オプションから Mini_Sumo を選択します。すると SUMO は、ドローボードウィンドウの下部に Mini_Sumo を表示するはずです。
モデルをビルドしようとすると、SUMO が muOHO_T を見つけられないという、以下でハイライトされたエラーが発生します。これは Model Base に関連付けられたパラメータです。
Mini_Sumo.xlsx[11] の中でこの muOHO_T を探すと、それが Model ワークシートのまさに最初のプロセス速度式で使われていることがわかります。加えて、このファイル全体を CTRL+F で検索すると、それが Parameters ワークシートで定義された muOHO や Tbase のようなパラメータに基づいて Calculated variables ワークシートで計算されていることがわかります。Excel 内のギリシャ文字が SUMO ではラテン文字の等価な表記に変換され、カンマがアンダースコアに置き換えられる点に注目してください。つまり、SUMO で muOHO_T と呼ばれるものは、Excel ファイルでは実際には μ<sub>OHO,T</sub> なのです。
このエラーを修正するために、TutorialThree basic CSTR.xlsxMini_Sumo.xlsx に次の2行を使って、Model Base からパラメータ PAR と計算変数 CVAR をインポートします[12]。
さて、SUMO を再度開いてシンプルなフローシートをビルドしようとすると、muOHO_T に関連するエラーはもう表示されません。しかし代わりに、kLaGCH4_bub に関連する新しいエラーが発生します。Mini_Sumo.xlsx を検索すると、それが Model ワークシートの Methane gas transfer - bubbles の速度式の中に見つかります。興味深いことに、それは Parameters にも Calculated variables ワークシートにも現れません。実は、SumoSlang はこれがプロセスユニットファイル内で直接計算されることを期待しています。たとえば標準ライブラリの CSTR プロセスユニット[13]では、このパラメータは Code ワークシートで kLaG.SV,bub として計算され、ここで G.SV は SumoSlang によって CH4 を含むすべての気相状態変数に展開されます。
そこで、Code ワークシートにガス移動パラメータをコーディングし、それらにプレースホルダ値 1 を割り当てることで、SUMO が求めているものを与えます。
しかし実際には、ガス移動の kLa 係数についてはプレースホルダ値しか持っていないため、SUMO にガス移動速度を計算させたくはありません。SumoSlang は、物質収支の計算に Rule を追加することで、これをうまく扱う手段を提供しています。この Rule は、Model Base で Handling(Integrated) を持つと指定された状態変数 SV に対してのみ物質収支が計算されるよう指定します。各状態変数の扱い（handling）は、Components ワークシートのテーブル見出し Handling で指定されます。Mini_Sumo.xlsx では、ほとんどの状態変数が Integrated である一方、ガスは Set になっていることがわかります。
もう一度 SUMO を開いて基本 CSTR モデルをビルドしようとすると、今度はエラーが一切ありません。成功です！
¶ チュートリアル 3 のまとめチュートリアル 3 では、Model Base からパラメータ PAR と計算変数 CVAR をインポートする方法を示しました。加えて、SUMO の標準モデルライブラリが、Process Code 内でのガス移動 kLa 係数の計算に依存していることを示しました。このチュートリアルでの basic CSTR プロセスユニットコードの更新により、それが標準の SUMO Model Base と互換になります。しかし、それを標準の SUMO Process Units と互換にするには、まだもう1ステップ必要です。この最終変更はチュートリアル 4 で示します。
TutorialThree basic CSTR フォルダのコピーを作成し、TutorialFour basic CSTR にリネームします。このフォルダ内のファイル名をフォルダ名と一致するように更新し、さらに Group Info ファイル内で参照されているプロセスユニットファイル名も変更することを忘れないでください。
チュートリアル 3 で説明したとおりに Mini_Sumo モデルを使ってモデルを正常にビルドしシミュレートできることを、TutorialFour basic CSTR を用いて再度確認します。
次に、TutorialOne basic Effluent を削除し、標準の SUMO Flow elements の Effluent 要素に置き換えます。このモデルをビルドしようとすると、次のエラーが発生します。
要するに、SUMO は Effluent の XBIO に、basic CSTR の処理水における値を割り当てようとしています。Model Base を確認すると、XBIO は計算変数 CVAR であることがわかり、したがって私たちのコードは反応槽の ..outp へ CVAR をマッピングしていない、と結論づけられます。これを是正するために、TutorialFour basic CSTR.xlsx の Code ワークシートに次の行を追加できます。
SUMO を再度開いて、標準ライブラリの Effluent 要素を使ってモデルをビルドしようとすると、成功です！ そして Effluent 要素の上にマウスを重ねると、Model Base からの計算変数が画面に表示されます。
¶ チュートリアル 4 のまとめチュートリアル 4 では、CVAR を私たちの basic CSTR プロセスユニットの処理水へマッピングする方法を示しました。これは、私たちのプロセスユニットを標準ライブラリの SUMO プロセスユニットと互換にするため重要です。これらのプロセスユニットの多くは、スプリッターやミキサー要素のように非常にシンプルで、Model Base とインターフェースする必要がありません。そのため、それらは上流のプロセスユニットからの SV と CVAR の両方のマッピングに依存します。これら4つのチュートリアルにより、Model Base を活用し、SUMO 標準ライブラリの残りの Process Units とインターフェースできるカスタムプロセスユニットモデルを構築するための基本的なツールが手に入りました。というわけで、楽しんでください！ スタイルに関するさらなるヒントとしては、BoSS に加えて、標準ライブラリの Process Units のいくつかを研究することをお勧めします。
これまでのチュートリアルでは、SumoSlang でカスタマイズしたプロセスモデルを構築し始める方法の概要を示しました。良い次のステップにはどのようなものがあるでしょうか。たとえば次のようなものはいかがでしょう。
SV は一方の出口へ優先的に振り分けられ、もう一方が割を食う、といったプロセスです。自分自身のカスタマイズ版に着手する前に、標準の SUMO ライブラリでハイドロサイクロン向けにこれがどのようにコーディングされているか C:\Dynamita\Sumo21\Process code\Process units\Separators\Cyclone を見てみるのが良い出発点かもしれません。\Dynamita\Sumo21\Process code\Process units\Bioreactors\Pond は、池の水柱とその底泥層との相互作用をモデル化するために、equalization basin（流量調整槽）のコード \Dynamita\Sumo21\Process code\Process units\Flow elements\Equalization basin を使用しています。Pond モデルに、標準ライブラリのいくつかのプロセスユニット（Variable volume equalization basin を含む）を呼び出す Structure という追加のワークシートが含まれている点に注目してください。\Dynamita\Sumo21\Process code\Process units\Bioreactors\PFR に良いものが示されています。SumoSlang は、経験豊富なモデラーにとってさえ、初心者には少し気後れさせるものかもしれません。これらのチュートリアルは、プロセスモデルがどのように動くか、Gujer マトリックス、微分方程式系についてすでに理解があり、もしかすると自分で多少のコーディングを行ったこともあるものの、SUMO のような商用シミュレーションソフトウェアパッケージの「ボンネットの中」ほど高度なことはやったことがない、という方に向けて書かれています。オーヴィル・ライトが 747 のコックピットにタイムスリップしてきたところを想像してみてください。飛行機とその操縦法については、間違いなく彼は誰にも劣らず詳しいでしょう。しかし 747 のコックピットには非常に多くのボタンや小さなランプがあり、何がどれの役目なのか彼にはまるで見当がつかないはずです！ 「実践しながら学ぶ」どころではありません。常識的に考えれば、監督なしに、そして何時間もの訓練なしに、彼は何にも触れるべきではありません。この例はあまりに大げさだと思いますか。結局のところ、コンピュータをクラッシュさせて死んだ人は誰もいませんから。確かにそのとおりですが、事実として、複雑さが取り除かれると学ぶのは容易になります。そしてこれは、飛行機の操縦を学ぶ場合と同じくらい、モデリングにも当てはまります。結局、もしオーヴィル・ライトがボーイング 747 で飛行を学ばざるを得なかったとしたら、航空の歴史はまったく違ったものになっていたかもしれません。
BoSS すなわち Book of SumoSlang
SumoSlang をコーディングする必要があるのはいつでしょうか。SUMO で直接モデルを作成することはできないのでしょうか。実際、ほとんどの場合、モデルの作成にコーディングはまったく必要ありません。ある新規の BNR プロセスは、世界中の他のどの BNR プロセスとも異なる独自のものかもしれませんが、それでも結局は曝気された生物反応槽と曝気されていない生物反応槽の組み合わせにすぎません。ですから SumoSlang は不要で、生物反応槽の要素を SUMO のドローボードにドラッグ・アンド・ドロップするだけで済み、あとは快適にモデリングを楽しめます！ しかし、そのモデルが、浮遊増殖（suspended growth）と付着増殖（attached growth）の間の独自の相互作用を持ち、さらには気相でも何か面白いことが起きているようなハイブリッド反応槽を含むとしたらどうでしょう。そして、この反応槽の独自の挙動を適切に捉えられるプロセスユニットが標準の SUMO ライブラリに存在しないとしたら。これはより複雑なケースであり、たいていの商用ソフトウェアでは手詰まりになってしまいます。しかし SUMO ではそれは問題になりません。自分でコーディングすればよいからです……SumoSlang で！
「Process Code」という名前のディレクトリは見つかるのに「My Process Code」が見つからない場合は、SUMO のインストール時に「Install」ディレクトリと「Working」ディレクトリに別々の場所を選んだということです。「My Process Code」の場所を見つけるもう一つの方法は、SUMO のメインメニューから「View | Directories | My process code」を辿ることです。
これらのファイルの名前は重要です。まず、「Group Info」ファイルには、それが置かれているフォルダと同じ名前を含めることが極めて重要です。たとえばフォルダ名が「Industrial DAF」であれば、「Group Info」ファイルは「Industrial DAF Group Info.xlsx」でなければなりません。あるいは、この場合フォルダ名が「TutorialOne basic CSTR」なので、ファイル名は「TutorialOne basic CSTR Group Info.xlsx」になります。画像ファイルやその他の「.xlsx」ファイルの名前には、特殊文字（ハイフンを含む！）を使えないという以外に制約はありません。画像ファイルの名前はプロセスユニットの Excel ファイル内で参照され、同様にプロセスユニットの Excel ファイルの名前は Group Info ファイル内で参照されます。「file(s)」のように「(s)」を付けているのは、これらが1つの場合も複数の場合もあり得ることを示すためです。ただし、「Group Info」ファイルは1つしか存在できません。
「どの状態変数のこと？」「まだ状態変数なんて何も定義していないのに！」と思うかもしれません。ここで言う状態変数とは、SUMO のフローシートでアクティブになっている Model Base ファイルに関連付けられたもののことです。SUMO を開くと、デフォルトの Model Base は Sumo1 モデルです。このモデルにはいくつかの X 状態変数が含まれており、したがって inp..L.SV と outp..L.SV は、私たちのプロセスユニットである基本 CSTR への入力・出力ストリームに関連付けられた液相状態変数の全リストを指します。もし Model Base ファイルを別のもの、Sumo2 やあなた独自のカスタム Model Base に変更すれば、L.SV はその Model Base ファイルの状態変数を指すことになります。
ドローボード用の画像を作成する最良の方法は何でしょうか。この場合、私は PowerPoint を使い、中にテキストを入れた長方形を作成しました。次にその画像を選択し、右クリックしてドロップダウンメニューから「図として保存」を選びます。ポートが表示されるスペースを画像内に確保するために、青い長方形の背後に2つ目の長方形を作成します。この2つ目の長方形は塗りつぶしなし・枠線なしにします。ただしこれによって、画像ファイルの境界が青い長方形より少しだけ大きく定まります。こうしてポートが表示されるスペースが生まれます。
チュートリアル 2 でモデルを脱パラメータ化する目的は、basic CSTR.xlsx に Model Base の「パラメータ」すなわち「PARAM」をインポートするコードを含める必要をなくすことです。Model Base から「パラメータ」を Process Units のコードにインポートする方法にはいくつかあるため、これは別のチュートリアルで扱うほうが望ましいのです。
硝化菌の増殖の化学量論を、ここでは最もシンプルな形で示しています。1 g の NH4-N を消費すると、Y g の硝化菌 XNITO が生成されます。したがって 1 g の XNITO を生成するには 1/Y g の NH4-N が必要です。Y=0.15 を仮定すると、アンモニアと硝酸それぞれのハードコード値 -6.667 および +6.667 が説明できます。
BoSS すなわち Book of SumoSlang もぜひチェックするのをお忘れなく！
SumoSlang では、液相状態変数 L.SV を、気泡やヘッドスペースに関連する気相成分 G.SV も含むより長い全状態変数 SV のリストとは別に、識別して計算を行うことができます。これは、L.SV は反応槽から反応槽へ移動するのに対し G.SV は移動しないため、有用な区別です。SumoSlang は、ある SV が L.SV かどうかをどうやって知るのでしょうか。SumoSlang は、Model Base の Components ワークシートの Phase 列でこれらの定義を探します。私たちの TutorialTwo_Mini_Sumo.xlsm、あるいは SUMO の Model Base にある他のいずれかのファイルを見てみてください。
私のコンピュータでは、このファイルは C:\Users\cdhou\AppData\Local\Dynamita\Sumo21\Process code\Model base\Full plant models にあります。
標準の SUMO プロセスユニットライブラリの CSTR with diffused aeration and calculated DO.xlsx のコーディングを調べると、PAR が Parameters ワークシートに3回、さらに Code ワークシートにもう3回定義されているのがわかります。これはどういうことでしょうか。これを理解するには Rule 列を見る必要があります。まず、両方のワークシートで、3つの PAR の定義はそれぞれ Type(Kinetic)、Type(Stoichiometric)、Type(Equilibrium) に適用されます。ですからこれらの定義についてまず理解すべきことは、Parameters ワークシートのテーブル見出しが Type(Kinetic)、Type(Stoichiometric)、Type(Equilibrium) のいずれを含むかに応じて、Model Base からパラメータをインポートするということです。次に、Parameters ワークシートでは、これらの定義は Non-InheritkinPAR、Non-InheritstoPAR、Non-InheritequPAR の場合にのみ適用されます。
対照的に、Code ワークシートではルールが逆になっており、InheritkinPAR、InheritstoPAR、InheritequPAR です。どちらが優先されるのでしょうか。その答えは、これらの継承の定義にあり、それらは Unit ワークシートに見つかります。これらの継承パラメータは TRUE に設定されているため、Code ワークシートの PAR の定義のみが適用されます。
そして PAR は、親ユニット Parent..PAR を用いて Code で定義されています。
では、これは何を意味するのでしょうか。親ユニットとは何でしょうか。要するに、Parent..PAR は、SUMO フローシート内のすべてのプロセスユニットに適用される「グローバルパラメータ」の集合と考えることができます。「ローカルパラメータ」は、ユーザーが以下に示すように Key parameters に「ローカル」な変更を加えた場合にのみ適用されます。ローカルな変更が加えられると、このプロセスユニットに関する該当の継承パラメータ（InheritkinPAR、InheritstoPAR、InheritequPAR のいずれか）が FALSE に切り替わります。
私のコンピュータでは C:\Users\cdhou\AppData\Local\Dynamita\Sumo21\Process code\Process units\Bioreactors\CSTR\CSTR with diffused aeration and calculated DO.xlsx にあります。
