第2章 自動化とパラメトリック性 -スーパーコンピュータで行われていた大量の計算とは
スーパーコンピュータ会社に勤務していた頃の話その2です。スーパーコンピュータでの計算といえば、一回の計算が数十時間から数日も掛かる超大規模なシミュレーションが脚光を浴びるのは当然のことです。トップレベルの研究者や利用者にとっては、その時代の最速の性能でどこまで大規模で長時間の計算ができるのかが重要なので、スーパーコンピュータ会社にとっても、最重要なお客様層であり、注力するのも大規模なテーマとアプリケーションなのでした。
運用支援を行うようになり、実際に、利用企業のジョブの実行状況を見てみると、大規模な計算でほぼ7~8割ぐらいのCPU時間が占められているのは当然としても、残りの計算は大半が、10分程度の線形応力計算のジョブが大量に流れていることで占められていることがわかるのです。初めてそのログ情報を見たときには何にも気に留めなかったのですが、前回の記事で書いたように、「設計とは最適化」というキーワードを聞いてからは、大量の計算がなぜ必要なのかがおぼろげながらわかってきたのでした。特にたくさんの数の計算を流しているある利用者に尋ねて見ると、パラメータを変更したモデルを事前に準備しておいて、スクリプトを使って自動的にそのモデルの計算ジョブを投入することを、毎日終業際に行っているとのことだったのです。翌日たくさんの計算結果が出ているので、それを検討したのち別のアイデアでモデルを変更し、いくつかのパラメータを大中小で変更するということを、毎日行っているのでした。いわゆるパラメータ・スタディ計算を手動で行っていたのですね。これこそが、前回記事で紹介した、Miura氏の言っていた、「設計とは最適化」の現場なのだと気付くようになったのです。
ジョブの時間は短く、線形応力計算という簡単なシミュレーションなので、技術的には全くわくわくしないのですが、そのようなシミュレーションこそが実は設計業務の枢要な役割を持っていて、万が一スーパーコンピュータがストップしようものなら、一番最初にクレームが来るのは、そうした設計部門ユーザからなのでした。このような実務経験に加えて、その当時MPP (Massively Parallel Processor)と呼ばれていた計算機を、同僚の一人が最適化アルゴリズムを利用して、たくさんの計算を同時並行に流して、もっとも適した設計解を探索するというプロジェクトをいくつか行っていたこともあり、私の関心は、大規模長時間ジョブではなく、小時間の大量計算のジョブ群、すなわちパラメータ・スタディ、惹いては最適化設計の方に、急速に傾いていきました。
ただ、特定のモデルとアプリを、MPPで独立並列に実行できるような設定準備を前提する必要がありましたので、利用者にも高度なスキルを要求する環境でした。汎用的に最適解の探索を行うのはまだまだ難しく、何年たてばそういう計算を自動でできるのかまったく想像ができないと思っていたのでした、あるソフトを紹介してもらうまでは。(続きは、次回にて)
【SIMULIA 工藤】
バックナンバー
【デザインとシミュレーションを語る】第一回:イントロダクション 【デザインとシミュレーションを語る】第二回:シミュレーションの分類 【デザインとシミュレーションを語る】第三回:シミュレーションは実験と比べて何がいい? 【デザインとシミュレーションを語る】第四回:シミュレーションは緻密な統合技術 【デザインとシミュレーションを語る】第五回:リアルとバーチャルの垣根をなくせたら?(1) 【デザインとシミュレーションを語る】第六回:リアルとバーチャルの垣根をなくせたら?(2) 【デザインとシミュレーションを語る】第七回:3D-CADは何のため? 【デザインとシミュレーションを語る】第八回 : CAE を志す人へのメッセージ(1) 【デザインとシミュレーションを語る】第九回 : CAEを志す人へのメッセージ(2) 【デザインとシミュレーションを語る】第十回: ソフトウエア・ロボットの誕生 【デザインとシミュレーションを語る】第十一回: 作業を自動化すること、その真の価値とは 【デザインとシミュレーションを語る】第十二回: “自動化を進めると設計者が考えなくなる?"への回答 【デザインとシミュレーションを語る】第十三回 : パラメトリック性の本質は新しい組み合わせ 【デザインとシミュレーションを語る】第十四回 : Zero Design Cycle Timeの衝撃 【デザインとシミュレーションを語る】第十五回 : 「設計とは最適化」の奥深い意味を教えてくれた技術者