もう、40年余も前のことになりますが、汎用計算機で行う流れのシミュレーションを行うため、プログラムを組んでいたころのことです。
プログラミング言語、FORTRANを使ってプログラムを組んでいましたが、このプログラム“言語”という言葉に違和感を持ちました。FORTRAN
が、言語ですか？ 日本語や英語、中国語など人が双方向でコミュニケーションに使う符号の集合である言葉と同じように、計算機に対する
一連の計算処理命令にそれぞれ名前を付けた記号の集合体であるFORTRANに、言語という名前を名乗る資格があるのでしょうか。言語というか
らには、人の言葉と同じように、人と計算機が双方向にコミュニケーションできるツールでないと言語とは言えないのではないかしら？ FORTRAN
などの“言語”は、人とロボットが会話するときの言葉になるのかしら？ などと“言語”の定義の拡張に違和感を覚えました。しかし、
この“言語”の中身に踏み込んでいこうとすると、オートマトン、チューリング、・・・といった抽象論を勉強しなくてはならず、そんな理論
は類推できる具体的なイメージがわかず、歯が立たず、興味を失ってしまいました。今から考えるともったいないことでしたが・・・。筆者は、
今もその時のトラウマが残っていて、計算機と人とのコミュニケーション、更にはオートマトン、チューリング・マシンなどという言葉を見つ
けると融通の利かなかった自分を思い出して、ぞっとします。
“言語”の話はさておき、“言語”を使って計算機上で何らかの“機能”を実現することは、子供のころの工作をする喜びと同じで、物を作る喜びを感じる人は多いと思います。複雑なものを作れば作るほど、苦労も大きくなりますが、完成した時の喜びは増します。プログラムの形
を作って、まずはコンパイルエラーを取り去り、配列の意図しないアクセス違反を探し出して、何らかの結果を出すまでは比較的素早くできま
す。でもそのあとのディバッグ、虫取りに多大な時間を取られます。この作業、巷の間違い探しのクイズに似ていて、簡単に見つかるものもあ
りますが、巧妙に背景に隠れていてなかなか見つからないものも数多くあります。このプログラムの中に隠れていて、時々悪さをする”虫“(虫
を作ったのは、誰でもない、プログラムを書いた自分自身ですが・・・)をすべて見つけ出し、真っ当なシミュレーション結果を出す作業は、忍
耐と根性が試されます。いささかマゾ的ですが、つらい作業でもあり、虫を発見した時の喜びに興奮する作業でもあります。筆者自身は、3次元
の乱流シミュレーションのプログラムを当時のベクトル計算機で高速処理できるよう、数回、一から作った経験があります。コーディングに費や
した時間の数倍、数か月以上の時間をディバッグに費やしました。忍耐とぬか喜びと興奮の毎日だったと思います。論文締切などが迫り、まだ見
つけていない”虫“がいることを、半ば確信し、怯えつつも作業を打ち切ったことも覚えています。
ところで、このディバッグには2段階あります。一段階目の簡単な方は、流れ現象の専門家でもなくてもできる、いわば機械的にできる虫取り
です。例えばシミュレーション結果が空間対称となる境界条件を与えれば、当然、シミュレーション結果は空間対称の結果にならないといけま
せん。対称にならない場合は、何らかの論理ミスがプログラムに隠れている筈です。その原因を計算機処理のステップごとに検証し、原因を探
し出し、修正します。ここで難しいのは対称性が成立しない原因が、必ずしもプログラムの”虫“のためでない場合もあることがあります。空
間対称となる境界条件を与えても、実際の流れでは、空間対称はいわばポテンシャルが高く不安定で、非対称の方がポテンシャルが低く、安定
となるため、シミュレーション結果も、(多分打切り誤差などの擾乱の影響で)いわばポテンシャルの低い安定な状態に遷移してしまい、空間対
称にならないこともあるので注意が必要となります。与えた境界条件が一意の解を与えるものではなく、複数の解が存在する場合もあるようで
す。一意の解しかない場合は、機械的なチェックで比較的容易にディバッグが進みます。しかし後者の場合は、流れ現象自身がそうした二意性
があり、これがシミュレーションで起きたんだと信じることで、ある程度納得することが必要でした。構造力学分野に明るい方であれば、圧縮
された部材で生じる”座屈“現象を思い出されると、こうした現象をあるいは類推できるかもしれません。与えた境界条件で流れ場が一意に決
まると無邪気に信じ込まないことが大切という気がします。
2段階目のより実践的なディバッグは、お手本となる実際の流れ場の条件を与えて、シミュレーションで再現される流れ性状が、実際の流れを
再現しているか否かを比較して検討することになります。しかし、流れのシミュレーション開発当時は、このお手本の流れ場の詳しいデータを見
つけだすことが相当に難しい課題でした。これは支配方程式が非線型方程式で、単純な境界条件でも、なかなか初等関数で記述できるような理論
解がないということも難しさの一つの原因です。熱伝導などの線形方程式の計算機シミュレーションであれば、理論解のある境界条件をシミュレ
ーションに与えて、結果を理論解と比較すればことが足ります。流れのシミュレーションでは、これがなかなかに難しいのです。実験で測定され
た結果を使えばよいのではないかと思われるかもしれません。しかし流れが工学的に重要な乱流状況にあるような流れでは、そもそもお手本にな
るような正確な実験データが、なかなかありません。特に、平均流が3次元的で、流速が激しく変動する3次元乱流に関しては、信頼性の高い測定
データはそうそうありません。世の中に出るデータは、一般化、普遍化しやすいものが多く、形状などの境界条件の特異性が高く、一般化しにく
い3次元乱流の観察データは、今でもあまり多く公表されていません。自分で、測定して使えば良いではないかと思われるかもしれません。しかし、
筆者など、自分の3次元の乱流流れの測定で、有効数字3桁を期待できるようなことはまずありません。せいぜい有効数字2桁か、1桁程度の測定しか
できないことが多いです。などと言っていたら、分野によっては、ほとんどポテンシャルフローですが、翼形の揚抗比は有効数字6桁で測定します
と言われて、絶句したこともあります。本当ですかね？ まあ、乱れのない、非粘性のポテンシャルフロー中の抗力・揚力測定であれば可能かも
しれませんが、少し疑っています。最後に、言わずもがなですが、シミュレーション結果が、お手本の流れ場をどうしても期待する精度で再現で
きない時、もうシミュレーションソフトに”虫“がいるなどとは思わず、シミュレーションプログラムの適応限界と考えるようにしています。
乱流シミュレーションも、今はもう、オウンコーディング(owncoding)のプログラムで行うことなどほとんどなくなってしまったと思います。
筆者などは、今の流体シミュレーションに携わる多くの方々は、筆者などが体験した多くの楽しみを味わう機会を奪われた気の毒な人々にも思えます。
