特許 6944992 シミュレーション資源の動的最適化

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6944992

(24)【登録日】2021年9月15日

(45)【発行日】2021年10月6日

(54)【発明の名称】シミュレーション資源の動的最適化

(51)【国際特許分類】

   G06Q 10/04 20120101AFI20210927BHJP

   G06F 15/177 20060101ALI20210927BHJP

   G06F 9/50 20060101ALI20210927BHJP

【ＦＩ】

   G06Q10/04

   G06F15/177 A

   G06F9/50 120Z

   G06F9/50 150E

【請求項の数】32

【全頁数】51

(21)【出願番号】特願2019-506406(P2019-506406)

(86)(22)【出願日】2017年8月10日

(65)【公表番号】特表2019-526854(P2019-526854A)

(43)【公表日】2019年9月19日

(86)【国際出願番号】US2017046323

(87)【国際公開番号】WO2018031792

(87)【国際公開日】20180215

【審査請求日】2020年7月30日

(31)【優先権主張番号】15/235,004

(32)【優先日】2016年8月11日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】519037669

【氏名又は名称】リスケール，インコーポレイテッド

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】ポート，グレゴリウス，イー．

(72)【発明者】

【氏名】ポート，ムルヤント，ダブリュ．

(72)【発明者】

【氏名】カネシロ，ライアン，エー．

(72)【発明者】

【氏名】マッケンジー，アダム，シー．

【審査官】 岡北 有平

(56)【参考文献】

【文献】 米国特許第０８７０６７９８（ＵＳ，Ｂ１）

【文献】 米国特許出願公開第２０１３／０１７４１４６（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１１／０１３１３１５（ＵＳ，Ａ１）

【文献】 特開２０１３−２１８６６１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ ー ９９／００

Ｇ０６Ｆ １５／１７７

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

インスタンス間依存性を有するタスクを実行するアプリケーションの実行のための計算資源の提供を動的に最適化するシステムであって、前記アプリケーションは、正しく実行し、前記インスタンス間依存性を解決するために、前記アプリケーションへ割り振られた前記計算資源の少なくとも１つの計算資源の事前構成仕様を必要とする１つ又は複数のアプリケーション強要制約を含み、前記システムは、
（ａ）前記アプリケーションを実行するためのハードウェア供給者プラットホーム上に計算資源のクラスタを提供するクラスタサービスと；
（ｂ）前記アプリケーション強要制約に従って前記アプリケーションを構成し、前記提供されたクラスタ上の前記アプリケーションの実行を開始するアプリケーションサービスと；
（ｃ）（ｉ）複数の計算資源変更指標及び（ｉｉ）前記アプリケーションにより生成される１つ又は複数の再開ファイルに関する前記アプリケーションの実行を監視するアプリケーション監視サービスと；
（ｄ）（ｉ）現在の計算資源の修正が是認されたかどうかを判断し、そうであれば（ｉｉ）前記アプリケーションの実行中に前記現在の計算資源の変更を実施するために前記計算資源変更指標及び前記再開ファイルを連続的に解析する計算資源評価エンジンと、を含み、
前記複数の計算資源変更指標は、アプリケーション固有データであって、その実行中に前記アプリケーションにより生成される出力ファイルから抽出されるデータを含み、前記アプリケーションの将来利用の計算資源の予測を容易にするアプリケーション固有データを含む、システム。

【請求項2】

（ａ）前記クラスタは前記アプリケーションの独立サブタスク計算を並列に実行するための複数のＣＰＵコアを含み、前記独立サブタスク計算は、第１のＣＰＵコア上で前記アプリケーションの第１のインスタンスにより行われる第１のサブタスク計算と、第２のＣＰＵコア上で前記アプリケーションの第２のインスタンスにより行われる第２のサブタスク計算とを含み；
（ｂ）前記第１のインスタンスにより行われる第３のサブタスク計算は、前記第２のインスタンスにより行われる前記第２のサブタスク計算の結果に依存し、これによりインスタンス間依存性を構成する、請求項１に記載のシステム。

【請求項3】

前記複数の計算資源変更指標は、
前記計算資源の前記アプリケーションの現在の利用の程度を反映する計算資源利用データをさらに含む、請求項１に記載のシステム。

【請求項4】

前記計算資源変更指標は、（ａ）前記アプリケーションへの入力として提供されるシミュレーションデータモデル内のセルの数の変更、（ｂ）前記アプリケーションにより行われる前記タスク内の１つ又は複数の繰り返し反復工程、（ｃ）前記アプリケーションにより呈示されるコア間通信の程度の変更、及び（ｄ）前記アプリケーションにより行われる前記タスクの多少計算資源集約的な局面への変更のうちの１つ又は複数の指標を含む、請求項１に記載のシステム。

【請求項5】

前記計算資源評価エンジンは、前記計算資源変更指標のその解析に基づき、前記アプリケーションの計算資源の将来利用の程度に関する予測を生成する、請求項１に記載のシステム。

【請求項6】

前記計算資源評価エンジンは、前記現在の計算資源の修正が是認されたかどうかのその判断の基礎を、時間の経過と共に前記アプリケーション監視サービスにより監視される過去の情報に置く、請求項１に記載のシステム。

【請求項7】

前記アプリケーション強要制約は、前記提供されたクラスタ内のＣＰＵコアの数の事前構成仕様を含む、請求項１に記載のシステム。

【請求項8】

計算資源の前記変更は１つの計算資源の増加と別の計算資源の低減とを含む、請求項１に記載のシステム。

【請求項9】

各再開ファイルは、前記アプリケーションの現在の中間状態を反映するデータを含み、これにより、将来再開される場合に前記アプリケーションが前記中間状態からの実行を再開することを可能にする、請求項１に記載のシステム。

【請求項10】

前記計算資源評価エンジンは、前記アプリケーションの実行中に：
（ａ）前記クラスタサービスに、選択されたハードウェア供給者プラットホーム上に計算資源の新しいクラスタを提供するように指示すること；
（ｂ）前記アプリケーションが実行されている前記現在のクラスタを終了すること；及び
（ｃ）前記アプリケーションサービスに、前記アプリケーションを前記アプリケーション強要制約に従って再構成し、前記提供された新しいクラスタ上の前記アプリケーションの実行を前記再開ファイルのうちの選択された１つに含まれる前記中間状態から開始するように指示することにより、前記現在の計算資源の変更を実施する、請求項１に記載のシステム。

【請求項11】

前記提供されたクラスタ上の前記アプリケーションの実行を開始することを各ユーザに許容する前に、対応するライセンスサーバにより前記アプリケーションの前記各ユーザを認証するライセンスサービスをさらに含む請求項１に記載のシステム。

【請求項12】

前記提供されたクラスタ上の前記アプリケーションの前記構成要素の実行を開始することを各ユーザに許容する前に、前記アプリケーションの構成要素の前記各ユーザを認証するライセンスサービスをさらに含む請求項１に記載のシステム。

【請求項13】

（ａ）前記提供された計算資源が前記タスクの実行中に使用される全時間を監視するハードウェア計測モジュールと、
（ｂ）前記アプリケーションが前記タスクの実行中に使用される全時間を監視するソフトウェア計測モジュールとをさらに含む請求項１に記載のシステム。

【請求項14】

前記ソフトウェア計測モジュールは、前記アプリケーションの構成要素が前記タスクの実行中に使用される全時間を監視する、請求項１３に記載のシステム。

【請求項15】

前記アプリケーションは前記提供されたクラスタ上で終了され、異なる計算資源を有する新しいクラスタ上で再開され、
前記ソフトウェア計測モジュールにより監視される前記全時間は、前記アプリケーションが前記提供されたクラスタ及び前記新しいクラスタ上で前記タスクの実行中に使用される時間の合計を含む、請求項１３に記載のシステム。

【請求項16】

前記ソフトウェア計測モジュールは前記タスクを実行する複数のアプリケーションを監視する、請求項１３に記載のシステム。

【請求項17】

インスタンス間依存性を有するタスクを実行するアプリケーションの実行のための計算資源の提供を動的に最適化する方法であって、前記アプリケーションは、正しく実行し、前記インスタンス間依存性を解決するために、前記アプリケーションへ割り振られた前記計算資源の少なくとも１つの計算資源の事前構成仕様を必要とする１つ又は複数のアプリケーション強要制約を含み、前記方法は、
（ａ）前記アプリケーションを実行するためのハードウェア供給者プラットホーム上に計算資源のクラスタを提供する工程と；
（ｂ）前記アプリケーション強要制約に従って前記アプリケーションを構成し、前記提供されたクラスタ上の前記アプリケーションの実行を開始する工程と；
（ｃ）（ｉ）複数の計算資源変更指標及び（ｉｉ）前記アプリケーションにより生成される１つ又は複数の再開ファイルに関する前記アプリケーションの実行を監視する工程と；
（ｄ）現在の計算資源の修正が是認されたかどうかを判断し、そうであれば前記アプリケーションの実行中に前記現在の計算資源の変更を実施するために前記計算資源変更指標及び前記再開ファイルを連続的に解析する工程と、を含み、
前記複数の計算資源変更指標は、アプリケーション固有データであって、その実行中に前記アプリケーションにより生成される出力ファイルから抽出されるデータを含み、前記アプリケーションの将来利用の計算資源の予測を容易にするアプリケーション固有データを含む、方法。

【請求項18】

（ａ）前記クラスタは、前記アプリケーションの独立サブタスク計算を並列に実行するための複数のＣＰＵコアを含み、前記独立サブタスク計算は、第１のＣＰＵコア上で前記アプリケーションの第１のインスタンスにより行われる第１のサブタスク計算と、第２のＣＰＵコア上で前記アプリケーションの第２のインスタンスにより行われる第２のサブタスク計算とを含み；
（ｂ）前記第１のインスタンスにより行われる第３のサブタスク計算は、前記第２のインスタンスにより行われる前記第２のサブタスク計算の結果に依存し、これによりインスタンス間依存性を構成する、請求項１７に記載の方法。

【請求項19】

前記複数の計算資源変更指標は、前記計算資源の前記アプリケーションの現在の利用の程度を反映する計算資源利用データをさらに含む、請求項１７に記載の方法。

【請求項20】

前記計算資源変更指標は、（ａ）前記アプリケーションへの入力として提供されるシミュレーションデータモデル内のセルの数の変更、（ｂ）前記アプリケーションにより行われる前記タスク内の１つ又は複数の繰り返し反復工程、（ｃ）前記アプリケーションにより呈示されるコア間通信の程度の変更、及び（ｄ）前記アプリケーションにより行われる前記タスクの多少計算資源集約的な局面への変更のうちの１つ又は複数の指標を含む、請求項１７に記載の方法。

【請求項21】

前記計算資源変更指標の前記解析に基づき、計算資源の前記アプリケーションの将来利用の程度に関する予測を生成する工程をさらに含む請求項１７に記載の方法。

【請求項22】

前記現在の計算資源の修正が是認されたかどうかの前記判断は時間の経過と共に監視される過去の情報に基づく、請求項１７に記載の方法。

【請求項23】

前記アプリケーション強要制約は前記提供されたクラスタ内のＣＰＵコアの数の事前構成仕様を含む、請求項１７に記載の方法。

【請求項24】

計算資源の前記変更は１つの計算資源の増加と別の計算資源の低減とを含む、請求項１７に記載の方法。

【請求項25】

各再開ファイルは、前記アプリケーションの現在の中間状態を反映するデータを含み、これにより、将来再開される場合に前記アプリケーションが前記中間状態からの実行を再開することを可能にする、請求項１７に記載の方法。

【請求項26】

前記アプリケーション実行中の前記現在の計算資源の変更の前記実施は：
（ａ）選択されたハードウェア供給者プラットホーム上に計算資源の新しいクラスタを提供する工程と；
（ｂ）前記アプリケーションが実行されている前記現在のクラスタを終了する工程と；
（ｃ）前記アプリケーション強要制約に従って前記アプリケーションを再構成する工程と、
（ｄ）前記提供された新しいクラスタ上の前記アプリケーションの実行を前記再開ファイルのうちの選択された１つに含まれる前記中間状態から開始する工程とを含む、請求項１７に記載の方法。

【請求項27】

前記ユーザに、前記提供されたクラスタ上の前記アプリケーションの実行を開始することを許容する前に、対応するライセンスサーバにより前記アプリケーションの各ユーザを認証する工程をさらに含む請求項１７に記載の方法。

【請求項28】

前記提供されたクラスタ上の前記アプリケーションの前記構成要素の実行を開始することを各ユーザに許容する前に、前記アプリケーションの構成要素の前記各ユーザを認証する工程をさらに含む請求項１７に記載の方法。

【請求項29】

（ａ）前記提供された計算資源が前記タスクの実行中に使用される全時間を監視する工程と、
（ｂ）前記アプリケーションが前記タスクの実行中に使用される前記全時間を監視する工程とをさらに含む請求項１７に記載の方法。

【請求項30】

前記アプリケーションの構成要素が前記タスクの実行中に使用される全時間を監視する工程をさらに含む請求項２９に記載の方法。

【請求項31】

前記アプリケーションは前記提供されたクラスタ上で終了され、異なる計算資源を有する新しいクラスタ上で再開され、前記アプリケーションが前記タスクの実行中に使用される全時間は、前記アプリケーションが前記提供されたクラスタ及び前記新しいクラスタ上で前記タスクの実行中に使用される時間の合計を含む、請求項２９に記載の方法。

【請求項32】

前記タスクを実行する複数のアプリケーションを監視する工程をさらに含む請求項２９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

背景技術
本出願は、２０１７年８月１０日にＰＣＴ国際特許出願として出願されており、その全開示を参照により本明細書に援用する２０１６年８月１１日出願の米国実用特許出願第１５／２３５，００４号からの優先権を主張する。

【0002】

技術分野
本発明は、一般的には並列処理環境内の計算資源を管理することに関し、特に、シミュレーション又は他の高性能計算タスクなどのインスタンス間依存性を有するタスクの実行中に計算資源を動的に最適化することに関する。

【背景技術】

【0003】

関連技術の記載
ハードウェア及びソフトウェアの計算資源の要求が劇的ペースで増加し続けるにつれて、新しい計算プラットホームは、計算資源へのアクセスと計算資源の管理とを費用効率が高いやり方で提供するという個人及び会社への負担を部分的に軽減するように進化してきた。このようなプラットホームを運営する「ハードウェア供給者」は、それらの使用に関する多くの制御を保持する一方で顧客が物理的計算資源要件を外部委託することを可能にする。

【0004】

例えばAmazon、Microsoft、及びGoogleなどのクラウド計算プラットホームは共有物理的計算資源へのアクセスを顧客へ提供する。このような計算資源は、１つ又は複数のオペレーティングシステム、１つ又は複数のシングル又はマルチコアＣＰＵ、ネットワーク相互接続性ハードウェア（例えばイーサーネットコントローラ）、並びに外部ハードディスク及びフラッシュアレイを含む可変量のメモリ（例えばＲＡＭ及び非揮発性メモリ）及び固定記憶装置（例えばハードディスク及びフラッシュドライブ）を有するサーバを含む。各ハードウェア供給者は通常、アプリケーションの実行のための様々な構成の計算資源を有する様々な異なるサーバ「タイプ」をそれらのプラットホーム上へ提供する。

【0005】

これらのハードウェア供給者はしばしば、各顧客要求へ割り振られる一組の仮想計算資源（例えば「仮想マシン」）を顧客が指定することを可能にする仮想化を採用する。いくつかのハードウェア供給者は、同様なサービスを提供するが、他の顧客と共有されない専用物理的ハードウェアを顧客が規定することを可能にする。このような「ベアメタル（bare metal）」サービスは、シミュレーション及び他の高性能計算（ＨＰＣ）環境内に見られるものなど特にＣＰＵ集約的であるタスクのための強化された性能を提供し得る。

【0006】

仮想及び／又はベアメタルサービスを提供するかどうかにかかわらず、ハードウェア供給者はしばしば、規定計算資源を使用する間の時間だけの代価を顧客が払うオンデマンド「ペイパーユース：pay-per-use」モデル（定期的月間又は年間リース又は「定期購読」モデルの代わりに又はそれに加えて）を提供する。このような資源の効率的利用は、（一定の物理的計算資源を顧客の基地全体にわたって効率的に配備することにより価値を最大化するために）ハードウェア供給者にとって、そして（例えば、規定タスクをより迅速に完了するという時間節約恩恵とそれほど強力でない計算資源を提供するということの費用節約恩恵とをバランスすることにより価値を最適化するために）それらの顧客にとって重要である。

【0007】

ハードウェア供給者は、一定の物理的計算資源の利用を複数の顧客の重畳する要求全体にわたって割り振る際に「負荷バランス」問題に直面する。様々な「動的提供」手法が、様々な利用可能物理サーバ及び関連計算資源（メモリ、記憶装置、ネットワーク帯域幅など）間で、各顧客により規定された計算資源を再割り振りするために採用されてきた（例えば米国特許第９，００９，２９４号参照）。しかし、このような負荷バランス手法は、タスクの計算資源要件が動的に（すなわちタスクの実行中に）変化するシナリオに適切に対処しない。このようなシナリオでは、タスクの計算資源を様々な物理サーバ間で単に再割り振りすることは十分ではない。別の機構は、当該タスクへの計算資源の次善最適割り振りにより呈示される問題を、タスクの実行中の様々な時点で、識別しこれに対処することが要求される。

【0008】

ハードウェア供給者はタスクの計算資源の現在の利用（例えばＣＰＵ、ＲＡＭ、記憶装置、ネットワーク帯域幅などの利用割合）を監視し得るが、このような「計算資源利用」情報だけでは、タスクの最適「将来」資源要件を判断するのに不十分である。このような将来予測すなわち予報をすることは、実行されているアプリケーションと実施されているタスクの特定機能とに関係する内部「アプリケーション固有」情報へのアクセスを必要とするだろう。

【0009】

この問題への現在の一手法は、現在の要求へ割り振られる「AmazonＥＣ２インスタンス」（すなわち特定タイプの仮想サーバ）の数をいつ増加及び／又は減少すべきかを動的に判断する条件をその顧客が定義できるようにするAmazonの「ＥＣ２自動スケーリング」サービスにより例示される。並列処理環境において個別ＣＰＵコア上で実行するアプリケーションの複数の「インスタンス」と混同しないように、AmazonＥＣ２インスタンスは規定構成の計算資源（ＣＰＵコア、メモリ、記憶装置、ネットワーク帯域幅など）を有する仮想マシン又は仮想サーバである。顧客規定条件が満たされると、ＥＣ２インスタンスの数は顧客規定量だけ増加又は低減される。

【0010】

例えば、時間の経過に伴い外部クライアントウェブブラウザからの無数のＨＴＴＰ要求を処理するウェブサーバアプリケーションを考察する。Amazonの顧客（例えばウェブサイトの所有者）は当初、Amazonが４つのＥＣ２インスタンスを提供することを要求する可能性がある。ここで、各ＥＣ２インスタンスは８つのコアＣＰＵ、３２ＧＢのＲＡＭ、１６０ＧＢの記憶装置、及び１０ＧＢのイーサーネット接続を有する仮想サーバである。ウェブサーバアプリケーションのインスタンスが３２個のコアのそれぞれの上で実行する可能性があり、各コアは、毎秒様々なウェブブラウザからの何百又は何千もの外部ＨＴＴＰ要求を扱う可能性がある。

【0011】

外部クライアントウェブブラウザ要求の数が増加又は低下するにつれ、顧客は、ＥＣ２インスタンスの数を増加又は低減することを望み、これにより「最適」量の計算資源を時間の経過と共に提供しようとする可能性がある。例えば、顧客は、すべての現在のＥＣ２インスタンス全体にわたる毎秒の外部ＨＴＴＰ要求の数が所定閾値を越えると８つの追加ＥＣ２インスタンスの提供をトリガーするＥＣ２自動スケーリング条件を規定する可能性がある。逆に、別の条件は、ＨＴＴＰ要求の数がより低い所定閾値を下回ると既存ＥＣ２インスタンスの終了をトリガーする可能性がある。

【0012】

ＥＣ２インスタンスが除去されるとそれらのＥＣ２インスタンスの各ＣＰＵコア上で実行しているアプリケーションインスタンスは終了されるということに注意すべきである。同様に、ＥＣ２インスタンスが追加されると、新しいアプリケーションインスタンスはこれらの追加されたＥＣ２インスタンスのそれぞれのＥＣ２インスタンスの各ＣＰＵコア上にインストールされ、実行される。それにもかかわらず、これらの変更は、顧客の介在無しに、かつ完全に「最初からやり直して」タスクの現在の進捗のすべてを喪失すること無しに自動的に発生するので、「アプリケーション実行中に」発生すると言われる。

【0013】

外部ＨＴＴＰ要求は互いにほぼ独立であるので、ＨＴＴＰプロトコルのステートレス性質のおかげで、ウェブサーバアプリケーションにより行われるタスクは、複数のＣＰＵコアのそれぞれの上で同様な独立「サブタスク」（例えば外部ＨＴＴＰ要求）を同時に実行することによる並列処理から恩恵を受ける。さらに、将来のサブタスク計算は以前のこのような計算には一般的には依存しない（ＨＴＴＰプロトコルのステートレス性質にも起因する）ので、ウェブサーバアプリケーションはまた、計算資源の動的変化（例えばＥＣ２インスタンスの追加又は除去）に比較的免疫があり、ウェブサーバアプリケーションをAmazonのＥＣ２自動スケーリングサービスの理想的候補にする。

【0014】

しかし、このような依存性が存在する限り、顧客はこのような依存性を識別しこれらに対処しなければならない。このようないかなる機構も、実行されているアプリケーションと実施されているタスクの特定機能とに関係する内部アプリケーション固有情報の知識を有しないのでAmazonのＥＣ２自動スケーリングサービスにより提供されない。

【0015】

例えば、ウェブサーバアプリケーションが、複数の関連形式を含むウェブページ内の複数の外部ＨＴＴＰ要求を扱えば、これらの関連形式に関するいくつかのその後のサブタスク計算は以前の計算に依存する（例えば一形式のフィールドの値が別の形式のフィールドの値に依存する）可能性がある。したがって、ＥＣ２インスタンスの終了の場合、顧客は、このような依存性を検出し、それらに対処する（例えばこのような結果に依存するその後の計算を行う別のＥＣ２インスタンスによる使用のために、関連する以前の計算の結果を保存することにより）必要があるだろう。同様に、追加されたＥＣ２インスタンスの場合、顧客は、「新たに追加されたＥＣ２インスタンスにより行われるその後の計算が、依存する任意の以前の計算の結果をどこで取得すべきかを知る」ということを保証する必要があるだろう。

【0016】

並列処理のために特に設計されたアプリケーションはこのような依存性に対処する機構を含み得るが、上記アプリケーションは通常、少なくとも１つの下位組の提供された計算資源の「知識」（例えばＣＰＵコアの数）により事前構成されなければならなく、アプリケーションの実行中にこのような計算資源を修正することを困難なものにする。AmazonのＥＣ２自動スケーリングサービスは、ＥＣ２インスタンス間の通信のための（例えば、同じＥＣ２インスタンス上か別のＥＣ２インスタンス上かにかかわらず追加ＣＰＵコアが利用可能であるということを実行中のアプリケーションに知らせるための）組み込まれた機構を有しない。

【0017】

その結果、このＥＣ２自動スケーリング手法に対する重大な制限がある。１つの問題は、計算資源の変更が必要とされる条件及び変更の性質（例えば、条件が満たされると追加又は除去されるＥＣ２インスタンスの数）を顧客が規定しなければならないということである。さらに、効果的となるためには、このような条件は予測的でなければならなく、単に反応的ではあってはならない。例えば、外部ＨＴＴＰ要求が所定時刻に所定閾値を越えたということは、近未来へさえも続くことになるトラフィックパターンを反映してもよいし反映しなくてもよい。

【0018】

さらに重要なことに、顧客は、計算資源のこれらの動的変化の結果を管理するために「インスタンス間」（「サーバ間」を含む）依存性に対処することを任される。上に指摘したように、多くのアプリケーションは、中間計算を並列に行い得る（通常は、アプリケーションの複数のインスタンスを個別ＣＰＵコア上で同時に実行することにより）独立サブタスクの存在のおかげで並列処理から恩恵を受けるタスクを実施する。しかし、これらのアプリケーションはしばしば、１つのＣＰＵコア上のアプリケーションの１つのインスタンスにより行われるその後の計算がこれらの中間計算の結果に依存するインスタンス間依存性を呈示する（同じ又は他のＣＰＵコア上で又はさらには物理的又は仮想的サーバ全体にわたってサーバ間依存性を生じる）。

【0019】

これらのインスタンス間依存性の存在は、実行中にタスクへ割り振られる計算資源を修正しようする顧客にとって大きな重荷となる。上に指摘したように、アプリケーションが、並列処理用に設計されており、これらのインスタンス間依存性に対処するための機構を含んでも、顧客は、特定の計算資源が変化した（例えば、あるＣＰＵコアが追加又は除去された）ということを実行中のアプリケーションに通知するという問題を依然として任される。いかなるこのような機構も現在存在しない。

【0020】

シミュレーションアプリケーション（及び他のＨＰＣアプリケーション）は、時間が重なるが互いに依存しなく、したがって並列に行われ得る多くの同様なサブタスク計算に通常は関与するので並列処理環境から恩恵を受けるアプリケーションの主要例である。しかも、シミュレーションの過程中のその後の計算はしばしば、これらの以前の中間サブタスク計算の結果に依存する（すなわちインスタンス間依存性の存在に起因する）ので、シミュレーションアプリケーションは並列処理環境において正しく機能するためにこれらのインスタンス間依存性に対処しなければならない。

【0021】

シミュレーションアプリケーションは、インスタンス間依存性に対処する（例えば、それらの以前の結果に依存するその後のサブタスクを行うＣＰＵコア及びサーバ間で中間計算の結果を伝達することにより）ための機構も提供する一方で独立サブタスクの並列処理を容易にするように設計される。しかも、このような伝達を実施するために、シミュレーションアプリケーションはシミュレーションタスクにいくつかの制約（最低量のＲＡＭ又はネットワーク帯域幅を想定すること、又は顧客のシミュレーションデータ「モデル」の特定特性に基づき特定数のＣＰＵコアにより事前構成されることなど）を課する。

【0022】

換言すれば、シミュレーションアプリケーションは、その上で実行する少なくとも１つの下位組の計算資源の予備知識（事前構成を介し）を想定しておりシミュレーションアプリケーションの実行中に顧客がそれらの計算資源を修正しようとするという挑戦的課題を提示する。この挑戦的課題をより良く理解するために、どのようにシミュレーションアプリケーションが特定インスタンス間依存性に対処して、それ自身の「アプリケーション強要制約」の限界内で計算資源を利用するかを理解することが有用である。

【0023】

シミュレーションアプリケーションは、ありとあらゆる科学的及び工学的規律内で特定現実世界又は抽象システムの振る舞いを表すように設計された顧客提供データ「モデル」を利用する下位アルゴリズムを実施する。その環境を含むモデル化されたシステムは通常、個別構成要素又は「セル」（シミュレーション規律に依存して「素子」、「粒子」、「分子」などと時折呼ばれる）に分割される。これらの構成要素セルは、時間の経過と共に様々な変更を受けるいくつかの特性（長さ、密度、温度、圧力など）を有する。いかなる現実世界又は物理的カウンターパート（例えばロールプレイアプリケーション）も有しないシステムですら、様々な抽象的特性（例えば心理学的行動、感情、行為など）を呈示する構成要素セルに分割され得る。

【0024】

フロントバンパーを設計する自動車製造業者は、それらの自動車衝突の影響を固体壁（solid wall）へモデル化するためにシミューレーションソフトウェアを採用する可能性がある。壁に直接インパクトを与えるフトントバンパーの個々のセルの特性へのインパクトの影響は当初、このような計算が互いに独立である程度に並列に計算される（例えば、シミュレーションアプリケーションを複数のＣＰＵコア上で同時に実行することにより）可能性がある。しかし、時間の経過に伴う隣接セルへのインパクトの間接的影響は、これらの初期計算の結果に依存し、したがってインスタンス間依存性（サーバ間依存性を含む）を生じる。

【0025】

同様に、飛行機設計者は、翼自体を表すためだけでなく飛行中の翼の表面を取り囲む空気も表すために無数の個々のセルを採用することにより飛行機翼上の乱流の影響をシミュレーションする可能性がある。シミュレーションアプリケーションがその環境内で飛行中の飛行機のモデルを「実行する」場合、シミュレーションアプリケーションは、モデルにより課された規則又は制約に従ってセルの特性へのこれらの変更を計算する。

【0026】

シミュレーションの実行が進むにつれて、シミュレーションアプリケーションは（顧客のモデルにも従って）、個々のセルを複数セルに分割してもよいし（例えば構成要素セル間のより詳細な相互作用を処理するために）、逆に複数セルをまとめて単セルに合成してもよい。セルの数のこの修正はシミュレーションアプリケーションの計算資源の利用の効率にインパクトを与えるということに注意すべきである。例えば、シミュレーション実行中の所与時点で、（時間及び費用などの様々な他の要因の「グローバル最適化」だけでなく）最大並列化の要望とＣＰＵコア間のインスタンス間通信により課されるオーバーヘッドとのバランスに基づく「コア当たりセル」の理想数が存在し得る。したがって、所与時点におけるセルの数の変更は実際の規定計算資源を多少「最適」にし得る。

【0027】

特に並列処理及び他のＨＰＣ環境において必要とされるのは、このような計算資源の変更及びこのような変更の性質を保証する条件を判断する責任から顧客を自由にする一方で、特定タスクへ割り振られる計算資源を動的に最適化するための機構と処理である。このような機構及び処理はまた、アプリケーションがこのような変更により影響を受けるサーバ間及び他のインスタンス間依存性に対処することを可能にするアプリケーション強要（application-imposed）制約に自動的に従わなければならない。

【発明の概要】

【課題を解決するための手段】

【0028】

概要
本発明は、例えば、特定タスクの実行中の様々な時点で必要とされる特定タスクのための最適計算資源を判断することから顧客を自由にする仲介サーバプラットホームを提供することにより上記欠陥に対処するためのシステム及び方法の実施形態を含む。本発明は並列処理及び他のＨＰＣ環境から恩恵を受ける様々なタイプのアプリケーションへ適用され得るが、本明細書で論述される実施形態は、例示目的のために科学的及び技術的シミュレーションの領域に焦点を合わせる。

【0029】

しかし、その後の計算が以前のサブタスク計算の結果への依存性を有する独立サブタスクに関わるいかなるアプリケーションも本発明の恩恵を受け得る。さらに、特定ハードウェア及びソフトウェア実施形態が以下に説明されるが、本発明の様々な構成要素の機能は、他の個別構成要素に合成又は分割され得、本発明の精神から逸脱することなくハードウェア又はソフトウェアで実現され得る。

【0030】

一実施形態では、「シミュレーションサーバプラットホーム」は、それらのモデルのシミュレーションを実行することを望むエンドユーザ顧客と特定シミュレーションアプリケーションがユーザシミュレーションを実行する物理的計算資源のハードウェア供給者との間の仲介者（例えばインターネット又は他のネットワーク接続上の）として提供される。この実施形態では、シミュレーションサーバプラットホームは、１つ又は複数のハードウェア供給者の「顧客」として働き、一方、エンドユーザはシミュレーションサーバプラットホームの「顧客」である。各シミュレーションアプリケーションの所有者は、そのアプリケーションを直接ユーザへ、又はシミュレーションサーバプラットホームの所有者を介し（又は、さらにはハードウェア供給者プラットホームの所有者を介し）ユーザへ間接的にライセンスし得る。

【0031】

例えば、エンドユーザは、インターネット上でシミュレーションサーバプラットホームとの接続を確立し、所望シミュレーションアプリケーションを規定し、そのシミュレーションデータモデル及び他の関連入力パラメータ及びデータファイルを提供する。一実施形態では、ユーザはまた、所望の初期組の計算資源を選択し、一方、別の実施形態では、シミュレーションサーバプラットホームが、ユーザにより提供される情報の解析に基づきこの初期判断を行う。

【0032】

いずれにしても、シミュレーションサーバプラットホームは、インターネット上で１つ又は複数のハードウェア供給者との接続を確立し、初期組の計算資源（すなわち各ハードウェア供給者により提示される利用可能計算資源タイプの中から物理的又は仮想的サーバの「クラスタ」）を提供する。シミュレーションサーバプラットホームは、ユーザのシミュレーションモデルを含む、他の関連ソフトウェア及びデータと共に、提供されたクラスタ上に適切なシミュレーションアプリケーション（例えば、各ＣＰＵコア上のシミュレーションアプリケーションのインスタンスを含む）をインストールし、次に、シミュレーションタスクの実行を開始する。シミュレーションは、現実世界において又はモデル化又はシミュレーションされた抽象的「システム」においてはるかに短い期間シミュレーションする一方で、何時間、何日間、又はさらには何週間も実行し得るということに留意されたい（例えば、１５秒の自動車衝突はシミュレーションするのに３週間かかり得る）。

【0033】

以下にさらに詳細に論述されるように、シミュレーションサーバプラットホームはまた、一実施形態では、「計測」機能を行い、これにより、特別提供ハードウェア上でシミュレーションが実行している時間とソフトウェア計算資源とを監視する。これは、シミュレーションサーバプラットホームの所有者が、ハードウェア供給者とシミュレーションアプリケーションの売り手とにより確立されたものから変動する（そしてシミュレーションサーバプラットホームの所有者へ課金される）ユーザ価格モデルを提示することを可能にする。

【0034】

例えば、ハードウェア計測に関し、３時間実行するシミュレーションは、各特別提供ハードウェア資源の費用に基づく価格計算を可能にするだろう。例えば、８ＧＢのＲＡＭ（そしてＣＰＵコアの＄０．１０と８ＧＢのＲＡＭの＄０．０５の「コア時間当たりの価格」）を有する１６コアサーバは、ＣＰＵコア及びＲＡＭだけを考慮して３時間のシミュレーション（４８コア時間の＄４．８０のＣＰＵ価格と＄２．４０のＲＡＭ価格）の＄７．００の価格を生じるだろう。ハードウェア供給者は通常、特定仮想サーバタイプの価格を提供するが、仲介シミュレーションサーバプラットホームの使用は、物理的又は仮想的サーバベースの価格とは対照的に、選択されたハードウェア供給者により提示されるものを真似ても真似なくてもよい広範なバリエーションの顧客価格モデル（例えばオンデマンド又は低優先価格）及び異なる「コア時間」又は個々の計算資源（例えばＲＡＭ、ネットワーク帯域幅など）の他の価格を可能にする。

【0035】

さらに、本発明はシミュレーションタスクへ割り振られた規定計算資源の修正を可能にするということを考えれば、本発明のハードウェア計測機能は、シミュレーションタスクの実行中に提供される各組の計算資源へ割り振られる時間（そして関連価格）を監視する。

【0036】

同様に、ソフトウェア計測に関して、シミュレーションサーバプラットホームは、特定シミュレーションアプリケーション（及び、一実施形態では、その各構成要素）が実行される時間を監視する。いくつかのシミュレーションアプリケーション売り手は測定されたソフトウェア価格モデルを採用するが、他のものは予約購読、シート毎、同時利用者又は他の価格モデルを利用し得る。いずれにしても、本発明のソフトウェア計測機能は、様々な異なる価格モデルを様々なユーザ又はグループのユーザへ提供する際の柔軟性を促進する。

【0037】

さらに、一実施形態では、様々な組の計算資源が時間の経過と共にシミュレーションタスクへ提供される場合に、様々なソフトウェア価格モデルが採用される。本発明のソフトウェア計測機能は、単一シミュレーションタスクの実行の過程中に実行する様々なシミュレーションアプリケーションへ（及びその特定構成要素へ）割り振られた時間の監視を可能にする。

【0038】

シミュレーションサーバプラットホームはまた、特定シミュレーションアプリケーション及び構成要素特徴に関するユーザの認証の仲介者として働く。一実施形態では、シミュレーションサーバプラットホームは、様々な異なる物理的場所（例えばユーザ、シミュレーションアプリケーションプロバイダ、１つ又は複数のハードウェア供給者の構内を含む）に又はさらには（それ自体がハードウェア供給者の物理的ハードウェア上に配備され得る）シミュレーションサーバプラットホーム上に直接的に配備され得るソフトウェア「ライセンスサーバ」と通信する。

【0039】

個々のシミュレーションタスクへ割り振られた計算資源の動的修正を容易にするために、シミュレーションサーバプラットホームは、一実施形態では、ユーザのシミュレーションタスク（すなわち、ユーザのシミュレーションアプリケーションを実行するシミュレーションデータモデル）を実行するためのハードウェア供給者プラットホーム上に計算資源のクラスタを提供する「クラスタサービス」を含む。一実施形態では、クラスタは、ＣＰＵコア、ＲＡＭ、記憶装置、ネットワーク帯域幅などの特定構成を有するハードウェア供給者により提示される選択されたタイプの仮想サーバの１つ又は複数の仮想サーバを含む。

【0040】

上に指摘したように、シミュレーションアプリケーションは並列処理環境内のクラスタ上で実行するように設計され、ここでは、シミュレーションアプリケーションの個々のインスタンスは、個別ＣＰＵコア上で並列に実行し、独立サブタスク計算を同時に行う。さらに、シミュレーションアプリケーションは、シミュレーションアプリケーションの１つのインスタンスにより行われるその後のサブタスク計算が同じ又は他のインスタンスにより行われた以前のサブタスク計算の結果に依存するインスタンス間（サーバ間を含む）依存性（すなわちＣＰＵコア全体にわたる、そしていくつかのケースでは仮想サーバ全体にわたる）に対処する。

【0041】

シミュレーションサーバプラットホームはまた、一実施形態では、様々なユーザ指定入力パラメータ、ユーザのシミュレーションモデル、必要な下位組の規定計算資源（例えばＣＰＵコアの数）及び他の関連ソフトウェア、入力パラメータ及びデータファイルによりシミュレーションアプリケーションを構成する「シミュレーションサービス」を含む。上に指摘したように、クラスタ内で規定される計算資源は、規定される必要がなくてもシミュレーションアプリケーションにより課されるいかなる制約（例えば最低量のＲＡＭ）にも従わなければいない。

【0042】

この実施形態では、シミュレーションサービスは、各ＣＰＵコア上のシミュレーションアプリケーションのインスタンスを含むクラスタ内のすべての関連ソフトウェア及びデータ、及び以下にさらに詳細に説明される本発明の他の構成要素に一意的な他のソフトウェアをインストールする。最後に、シミュレーションサービスは、クラスタ内の各仮想サーバ内の各ＣＰＵコア上でシミュレーションアプリケーションの各インスタンスの実行を開始する。

【0043】

シミュレーションサーバプラットホームはさらに、一実施形態では、クラスタ内の計算資源のシミュレーションアプリケーションの使用に関係する様々な「資源変更指標」を時間の経過と共に動的に監視するシミュレーション監視サービスを含み、シミュレーションアプリケーションへ割り振られた現在の計算資源と当該変更（例えば十分な数の追加ＣＰＵコアを有する異なるタイプの仮想サーバ）の性質との変更が保証されるかどうかそしてそれがいつなのかを判断するために連続ベースで本発明により利用される情報を提供する。

【0044】

以下にさらに詳細に説明されるように、このような資源変更指標は、一実施形態では、「計算資源利用」情報（シミュレーションアプリケーションのインスタンスによる特定計算資源の現在の利用の割合など）と、クラスタ内の現在の計算資源のシミュレーションアプリケーションの使用がいくつかの所定ゴールを満たす程度を反映してシミュレーションアプリケーションの将来の計算資源要件の予測を容易にする「アプリケーション固有」情報（監視されている特定シミュレーションアプリケーションタスクに関係する）との両方を含む。

【0045】

加えて、一実施形態では、シミュレーション監視サービスは、以下にさらに詳細に論述されるように過去の傾向が識別され得るように各計算資源に関する計算資源利用及びアプリケーション固有情報を時間の経過と共に監視し格納する。例えば、所与の時点で、シミュレーション監視サービスは、規定クラスタ内のＣＰＵ、ＲＡＭ、記憶装置及びネットワーク帯域幅資源のシミュレーションタスクの利用を監視する。特定仮想サーバ上のＣＰＵコアは、現在５８％ＣＰＵ利用率を呈示し得、一方、利用可能ＲＡＭの７８％が使用中であり得る。

【0046】

個々に採取されるこのような現在及び過去の情報は、特定規定計算資源の増加又は低減の必要性を（例えば所定閾値に基づき）示唆し得る。別の実施形態では、より全体論的（さらには予測的）解析が、計算資源利用とアプリケーション固有情報との両方を全体として考慮する規則ベース又は機械学習エンジンにより容易にされる。

【0047】

資源変更指標はまた、監視されている特定シミュレーションアプリケーションタスクに関係するアプリケーション固有情報を含む。例えば、シミュレーションが進むにつれて、シミュレーションアプリケーションは、計算資源の変更が保証されるかどうかを推論し得る情報を抽出するためにシミュレーション監視サービスにより解析される「出力ファイル」へ様々なデータを書き込む。

【0048】

シミュレーションアプリケーションは、本発明により採用されるものとは全く異なる目的のためにデータを出力ファイルへ書き込むということに注意すべきである。このような情報は、様々な理由のためのユーザによる手動解析（恐らく解析的ツールの支援を伴う）に向けられる。例えば、ユーザは、シミュレーションのトラブルシュートを行い、シミュレーションを停止することを是認するエラーが発生したかどうかを出力ファイル内の情報から判断し、そして恐らく、問題が解決された（例えばシミュレーションモデル内のバグを正すことにより）将来時点でシミュレーションを再実行し得る。別のシナリオでは、ユーザは、シミュレーションの効率を評価するためにこの情報を解析し、そして将来のシミュレーションが、短い経過時間後に実行し、より少ない計算資源を利用し、又はそうでなければユーザが望む所望制約が何であってもそれを満たすように、恐らく、モデル又は入力データに対し変更を行い得る。

【0049】

いずれにしても、一実施形態では、シミュレーション監視サービスは、シミュレーションアプリケーションの現在の計算資源の使用の効率に関する貴重な洞察とその潜在的将来計算資源要件（将来の計算資源利用の予測を含む）とを提供する情報の出力ファイルを解析する。本発明は単一の固定組の計算資源がシミュレーションタスク全体の実行を通じて最適であるという「一般通念」に挑戦しているということが強調されるべきである。様々な異なるタイプの情報が、この解析と、いつ計算資源の変更とこのような変更の性質及び程度とが是認されるかの判断とを容易にするために出力ファイルから抽出される。

【0050】

例えば、上に指摘したように、シミュレーションアプリケーションは時々、セルを複数セルに分割する又は複数セルを単一セルに合成し得、これにより規定のコア当たりセル比を変更し、そして恐らく、より多い又は少ないＣＰＵコアの必要性を示唆する、又はセルの数又は他の関連要因の将来予測を少なくとも考慮する。出力ファイル内に見つかった又はそれから推測された他の情報がディスクＩ／Ｏ動作に関係する。例えば、時間の経過に伴うディスクＩ／Ｏ動作の増加は、インスタンス間又はサーバ間通信における不均衡を示唆する可能性があり、恐らく、このような増加が特定速度で継続すると予測されればＣＰＵコア当たりより多くのＲＡＭの必要性を示唆する。他のシナリオでは、特定計算の結果は、例えばシミュレーション（例えば燃焼サイクル）の資源集約的局面が開始されたということを示唆する可能性がある。

【0051】

上にも指摘したように、シミュレーションアプリケーション自体は、シミュレーションアプリケーションへ割り振られた計算資源を修正する前にも考慮されなければならないいくつかの計算資源制約を課す。これらの「アプリケーション強要制約」は、シミュレーションアプリケーションが計算資源情報のいくつかにより事前構成される（例えば入力パラメータ又は構成ファイルを介し）ということを必要とする。例えば、シミュレーションアプリケーションは通常、例えばＣＰＵコア間の通信を処理することにより正しく機能し関連インスタンス間依存性に対処するためにアプリケーションのインスタンスがインストールされる特定数のＣＰＵコアを「知ら」なければならない。いくつかの計算資源仕様の当該知識無しに、シミュレーションアプリケーションは、ＣＰＵコアにより行われるその後の独立サブタスク計算が恐らく他の物理的又は仮想的サーバ上で他のＣＰＵコアにより行われた以前の計算からの結果を必要とする場合に発生する依存性に対処することができない可能性がある。

【0052】

したがって、シミュレーションアプリケーションは実行が始まる前に必要計算資源仕様により事前構成されるということが肝要である。シミュレーションアプリケーションが実行中に再構成されることができれば、計算資源の変更はシミュレーションタスクの実行を一切停止することなく動的に行われる。しかし、シミューレーションソフトウェア設計における現在の制限を所与として、本発明は、一実施形態では、計算資源の変更が是認されると現在のクラスタにおけるシミュレーションアプリケーションの実行を一時的に中止し、新しいクラスタ上のシミュレーションタスクのインスタンスを再開する。しかも、このような処理は、現在の中間「シミュレーション状態」の知識（すなわちすべての変数の正確な状態）を必要とする。

【0053】

したがって、資源変更指標を監視することに加えて、シミュレーションサービスはまた、一実施形態では、シミュレーションアプリケーションにより生成されそして現在の中間シミュレーション状態を含む「再開ファイル」の書き込みを監視する。多くの場合、シミュレーションアプリケーションがこれらの再開ファイルをディスクへ書き込む頻度はシミュレーションアプリケーションが実行される前に構成され得るが、シミュレーション状態全体を余りに頻繁に保存することは禁止的であり得る（例えば、シミュレーション状態全体を保存するために必要とされる時間及び他の資源のために）ということに注意すべきである。

【0054】

出力ファイルと同様に、これらの再開ファイルは、本発明により利用されるものとは異なる目的（耐障害性）に向けられる。「チェックポインティング（checkpointing）」と時折呼ばれるこのプロセスは、アプリケーションの状態のディスクへの定期的書き込みに関与するので、アプリケーションは、故障（例えばハードウェア故障、ソフトウェアクラッシュなど）の場合にはこの中間状態から再開され得る。

【0055】

しかし、シミュレーションサーバプラットホームは、一実施形態では、ハードウェア又はソフトウェア故障から回復する目的のためではなくアプリケーション実行中に計算資源の変更を容易にする目的のためにこれらの再開ファイルを利用する（たとえ、変更自体がシミュレーションアプリケーションのインスタンスの実行を中止することと再開することとに関与しても）。換言すれば、この実施形態では、シミュレーションサーバプラットホームは、ハードウェア供給者の現在の提供クラスタ上で実行するシミュレーションを意図的に終了し、異なる計算資源を有する新しいクラスタ（同じ又は異なるハードウェア供給者又は複数のハードウェア供給者からの）を提供する。ここでは、シミュレーションサーバプラットホームは、選択された再開ファイル内に含まれる保存された中間シミュレーション状態から再開し得る。

【0056】

耐障害性又は故障シナリオとは異なり、シミュレーションサーバプラットホームは、適切な再開ファイルが存在するかどうかと正確にいつシミュレーションタスクの実行を中止すべきかとを予め知る（リアルタイム監視に基づき）。さらに、一実施形態では、予測計算資源活用に基づき、シミュレーションサーバプラットホームは、この変更を有効にするための最適時間を判断し、１つ又は複数のハードウェア供給者プラットホーム上で利用可能様々なタイプの計算資源により課された制約とシミュレーションアプリケーション（新しい組の計算資源に準拠するように再構成される）自体により課された制約とに準拠する最適な新しい組の計算資源を生成する。

【0057】

シミュレーションサーバプラットホームは追加的に、一実施形態では、いつ計算資源の変更が是認されるかを判断するために計算資源変更指標と既存再開ファイルとを連続的に解析する計算資源評価モジュールを含む。他の方法で是認された変更は十分に最近の再開ファイルの欠如により影響を受け得るということに注意すべきである。別の実施形態では、ユーザは、このようなアプリケーションが再開ファイルを生成する頻度を制御するためのいくつかのシミュレーションアプリケーションを構成し得る。

【0058】

以下にさらに詳細に論述されるように、計算資源評価モジュールは、アプリケーションの将来計算資源要件を予測するように設計された様々な技術（所定式及びトリガー、規則ベース解析、及び機械学習を含む）を適用する。一実施形態では、この被監視情報は、１つ又は複数の所定閾値条件が計算資源の変更を是認するように満たされたかどうかを判断するために連続的に解析される。この解析プロセスはユーザ介在の必要性無しにリアルタイムで自動的に行われるということが強調されるべきである。

【0059】

現在の一組の提供された計算資源の変更が是認される場合、シミュレーションサーバプラットホームはさらに、一実施形態では、計算資源評価モジュールにより行われるものと同様な技術を適用する計算資源計算モジュールを含むが、１つ又は複数のハードウェア供給者プラットホーム上で利用可能なタイプの計算資源により課される追加制約を考慮する。例えば、変更が是認されたということを判断すると、計算資源計算モジュールは、追加の１６個のＣＰＵコアが最適に必要とされるが３２ＧＢ未満のＲＡＭが必要とされるということを判断し得、場合によっては、１つ又は複数のハードウェア供給者（恐らく、シミュレーションアプリケーションが現在実行しているものとは異なるハードウェア供給者ですら）により提示される異なるタイプの仮想サーバの選択を生じる。

【0060】

計算資源計算モジュールが、修正計算資源の所望の新しいクラスタの仕様を生成すると、現在のクラスタは置換されなければならない。シミュレーションサーバプラットホームは、一実施形態では、選択されたハードウェア供給者プラットホーム上に修正計算資源の新しいクラスタを提供することと、（新しいクラスタにより必要とされ得る関連データを保存した後）シミュレーションアプリケーションが現在実行している現在のクラスタを終了することとをクラスタサービスに指示するシミュレーション資源管理プログラムを含む。

【0061】

次に、シミュレーションサーバプラットホームは、必要とされる下位組の修正計算資源の仕様と、シミュレーションアプリケーションが実行を再開し得る中間シミュレーション状態を含む選択された再開ファイルの場所とによりシミュレーションアプリケーションを再構成することをシミュレーションサービスに指示する。

【0062】

次に、シミュレーションサービスは、各ＣＰＵコア上のシミュレーションアプリケーションのインスタンスを含む新しいクラスタ内のすべての関連ソフトウェア及びデータ並びに以下にさらに詳細に説明される本発明の他の構成要素に一意的な他のソフトウェアをインストールする。最後に、シミュレーションサービスは、新しいクラスタにおける各仮想サーバ内の各ＣＰＵコア上のシミュレーションアプリケーションの各インスタンスの実行を開始する（すなわち、保存された中間シミュレーション状態からの実行を「再開」する）。

【0063】

一実施形態では、ユーザは、最短全体実行時間、一番安い計算資源料金、又は様々な他のゴールを最適化することなどの１つ又は複数の所定グローバル最適化ゴール（１つ又は複数のこのようなゴールをバランスする最適化機能を含む）を規定する。この実施形態では、シミュレーションサーバプラットホームは、ユーザの規定ゴールを最適化するために現在の計算資源をいつそしてどの程度修正するかのその判断においてこのようなゴールを調整する。特に、シミュレーションサーバプラットホームは、資源変更指標とアプリケーション固有情報との両方を監視し、シミュレーションアプリケーションの現在の計算資源の使用がこのような所定ゴールを満たす程度を評価する。

【0064】

別の実施形態では、シミュレーションサーバプラットホームは、このような段階をリアルタイムに動的に判断することとは対照的に、「シミュレーション段階」及び関連組の計算資源との数（例えば以前のシミュレーションからのユーザ提供情報に基づき）を予め判断する。この実施形態では、シミュレーションサーバプラットホームは、１つの所定シミュレーション段階から別の段階への遷移をいつ有効にすべきかを判断する必要がある。

【0065】

本発明の別の代替実施形態では、シミュレーションサーバプラットホームは、例えば以前のシミュレーションタスクの解析及び他のユーザ提供情報に基づく計算資源の推薦をユーザへ提供する（計算資源の自動変更を有効にするのではなく）。別の代替案実施形態では、シミュレーションサーバプラットホームは、シミュレーションタスクの将来の「完全な」実行のための計算資源要件を予測する目的のためにシミュレーションアプリケーションの一部（例えば主要ループ又は期間を通じ１回のパス）を「事前実行」する。以下の添付図面に示される本発明の実施形態の詳細説明に移る前に、本発明はそれらのシミュレーションタスクが実行されることになる単一の固定組の計算資源を現在選択しなければならないユーザに重要な恩恵を提供するということに注意すべきである。例えば、計算資源のクラスタを「過剰規定する」ユーザは最終的にシミュレーションタスクに支払い過ぎ、一方、計算資源のクラスタを「過小規定する」ユーザは、それらのシミュレーションタスクが余りにゆっくりと実行する又は恐らく完全に失敗するということを発見し得る。

【図面の簡単な説明】

【0066】

【図1】本発明のシミュレーションサーバプラットホームの主要構成要素の一実施形態のアーキテクチャブロックダイヤグラムである。

【図2】本発明のシミュレーションサーバプラットホームの主要構成要素の動的相互作用の一実施形態を示すアーキテクチャダイアグラムである。

【図3】本発明のシミュレーションサーバプラットホーム上でハードウェア計測モジュールにより行われる処理の一実施形態を示すフローチャートである。

【図4】本発明のシミュレーションサーバプラットホーム上でソフトウェア計測モジュールにより行われるプロセスの一実施形態を示すフローチャートである。

【図5】本発明のシミュレーションサーバプラットホームによりハードウェア供給者プラットホーム上に提供されたクラスタの主要構成要素の一実施形態を示すアーキテクチャブロックダイヤグラムである。

【図6】本発明のシミュレーションサーバプラットホーム上のシミュレーション資源管理プログラムの主要構成要素の一実施形態を示すアーキテクチャブロックダイヤグラムである。

【図7】本発明のシミュレーションサーバプラットホーム上のシミュレーション資源管理プログラムの動的動作の一実施形態を示すフローチャートである。

【発明を実施するための形態】

【0067】

詳細な説明
本発明のシステム及び方法の詳細な実施形態は添付図面に示され以下に説明される。最初に、本発明は添付図面を参照して以下に論述される特定実施形態に限定されないということに留意すべきである。例えば、本発明は、本発明の精神から逸脱することなく、様々な技術的トレードオフを反映するより少ない又は多い様々な概念的モジュール（ハードウェア又はソフトウェアで実装される）間に再割り振りされる機能と共に個別サーバプラットホームに一体化される可能性がある。本発明のシステム及び方法の追加実施形態は当業者に明らかになる。

【0068】

図１に移ると、本発明のシステム１００は、ユーザがユーザ装置１４０（デスクトップ及びラップトップコンピュータ、スマートフォンなど）を介し様々なハードウェア供給者プラットホーム１３０の物理的ハードウェア上でそれぞれのシミュレーションを実行することができるようにする。シミュレーションサーバプラットホーム１０１は、ユーザ装置１４０とハードウェア供給者プラットホーム１３０との間で仲介者（インターネット１２５を介し）として働き、シミュレーションプロセスを強化及び簡単にするように設計された多様な特徴をユーザへ提供する。

【0069】

例えば、ユーザは、複数の異なるハードウェア供給者を識別し契約し、ユーザの所望シミュレーションアプリケーションをインストール及び構成し、関連ライセンスサーバ配備及び認証プロセスを管理する必要がない。その代りに、ユーザは、ハードウェア及びソフトウェア利用の自動計測及び組み込まれた柔軟な課金システムと共にシミュレーションを実行するように調整されたユーザフレンドリーインターフェースを備える。

【0070】

さらに重要なことには、以下でさらに詳細に説明されるように、ユーザはもはや単一の固定組の計算資源に制限されない。その代りに、シミュレーションサーバプラットホーム１０１は、ユーザのシミュレーションタスクが実行中に、計算資源の変更が是認される「最適な」時点と「最適な」新しい組の計算資源とを動的に判断する。さらに、シミュレーションサーバ１０１は、インスタンス間（サーバ間を含む）依存性にユーザ介在なく対処する選択されたシミュレーションアプリケーションの能力を保つ一方で、計算資源の変更を１つ又は複数のハードウェア供給者プラットホーム１３０全体にわたって自動的に実施する。

【0071】

一実施形態では、ユーザは、インターネット１２５を介しシミュレーションサーバプラットホーム１０１と通信するために標準ＨＷ／ＳＷ１４２（標準ＣＰＵ、ディスプレイ、Ｉ／Ｏ装置、メモリなどを含む）を採用する。この実施形態ではカスタムクライアントアプリケーションを必要とする代わりに、ユーザがシミュレーションサーバプラットホーム１０１と通信するユーザインターフェース１４１を提供するために標準ウェブブラウザが採用される。したがって、各ユーザ装置１４０により行われる機能は、メモリ内に格納された命令を実行する標準ＣＰＵにより実施される。他の実施形態では、カスタムハードウェア及びソフトウェアが本発明の精神から逸脱することなく採用され得る。

【0072】

同様に、ハードウェア供給者プラットホーム１３０は、メモリ内に格納された命令を実行するＣＰＵを介しその機能を実施する物理的ＨＷ／ＳＷ１３２を含む。上に指摘したように、ハードウェア供給者はしばしば、当該技術分野で良く知られているように、同時実行中の複数ユーザアプリケーション間で物理的ＨＷ／ＳＷ１３２を共有するように設計された様々な仮想化ハードウェア及びソフトウェア機構も含む。シミュレーションサーバプラットホーム１０１はまた、メモリ内に格納された命令を実行するＣＰＵを介しその機能を実施するためにサーバＨＷ／ＳＷ１０２を含む。一実施形態では、シミュレーションサーバプラットホーム１０１の機能の多くは、ハードウェア供給者プラットホーム１３０のうちの１つ又は複数の上に常駐し、シミュレーションサーバプラットホーム１０１の所有者／オペレータをそのユーザにサービスするためにそれ自身の標準物理的ハードウェア及びソフトウェア構成要素を提供することから解放する。サーバＨＷ／ＳＷ１０２のいくつかの標準構成要素は依然として、シミュレーションサーバプラットホーム１０１の機能への遠隔管理者アクセスを可能にするためにシミュレーションサーバプラットホーム１０１の所有者／オペレータの構内に常駐する。

【0073】

ユーザがシミュレーションタスクを開始すると、シミュレーションサーバプラットホーム１０１は、ユーザのシミュレーションタスクを実施するためにクラスタ１３１を１つ又は複数のハードウェア供給者プラットホーム１３０上に配備する。各クラスタ１３１の様々な主要構成要素は以下にさらに詳細に論述される（特に図５を参照して）が、ユーザにより開始されるシミュレーションタスク毎に、シミュレーションサーバプラットホーム１０１のいくつかの構成要素は、当該タスクのシミュレーションプロセスを管理するために複製されて１つ又は複数のハードウェア供給者プラットホーム１３０のクラスタ１３１上に配備されるということに注意すべきである。概要レベルで、シミュレーションランナー１３３は、シミュレーションアプリケーションインスタンス１３９自体により実施されるユーザのシミュレーションタスクの動作（すなわち通常は複数のＣＰＵコア全体にわたって並列に実行するユーザにより選択されたシミュレーションアプリケーションのインスタンス）を管理する。

【0074】

シミュレーションサーバプラットホーム１０１の主要構成要素に移ると、サーバＤＢ（データベース）１０５は、管理者課金、並びにユーザ、ハードウェア供給者、及びシミュレーションアプリケーションプロバイダに関するプロファイル及び他のデータ、並びにシミュレーションサーバプラットホーム１０１の特定構成要素に関係するデータを含む様々な異なるタイプの現在及び過去のデータを格納するために採用される（各構成要素の動作に関しては以下にさらに詳細に論述される）。しかし、サーバＤＢ１０５内に格納される情報は、ユーザのシミュレーションタスク毎に提供されるクラスタ１３１上に格納される情報とは区別されるべきであり、これについても以下にさらに詳細に論述される。他の実施形態では、サーバＤＢ１０５の格納要件は、本発明の精神から逸脱することなく、複数の個別データベース並びに他の短期的及び長期的ファイル格納機構及び物理的装置により満たされ得る。例えば、一実施形態では、シミュレーションタスクに関係するユーザデータ及び他の情報は安全な記憶装置内に暗号化され分離され、様々な標準的ハードウェア及びソフトウェアセキュリティプロトコルにより保護される。

【0075】

シミュレーションサーバプラットホーム１０１は、標準的認証プロセスの一部として、ユーザが本システムに最初にアクセスするときにユーザを認証する。しかし、ユーザがシミュレーションタスクを開始し得る前に、ユーザは最初に、ユーザのモデルにより表される振る舞いをシミュレーションするためにユーザにより選択される特定シミュレーションアプリケーションの使用のために認証されなければならない。別の実施形態では、いくつかのシミュレーションアプリケーションはまた、シミュレーションアプリケーションの個々の構成要素の使用のためにユーザが認証されるということを要求する。このような認証は、シミュレーションタスクが開始される前に又は他の実施形態ではシミュレーションの実行中に（例えば、個々の構成要素がアクセスされた時点で）発生し得る。

【0076】

この認証プロセスは、個々のシミュレーションアプリケーションの所有者及び第三者ライセンスサーバ売り手により提供されるライセンスサーバ１１２を介し実施される。ライセンスサーバ１１２は標準的サーバハードウェア上で実行するソフトウェアで構成されてもよいし、カスタムサーバハードウェア装置内で具現化されてもよい。さらに、ライセンスサーバ１１２は、ユーザの構内に、シミュレーションアプリケーションプロバイダ内に、又は他の場所（シミュレーションサーバプラットホーム１０１の構内を含む）に配備され得る。いずれにしても、認証プロセス（及びライセンスサーバ１１２との通信全体）は、ソフトウェア計測モジュール１１３により行われるソフトウェア計測プロセスの一部としてライセンスサービス１１３ａにより管理される。

【0077】

図４を参照して以下でさらに詳細に説明されるように、ソフトウェア計測モジュール１１３は、シミュレーションアプリケーション（又はその構成要素）がユーザのシミュレーションタスクの実行中に使用される全時間を監視する。同様に、ハードウェア計測モジュール１１４（図３に関して以下にさらに詳細に論述される）は、ハードウェア計算資源がユーザのシミュレーションタスクの実行中に使用される全時間を監視する。複数の異なる組の計算資源がユーザのシミュレーションタスクの実行中に配備される場合にはハードウェア計測モジュール１１４は各一組の計算資源が使用される全時間を監視することになるということに注意すべきである。別の実施形態では、ハードウェア計測モジュール１１４は、複数のハードウェア供給者プラットホーム１３０全体にわたる個人ユーザのタスクの計算資源の使用を監視する（そして、さらに別の実施形態では、個々のハードウェア資源は別々に監視される）。

【0078】

ソフトウェア計測モジュール１１３とハードウェア計測モジュール１１４は共同で、当該シミュレーションタスクが１つ又は複数のシミュレーションアプリケーション、１つ又は複数のハードウェア供給者プラットホーム、及び１つ又は複数の異なる組の計算資源に関与するかどうかにかかわらず、ユーザが費用、時間、及びユーザの個々のシミュレーションタスクの他の所望特性を最適化することを可能にする柔軟な「ペイパーユース」課金モデルを容易にする（以下にさらに詳細に論述されるように）。

【0079】

ユーザがシミュレーションタスクを開始すると、クラスタサービス１０４は、利用可能ハードウェア供給者プラットホーム１３０のうちの１つ又は複数から計算資源のクラスタを提供する。一実施形態では、ユーザは、シミュレーションサーバプラットホーム１０１により提供される様々な利用可能選択の中から選択される初期組の計算資源を判断する。別の実施形態では、シミュレーションサーバプラットホーム１０１は、この初期組の計算資源を判断し、ユーザのシミュレーションタスクが実行中にその後の一組の計算資源を判断する以下に説明される技術を採用する。

【0080】

利用可能性監視器１０４ａは、ハードウェア供給者プラットホーム１３０により提供される様々な仮想サーバタイプの利用可能性に関する情報（現在利用可能容量及び関連価格を含む）を維持する。所定時刻に、各ユーザのシミュレーションタスクは、１つ又は複数のハードウェア供給者プラットホーム１３０から提供される仮想サーバのクラスタに関連付けられることになる。しかし、ハードウェア供給者プラットホーム１３０のそれぞれにより提示される様々なタイプの仮想サーバ（そして各タイプの容量並びに価格）は時間の経過と共に変動し得る。

【0081】

上に指摘したように、ハードウェア供給者の観点からは、シミュレーションサーバプラットホーム１０１は、個人ユーザのシミュレーションタスクに関連付けられた１つ又は複数の仮想サーバのクラスタを提供する顧客である。しかし、シミュレーションサーバプラットホーム１０１の観点からは、各ユーザは、そのシミュレーションタスクが可変計算資源要件を有する顧客である（仮想サーバのクラスタとして当初分類されてもされなくてもよい）。以下でさらに詳細に説明されるように、これらの計算資源要件は（シミュレーションタスクが開始される前に当初確立される、又はシミュレーションタスクが実行中の様々な異なる時点で後で確立されるかにかかわらず）、１つ又は複数のハードウェア供給者プラットホーム１３０により現在利用可能にされている仮想サーバ（１つ又は複数の特定仮想サーバタイプ）のクラスタ内へ効果的に「翻訳」される。

【0082】

いずれにしても、シミュレーションサーバプラットホーム１０１とハードウェア供給者プラットホーム１３０のそれぞれとの間の接続は、ハードウェア供給者アダプタ１０４ｂ（すなわち、情報の双方向通信及び交換を可能にするカスタムＡＰＩ）を介しインターネット１２５上で維持される。例えば、ハードウェア供給者アダプタ１０４ｂは、ハードウェア供給者プラットホーム１３０から仮想サーバのクラスタを提供（及び終了）するために及びユーザのシミュレーションタスクに関するステータス情報を取得するためにシミュレーションサーバプラットホーム１０１により採用される。以下でさらに詳細に説明されるように、このステータス情報は、計測目的のため（例えばハードウェア計測モジュール１１４及びソフトウェア計測モジュール１１３による使用のため）だけでなく各ユーザのシミュレーションタスクの実行に関係するデータ（例えば各計算資源に関する時間の経過と共に監視された計算資源利用及びアプリケーション固有情報）を監視するためにも採用される。

【0083】

クラスタサービス１０４がユーザのシミュレーションタスクの実行のためのクラスタを提供すると、シミュレーションサービス１０３は、ユーザのシミュレーションデータモデルと必要下位組の規定計算資源と共に様々なユーザ指定入力パラメータによりユーザの選択されたシミュレーションアプリケーション（又は、別の実施形態では、複数の異なるシミュレーションアプリケーション）を構成する。上に指摘したように、これらの規定計算資源と他のアプリケーション強要制約は、ユーザのモデルを正しくシミュレーションして任意のインスタンス間（そしてサーバ間）依存性に対処するためにシミュレーションアプリケーションにより必要とされる。

【0084】

シミュレーションサービス１０３はまた、すべての関連ソフトウェア及びデータを、提供されたクラスタ内にインストールする。例えば、クラスタ内の各仮想サーバ上にシミュレーションアプリケーションを構成することに加えて、当該シミュレーションアプリケーションのインスタンスが、このような各仮想サーバ上で各ＣＰＵコアにより実行するためにインストールされなければならない。各クラスタ上にインストールされる追加ソフトウェア及びデータ構成要素は図５を参照して以下にさらに詳細に論述されることになる。すべての関連ソフトウェア及びデータが構成されインストールされると、シミュレーションサービス１０３は、クラスタ内の各仮想サーバ内の各ＣＰＵコア上でシミュレーションアプリケーションの各インスタンスの実行を開始する。

【0085】

最後に、シミュレーション資源マネジャ１１０は、一実施形態では、実行中にユーザのシミュレーションタスクへ割り振られた計算資源を修正する動的プロセスを管理する責任を負う。図６と図７を参照して以下にさらに詳細に論述されるように、シミュレーション資源マネジャ１１０は、その提供されたクラスタにおいて実行中に、各ユーザのシミュレーションタスクの実行を連続的に監視し、当該提供クラスタに関連付けられた現在の計算資源を修正する必要性を証拠付ける様々な「資源変更指標」を探索する。これらの資源変更指標は、「計算資源利用」情報（ＲＡＭ、記憶装置、ネットワーク帯域幅など各ＣＰＵコア及び他の計算資源のパーセント利用率など）と、ユーザのシミュレーションタスクに関係するアプリケーション固有情報（例えばシミュレーションアプリケーションにより動的に書き込まれた出力ファイルから抽出されるユーザのモデル内のセルの現在数）とを含む。

【0086】

シミュレーションアプリケーションにより生成される時折再開ファイルと共にこれらの資源変更指標を抽出すると、シミュレーション資源マネジャ１１０は計算資源の変更が是認される最適時点（もしあれば）を判断するためにこの情報を連続的に解析する。このような変更が是認されれば、シミュレーション資源マネジャ１１０はまた、最適な新しい組の計算資源（例えば１６個の追加ＣＰＵコア、８ＧＢ未満のＲＡＭなど）を判断し、次に、これを、１つ又は複数のハードウェア供給者プラットホーム１３０上（いくつかのケースでは、例えば当該時間における適切な仮想サーバタイプの欠如に起因して、現在のクラスタに採用されたものとは異なるハードウェア供給者プラットホーム上であり得る）の仮想サーバの利用可能クラスタに「翻訳」する。

【0087】

以下でさらに詳細に説明されるように、この解析は、所定条件及び閾値の比較的単純な計算から、複雑な規則ベース解析及び一実施形態では将来計算資源要件の評価に関わる予測的機械学習手法までの範囲にわたり得る。いずれにしても、このような解析が計算資源の変更をトリガーすると、シミュレーション資源マネジャ１１０は、新しいクラスタを提供するためにクラスタサービス１０４を呼び出し、現在のクラスタを終了し、新しいクラスタ上でユーザのシミュレーションタスクの実行を「再開」する。

【0088】

上に指摘したように、シミュレーションアプリケーションが実行を（例えば選択された再開ファイルに含まれる中間シミュレーション状態から）再開し得ることを保証するために、シミュレーション資源マネジャ１１０は、実行を開始（再開）する前に必要アプリケーション強要制約（例えば新しいクラスタ内のＣＰＵコアの数）により新しいクラスタ内のシミュレーションアプリケーションを構成する。

【0089】

シミュレーションサーバプラットホーム１０１の構成要素自体は、一実施形態では、１つ又は複数のハードウェア供給者プラットホーム１３０の個別クラスタ上にインストールされ、そこから、ウェブブラウザインターフェース及び適切な認証信任状を介し任意のコンピュータから管理及び関連目的のためにアクセスされる。それにもかかわらず、シミュレーションサーバプラットホーム１０１のいくつかの構成要素（例えばシミュレーションランナー１３３）は、以下に詳細に論述されるようにユーザのシミュレーションタスクに対応する各クラスタ１３１内にインストールされる。

【0090】

図２を参照すると、ダイアグラム２００は、上に論述されたシミュレーションサーバプラットホーム１０１の主要構成要素の動的相互作用の一実施形態を示す。例えば、ユーザがシミュレーションタスクを開始すると、シミュレーションサービス２０３は、「クラスタ立ち上げ」要求（クラスタを定義する計算資源の仕様を含む）によりクラスタサービス２０４を呼び出し、クラスタサービス２０４に１つ又は複数のハードウェア供給者プラットホーム１３０上にクラスタを提供させ、そして（シミュレーションサービス２０３へ提供する）「シミュレーションクラスタＩＤ」を取得させる。このシミュレーションクラスタＩＤは、特定ユーザのシミュレーションタスクに関連付けられた各特定クラスタを一意的に識別するので、クラスタサービス２０４を介したハードウェア供給者プラットホーム１３０との将来の通信を容易にする。このような通信は、クラスタを終了することと、ユーザのシミュレーションタスクが実行中にステータス情報を取得することとを含む。

【0091】

シミュレーションサービス２０３は、当該クラスタに関係する通信を容易にするためにシミュレーション資源マネジャ２１０へ提供する各特定クラスタに関係するクラスタメタデータ（一実施形態では、ホスト名／ユーザ対）を生成する。例えば、計算資源の変更がユーザのシミュレーションタスクに関して是認されたということをシミュレーション資源マネジャ２１０が判断すると、シミュレーション資源マネジャ２１０は、（例えば、所望ハードウェア供給者、特定タイプの仮想サーバの数などを識別する）新しいクラスタに関する関連情報と共に「シミュレーション資源変更要求」をシミュレーションサービス２０３へ提供する。クラスタメタデータはまた、この実施形態では、ハードウェア及びソフトウェア計測のために（再び、ユーザのシミュレーションタスクを一意的に識別するために）利用される。

【0092】

クラスタがクラスタサービス２０４により提供されると、シミュレーションサービス２０３は、シミュレーションランナー２３３を含む関連ソフトウェア及びデータをクラスタ上にインストールし構成する。次に、シミュレーションサービス２０３は、これにより、ユーザのシミュレーションタスクの実行を開始し、そしていくつかの「命令」を実行する（例えば出力ファイルをアップロードする）だけでなく当該タスクが実行中にステータス情報を交換するために通信する。シミュレーションサービス２０３により提供されるインストール及び構成情報は、ユーザのモデル、シミュレーションアプリケーション（例えばいくつかの提供された計算資源に関係するアプリケーション強要制約を含む）を開始するための入力構成パラメータ及びファイル、並びに任意の他の関連入力データ（例えばシミュレーションがその初期状態において開始することよりむしろ実行を「再開」すれば、選択された再開ファイルからの中間シミュレーション状態情報）を含む。

【0093】

シミュレーションサービス２０３が、関連ソフトウェア及びデータをインストールし、次にシミュレーションランナー２３３にシミュレーションの実行を開始するように指示すると、シミュレーションランナー２３３は、以下にさらに詳細に説明されるように、「ＳＩＭ ＡＰＰインスタンス」２３９（すなわち個別ＣＰＵコアにより実行されるシミュレーションアプリケーションの各インスタンス）のそれぞれの実行を開始することによりシミュレーションを開始する。シミュレーションサービス２０３はまた、例えば、クラスタが依然として「生きている」ということを保証するためにクラスタを「ピン（ping）」するために、そしてシミュレーションが終了すると（又は、例えばソフトウェア又はハードウェア故障のおかげで早期の終了が是認されると）クラスタをシャットダウンするためにシミュレーションランナー２３３との定期的通信を維持する。多くのシミュレーションアプリケーションはノード間通信を容易にする標準的「メッセージパッシングインターフェース」（ＭＰＩ：Message Passing Interface）を実装する。一実施形態では、シミュレーションランナー２３３はまた、それ自身の通信のためのＭＰＩを実装する。

【0094】

一実施形態では、シミュレーションタスクの実行を開始すると、シミュレーションアプリケーションのＳＩＭ ＡＰＰインスタンス２３９のそれぞれは、ユーザを認証し、ユーザがシミュレーションアプリケーション又はシミュレーションアプリケーションの特定構成要素特徴から／へ「チェックアウト」／「チェックイン」することを容認するためにライセンスサーバ２１２と通信する。ライセンスサーバ２１２は、そのシミュレーションタスクが認証プロセスを容易にするように、実行しているユーザを一意的に識別するためにホスト名／ユーザ対（上に指摘したようにシミュレーションサービス２０３により生成される）を採用する。別の実施形態では、クラスタ内の「ヘッドノード」内の「マスタ」インスタンス（図５を参照して以下に論述される）が他のノードのために認証機能を実行する。

【0095】

シミュレーションタスクが実行するにつれて、シミュレーションランナー２３３は、以下にさらに詳細に論述されるように、様々なタイプの利用データ（抽出された資源変更指標を含む）を取得し、当該データを解析のためにシミュレーション資源マネジャ２１０へ提供する。加えて、シミュレーションサーバプラットホーム１０１は、図３に以下に示すように、ハードウェア計算資源とソフトウェア計算資源との両方の各シミュレーションタスクによる使用を連続的に計測する。

【0096】

図３のフローチャート３００は、ユーザのシミュレーションタスクに関連付けられた提供クラスタのハードウェア資源が使用される時間（例えば「開始」時間及び「終了」時間に基づく）を監視するためにハードウェア計測モジュール１１４により行われる計測プロセスの一実施形態を示す。このプロセスは、「特定ハードウェア資源の価格」に「監視された利用時間」を掛けることによる「ペイパーユース」ベースでユーザが課金され得るようにする。

【0097】

ハードウェア供給者は通常、複数の仮想サーバのクラスタとは対照的に「仮想サーバ」（又は「仮想マシン」）の粒度のレベルに合わせて働くということに注意すべきである。換言すれば、シミュレーションサーバプラットホーム１０１の観点からは、ユーザのシミュレーションタスクは、複数の仮想サーバ（一実施形態では、さらに複数のハードウェア供給者全体にわたる）を含み得る単一クラスタに関連付けられる。しかし、ハードウェア供給者の観点からは、各仮想サーバは、複数の仮想サーバが単一シミュレーションタスクに関連付けられているということをハードウェア供給者は意識する必要がないので個別「課金可能ジョブ（billable job）」と考えられ得る。さらに、別の実施形態では、シミュレーションタスクは、仮想サーバだけでなくベアメタルサーバの供給者を含む様々なハードウェア供給者全体にわたって同時に実行し得る。

【0098】

様々なシミュレーションタスクを実行する複数ユーザを同時に（場合によっては複数の様々なハードウェア供給者プラットホーム１３０全体にわたって）扱うことに加えて、フローチャート３００に説明されたプロセスはまた、ユーザの個々のシミュレーションタスクへ割り振られたハードウェア資源がシミュレーションタスク実行中に修正される（例えばシミュレーションタスクの実行中の様々な時点で必要に応じより多い又は少ないハードウェア資源を提供するために）シナリオ（以下にさらに詳細に説明される）に対処するということにも注意すべきである。このようなシナリオでは、第１のクラスタ上のミュレーションタスクの実行は第２のクラスタ上で停止及び再開され（恐らく複数回）、これらのクラスタのそれぞれの上（及び各クラスタ内の各仮想サーバ上）のハードウェア資源の使用は、各クラスタ（又は個々の仮想サーバ）に関連付けられた様々な価格で計測され、これによりシミュレーションタスクのユーザに「最適」量のハードウェア資源の価格を請求する。

【0099】

いずれにしても、フローチャート３００内に示されたハードウェア計測プロセスの以下の論述は、個々のシミュレーションタスク及びハードウェア資源（１つ又は複数の仮想マシン及び／又はベアメタルサーバを含む）のその関連クラスタの粒度のレベルで、又はシミュレーションタスクが複数のこのようなサーバに関連付けられその上で実行している（連続的に又は同時に）ということを意識しない各個々の仮想サーバ又はベアメタルサーバ（個別の「開始」時間及び「終了」時間を有する）の粒度のレベルで、ハードウェア供給者がハードウェア資源の利用を監視するかどうかにかかわらず、等しく適用されるということが強調されるべきである。当業者は、どのようにシミュレーションタスクの全ハードウェア料金を生成する（個々の仮想サーバ又はベアメタルサーバのための異なる価格が存在する場合でさえ）ために複数の仮想サーバ又はベアメタルサーバ全体にわたる（又は、さらには複数のハードウェア供給者全体にわたる）個別の「開始」時間及び「終了」時間を合成するかをフローチャート３００から容易に推定し理解し得る。

【0100】

フローチャート３００に示された連続的計測プロセスは、ハードウェア計測モジュール１１４がサーバＤＢ１０５から次の「アクティブ」シミュレーションタスク記録を取り出す工程３１０で開始する。すべての詳細がフローチャート３００に示されるのではないが、シミュレーションタスクに関係するデータベース記録がどのようにハードウェア供給者プラットホーム１３０とシミュレーションサーバプラットホーム１０１との両方により生成され維持されるかを理解することが有用である。

【0101】

シミュレーションサーバプラットホーム１０１がハードウェア供給者プラットホーム１３０からクラスタ（個々のシミュレーションタスクに関連付けられた）を提供すると、ハードウェア供給者プラットホーム１３０は、クラスタサービス１０４内のハードウェア供給者アダプタ１０４ｂにより採用されるものなどのＡＰＩを介しアクセス可能である「ハードウェア供給者」データベース記録を維持する。この記録は通常、関連メトリックと共に、提供されたシミュレーションタスクの識別子（すなわち「クラスタＩＤ」、又は上に指摘したように個別「仮想サーバ」ＩＤ）を含み、シミュレーションタスク（様々なハードウェア供給者間で変わる）により又はそれに関して行われる様々な活動の時間スタンプを含む。このＩＤは通常、どの特定プロセスがクラスタ上（又は個別仮想サーバ又はベアメタルサーバ上で）で実行中かを示す。シミュレーションタスクの実行が全体として停止する（シミュレーションの正常完了により、又はハードウェア又はソフトウェア故障により）と、記録はもはやハードウェア供給者のデータベース内で「アクティブ」として示されない。

【0102】

シミュレーションサーバプラットホーム１０１は同様な対応するデータベース記録をサーバＤＢ１０５内に維持する。フローチャート３００に関する以下の論述から明らかになるように、ハードウェア計測モジュール１１４は、その計測機能を実行し、シミュレーションタスク記録をサーバＤＢ１０５内に維持するために、ハードウェア供給者プラットホーム１３０により維持される情報に依存する。サーバＤＢ１０５内に維持されるシミュレーションタスクＩＤは１つ又は複数のハードウェア供給者プラットホーム１３０全体にわたる複数の異なるベアメタルサーバ又は仮想サーバに関連付けられ得るということにも注意すべきである（上に暗示されるように）。

【0103】

フローチャート３００へ戻ると、サーバＤＢ１０５におけるデータベース記録（工程３１０において取り出された）内のシミュレーションタスクＩＤは、シミュレーションタスクに関連付けられた関連ハードウェア供給者を識別する（サーバ又は個々のベアメタルサーバ又は仮想サーバのクラスタの粒度のレベルかにかかわらず）。ハードウェア計測モジュール１１４は、この情報を工程３１２において利用して、当該シミュレーションタスクに関連付けられた整合するアクティブ「ハードウェア供給者」記録について関連ハードウェア供給者のＡＰＩに（ハードウェア供給者アダプタ１０４ｂを介し）照会する。

【0104】

工程３１５において、照会に対する応答がこのようなアクティブハードウェア供給者記録の存在を示せば、ハードウェア計測モジュール１１４は、工程３２０において、当該ハードウェア供給者記録から抽出された開始時間スタンプによりシミュレーションタスクデータベース記録（サーバＤＢ１０５からの）を更新する。ハードウェア供給者がクラスタ提供要求を受信し、当該クラスタを実際に提供し、そして「ハードウェア供給者」記録を生成した時から若干の時間が経過するということに注意すべきである。この実施形態では、ハードウェア供給者記録の存在は、正確な開始時間スタンプの存在を示す。これは、終了時間スタンプが判断される（以下に論述されるように）とハードワイヤ供給者がその「顧客」（すなわち、シミュレーションサーバプラットホーム１０１）に課金するために使用する時間スタンプであるからである。

【0105】

次に、工程３２２では、ハードウェア計測モジュール１１４は、現在時刻に基づき一時的終了時間スタンプによりシミュレーションタスクデータベース記録を更新する。換言すれば、シミュレーションタスクは、ハードウェア供給者の観点からは依然として「アクティブ」であるので、未だ終了していない。しかし、以下に論述されるように、この一時的終了時間スタンプは、実際の終了時間スタンプが推測され得る有用データとして働き得る（例えばハードウェア又はソフトウェア故障に起因するシミュレーションタスクの異常終了の場合）。

【0106】

次に、工程３３０では、ハードウェア計測モジュール１１４は、この更新されたシミュレーションタスクデータベース記録をサーバＤＢ１０５へ保存し、工程３７０において、一時的な「現在の」ハードウェア料金（すなわち、提供されたハードウェア資源に対するハードウェア供給者の価格を掛けた開始時間スタンプ及び一時的終了時間スタンプに基づく利用時間）を計算する。最終的に、シミュレーションタスクは終了され（正常に又は異常に）、アクティブハードウェア供給者記録は工程３１２における照会によりもはや見つからない。

【0107】

したがって、工程３１５において、このようなアクティブハードウェア供給者記録が存在しない（このような記録がかつて見出されたことがあるかどうかにかかわらず）ということを工程３１２における照会に対する応答が示し、ハードウェア供給者がシミュレーションタスクに関係するアクティブ記録を有しなければ（工程３１５において）、ハードウェア計測モジュール１１４は工程３２５においてサーバＤＢ１０５内の開始時間スタンプを探索する。開始時間スタンプが見つかられなければ（すなわち、シミュレーションが非常に速く完了したこと、又はシミュレーションが異常に故障した可能性が高いということのいずれかを示す）、ハードウェア計測モジュール１１４は、工程３３８において、そのデータベース記録を更新するためにフォールバックとしてその「内部」開始時間スタンプを使用する。換言すれば、ハードウェア計測モジュール１１４は、クラスタサービス１０４がクラスタの提供を要求した時間を使用する（開始時間スタンプはハードウェア供給者から利用可能ではないので）。

【0108】

工程３２５の結果にかかわらず、ハードウェア計測モジュール１１４は今や、開始時間スタンプにより更新されたデータベース記録を有し、シミュレーションが終了したということを知るが、終了時間スタンプを未だ有しない。したがって、工程３４０において、ハードウェア計測モジュール１１４は、関連ハードウェア供給者ＡＰＩにシミュレーションタスクに関する過去のメトリックを照会する（再びハードウェア供給者アダプタ１０４ｂを介し）。換言すれば、アクティブハードウェア供給者記録が存在しない間、過去のメトリックが依然としてハードウェア供給者により維持される。

【0109】

これらのメトリックは終了時間スタンプを推測するために工程３４２において利用される。例えば、これらのメトリックは、シミュレーションタスクがハードウェア又はソフトウェア故障により異常に終了された時間スタンプを提供し得る。代替的に、これらのメトリックは、正常終了を示し、実際の終了時間スタンプを提供し得る。他のケースでは、これらのメトリックは実際の終了時間スタンプを提供しなくてもよいが、終了時間スタンプが推測され得る活動の証拠を提供し得る。

【0110】

シミュレーションサーバ１０１はまた、シミュレーションタスクの正常又は異常終了の証拠をそれ自身の監視プロセスを介し検出し得る（以下に詳細に説明するように）。一実施形態では、実際の「終了」時間がこの利用可能「証拠」から抽出され得なければ、推測される「終了」時間として最新活動の時間スタンプが利用される。別の実施形態では、いつシミュレーションタスクが終了したか（すなわち、いつポーリング事象にもはや応答しなくなったか）を判断するために（活動の「鼓動」の、又はＣＰＵ利用などの特定ハードウェアメトリックの）定期的ポーリングが採用される。

【0111】

いずれにしても、ハードウェア計測モジュール１１４は今や、開始時間スタンプと終了時間スタンプとの両方を有する更新されたシミュレーションタスクデータベース記録を有し、工程３６０において、この最新記録をサーバＤＢ１０５へ保存する。次に、ハードウェア計測モジュール１１４は、工程３７０へ進み、上述したようにハードウェア料金を計算する（以前に計算されたいかなる一時的ハードウェア料金も更新する）。フローチャート３００に示さないが、この「最終」ハードウェア料金計算の結果は課金目的のために利用される（一実施形態では、同じシミュレーションタスクに関連付けられた恐らく複数のハードウェア供給者全体にわたって他のベアメタルサーバ又は仮想サーバのために計算された同様な料金と組み合わせることにより）。一実施形態では、（組織内の複数ユーザだけでなく）複数のシミュレーションタスク全体にわたるハードウェア料金が組み合わされて組織及びその個々のユーザのそれぞれのハードウェア料金を月一回生成する。

【0112】

工程３７５において、ハードウェア計測モジュール１１４は、監視すべき他のアクティブシミュレーションタスクを求めてサーバＤＢ１０５を連続的に（又は別の実施形態で、定期的には）探索する。別のアクティブシミュレーションタスクが見つかると、ハードウェア計測モジュール１１４はその関連アクティブシミュレーションタスクデータベース記録を取り出すために工程３１０へ戻り、この連続的ハードウェア計測プロセスを反復する。

【0113】

図４に移ると、フローチャート４００は、ユーザのシミュレーションタスクに関連付けられた提供されたクラスタのソフトウェア資源が使用される時間を監視するためにソフトウェア計測モジュール１１３により行われる計測プロセスの一実施形態を示す。図３に関して上に説明したハードウェア計測プロセス（ハードウェア資源の利用に関する「開始」時間及び「終了」時間を監視する）とは対照的に、フローチャート４００は、ソフトウェア資源（すなわちシミュレーションアプリケーション（そして、一実施形態では、その特定構成要素特徴））の利用に関する「チェックアウト」及び「チェックイン」事象を監視する。

【0114】

換言すれば、ソフトウェア計測は、クラスタのハードウェア資源が提供されなくても、そしてさらにはシミュレーションタスクが必ずしも開始されなくても、しかし特定シミュレーションアプリケーション（又はそのアプリケーションの特定構成要素特徴）のユーザが認証され、そしてアプリケーション又は構成要素特徴が立ち上げられると、開始する。このチェックアウト事象はソフトウェア計測プロセスの開始をマーキングするが、その後のチェックイン事象は、特定シミュレーションアプリケーション又は構成要素特徴の利用に関するプロセスの終了をマーキングする。

【0115】

上に論述したように、シミュレーションアプリケーションは、ユーザのアクセスを許容する前にユーザを認証するためにライセンスサーバ１１２を採用する。ユーザがシミュレーションアプリケーション又は構成要素特徴へアクセスしようとする（例えばシミュレーションタスク又は当該タスクの中間部を開始するために）と、シミュレーションアプリケーションは、ユーザを認証してこのようなアクセスを容認又は拒絶のいずれかを行うその関連ライセンスサーバ１１２と通信する。認証に続いて、シミュレーションアプリケーション又は特徴が立ち上げられると、ライセンスサーバ１１２はチェックアウト事象を生成し、その後最終的にシミュレーションアプリケーション又は特徴がもはや使用中でなくなるとチェックイン事象を生成する。

【0116】

ライセンスサーバ１１２は、契約目的、課金目的又は他の目的のために事象の記録を維持するためにこれらのチェックアウト及びチェックイン事象を「ライセンスログファイル」内に文書化する。これらのログ記録された事象は通常、シミュレーションアプリケーション及びユーザを識別する情報と、いつ事象が発生したかを示す「時間スタンプ」とを含む。いくつかのケースでは、時間スタンプは、事象の日付けと時間との両方を識別するが、他のケースでは、時間だけが含まれ、そして、以前及びその後の時間スタンプの日付けが推測され得る個別「日付けスタンプ」事象が生成される（例えば各暦日の始まり又は終わりに）。

【0117】

ソフトウェア計測モジュール１１３は、ライセンスログファイルからチェックアウト及びチェックイン時間スタンプを抽出することによりシミュレーションアプリケーションの使用を監視し得るように、ライセンスサーバ１１２との通信を管理するためにライセンスサービス１１３ａを含む。工程４１０で開始すると、ソフトウェア計測モジュール１１３のライセンスサービス１１３ａは、シミュレーションプラットホーム１０１によりインストールされたシミュレーションアプリケーションのユーザを認証する責任を負う様々なライセンスサーバ１１２のそれぞれとの接続を確立する。

【0118】

一実施形態では、工程４１０において、ソフトウェア計測モジュール１１３は、新エントリのライセンスサーバ１１２を定期的にポーリングする。この実施形態では、ソフトウェア計測モジュール１１３は、ライセンスログファイルにアクセスする（ライセンスサービス１１３ａにより確立された接続を介し）が、最後にチェックしてから新エントリ（例えばライセンスログファイルの終わりにおける新ライン）が実際に追加されたかどうかを工程４１５において判断しなければならない。別の実施形態では、新エントリを検出してソフトウェア計測モジュール１１３に通知するために割り込み機構が採用されるが、このような機構は様々なライセンスサーバ１１２（いくつかのケースでは、様々なハードウェア供給者プラットホーム１３０により提供される）とのより広汎な一体化を必要とする。

【0119】

一実施形態では、工程４１５は、新エントリが検出されるまで、すべての接続されたライセンスサーバ１１２により生成されるライセンスログファイル全体にわたって反復されるソフトウェア計測モジュール１１３により行われる連続プロセスである。ライセンスログファイルのうちの１つのライセンスログファイル内に新エントリを検出すると、ソフトウェア計測モジュール１１３はフローチャート４００（工程４２０で開始する）の残りの工程において当該エントリを処理し、その後工程４１５において新エントリの探索を再開する。

【0120】

別のプロセス（フローチャート４００に図示せず）では、ソフトウェア計測モジュール１１３は、各チェックアウト記録（特定ユーザのシミュレーションタスク又は構成要素特徴に関連付けられた対応するチェックアウト事象とチェックイン事象との「整合対」を含む）に関連付けられた使用時間（すなわちチェックアウト事象時間とチェックイン事象時間との差）を判断するために各チェックアウト記録を解析する。次に、ソフトウェア計測モジュール１１３は、これらの使用時間（シミュレーションタスク、ユーザ、ユーザの組織、及びシミュレーションアプリケーション全体にわたる）を積算し、課金目的のためにソフトウェア計測料金を計算するために当該関連価格構造を適用する。この結果、シミュレーションサーバプラットホーム１０１は、シミュレーションサーバプラットホーム１０１のユーザによるソフトウェア資源の使用を詳述する定期的（例えば月一回）料金及び使用報告書（シミュレーションアプリケーションのユーザ、組織及びライセンスの）を生成し得る。

【0121】

一実施形態（これもまたフローチャート４００に図示せず）では、整合するチェックイン事象がライセンスログファイル内で生成及び記録されていなければ（例えば、シミュレーションアプリケーションが、そのライセンスサーバ１１２に知らされることなく異常に終了したならば）、ソフトウェア計測モジュール１１３は人工的チェックイン事象を生成し、その日時を他の被監視情報から推測する。このような情報は、図５を参照し以下に詳細に論述されるように、クラスタが実行されているハードウェア供給者プラットホーム１３０からの通知とクラスタ自体内から識別される情報と含み得る。

【0122】

フローチャート４００へ戻ると、ソフトウェア計測モジュール１１３が、ライセンスログファイルのうちの１つのライセンスログファイル内に新エントリを工程４１５において検出すると、そのタイプを判断し得るように工程４２０において当該新エントリを解析する。ソフトウェア計測モジュール１１３は新エントリがチェックアウト事象かどうかを工程４２５において判断する。そうでなければ、次に、ソフトウェア計測モジュール１１３は新エントリがチェックイン事象かどうかを工程４３５において判断する。そうでなければ、ソフトウェア計測モジュール１１３は新エントリが日付けスタンプエントリかどうかを工程４４５において判断する。そうでなければ、ソフトウェア計測モジュール１１３は、工程４９２において、新エントリはしたがってソフトウェア計測モジュール１１３が無視し得る「未知ログエントリ」であるという結論を下す（そして、次に、工程４１５において新エントリの探索を再開する）。他の実施形態では、ライセンスサーバ１１２は、本発明の精神から逸脱することなく同様なやり方で処理され得る追加タイプの事象を生成し得る。

【0123】

新エントリがチェックアウト事象であるということが工程４２５において判断されれば、ソフトウェア計測モジュール１１３は工程４５０においてチェックアウト「日時」エントリを生成し、次に、工程４６０において、チェックアウト日時エントリと「オープン」チェックインエントリとを含む新しいチェックアウト記録を生成する（シミュレーションアプリケーション又は構成要素特徴が未だ「再チェックイン」されていないので）。次に、ソフトウェア計測モジュール１１３はこの新しいチェックアウト記録をサーバＤＢ１０５内に保存する。換言すれば、ソフトウェア計測モジュール１１３は、チェックアウト事象の日時と、同事象を対応シミュレーションアプリケーション及びユーザのシミュレーションタスクに関連付ける関連情報とを保存する。上に指摘したように、日付けが含まれていなければ、ソフトウェア計測モジュール１１３はライセンスログファイル内の最新日付けスタンプエントリから日付けを推測し得る。

【0124】

以下に論述されるように、この情報は後で、当該シミュレーションタスクにより全体使用率を判断するためにこの事象とその将来対応チェックイン事象とを整合するためにソフトウェア計測モジュール１１３により採用され、次に、この情報から、ソフトウェア計測モジュール１１３は上に指摘したようにソフトウェア計測料金を計算する。しかし、このチェックアウト事象の処理を終了したこの時点で、ソフトウェア計測モジュール１１３は工程４１５へ戻り、新エントリを求めてライセンスログファイルを探索することを再開する。

【0125】

他方で、新エントリが工程４３５においてチェックイン事象であると判断されれば、ソフトウェア計測モジュール１１３は工程４７０においてチェックイン「日時」エントリを生成する。ソフトウェア計測モジュール１１３は、以前の対応チェックアウトエントリが存在しなければならないということを知っているので、次に、工程４６０において生成され再保存された対応チェックアウト記録を求めてサーバＤＢ１０５を工程４８０において探索する（チェックアウト事象と対応シミュレーションアプリケーション及びユーザのシミュレーションタスクとを関連付ける上に論述された関連情報を利用して）。次に、ソフトウェア計測モジュール１１３は、チェックイン日時エントリによりこのチェックアウト記録を更新し、更新されたチェックアウト記録をサーバＤＢ１０５内に保存する。チェックアウト事象と同様に、ソフトウェア計測モジュール１１３は、ライセンスログファイル内の最新日付けスタンプエントリからこのチェックイン事象の日付けを推測し得る（新エントリ内に含まれなければ）。

【0126】

次に、ソフトウェア計測モジュール１１３は、いくつかのライセンスサーバ１１２がライセンスログファイルへ追加した各チェックイン及びチェックアウトエントリを有する時間だけ（しかし日付けがない）を含むという事実（上記）により、工程４９０において、チェックイン記録とチェックアウト記録との整合を容易にするために現在日付けをサーバＤＢ１０５へ保存する。新エントリが日付けスタンプエントリであるということが工程４４５において判断されれば、ソフトウェア計測モジュール１１３は、工程４９０において、当該日付けスタンプエントリから現在日付けをサーバＤＢ１０５内に保存する。いずれの場合も、この「現在日付け」情報は、工程４８０において、対応する整合チェックアウト記録の探索を容易にする（すなわち日付けが各チェックアウトエントリに関連付けられるということを保証する）。次に、ソフトウェア計測モジュール１１３は工程４１５へ戻り、新エントリを求めてライセンスログファイルを探索することを再開する。

【0127】

上に指摘したように、フローチャート４００に示されたこのソフトウェア計測プロセスは、シミュレーションアプリケーション及びそのシミュレーションアプリケーションの個々の構成要素特徴のチェックアウト事象とチェックイン事象とをほぼ整合し、これによりシミュレーションアプリケーションの所有者により特徴毎ベースで採用された様々な認証及び価格決定メカニズムを調整する。

【0128】

図５に移ると、ブロックダイヤグラム５００は、クラスタサービス１０４によりハードウェア供給者プラットホーム１３０上に提供された後のクラスタの主要構成要素の一実施形態を示す。上に指摘したように、シミュレーションサービス１０３は、シミュレーションアプリケーションのインスタンスを含むいくつかの構成要素をインストール及び構成することによりクラスタを構成する。これらの構成要素は、ユーザのシミュレーションタスクに関連付けられた各クラスタ内に常駐するにもかかわらず、概念的に、シミュレーションサーバプラットホーム１０１の機能の一部であるということに注意すべきである。様々なハードウェア及びソフトウェア構成要素間のこの機能の割り振りは、本発明の精神から逸脱することなく修正され得る工学と設計とのトレードオフの結果である。

【0129】

どのようにシミュレーション資源マネジャ１１０が計算資源の使用を監視し、計算資源の使用が是認されるとこれらを修正するプロセスを管理するか（以下の図６と図７を参照してさらに詳細に説明される）をより良く理解するために、どのようにこれらの主要機能構成要素が、実行中のシミュレーションと相互作用し、各クラスタ５３１とシミュレーションサーバプラットホーム１０１との間の通信を容易にするかを理解することが有用である。

【0130】

一実施形態では、シミュレーションタスク毎に、クラスタサービス１０４は、シミュレーションアプリケーションの各残りのインスタンスの追加ノード（ノードＨ１ ５３１_Ｈ１、ノードＨ２ ５３１_Ｈ２、．．．、ノードＨｎ ５３１_Ｈｎ）と共に、単一「ヘッドノードＨ」５３１_Ｈ（シミュレーションアプリケーションのインスタンス５３９_Ｈを含む）を含むクラスタ５３１を提供し構成する。この実施形態では、クラスタサービス１０４によりインストールされたシミュレーションアプリケーションの各インスタンス（５３９_Ｈ、５３９_Ｈ１、．．．、５３９_Ｈｎ）は個別ＣＰＵコアにより実行される。ＣＰＵコアは、単一の物理的又は仮想的サーバ内の１つ又は複数のＣＰＵ上に存在してもよいし、複数のＣＰＵ、物理的仮想サーバ、及び仮想サーバ全体にわたって散在してもよい。別の実施形態では、各ノードは、ハードウェア供給者プラットホーム１３０から提供される仮想サーバに対応し、したがって２つ以上のＣＰＵコアを含み得、したがって、シミュレーションアプリケーションの２つ以上のインスタンスを実行し得る。

【0131】

各ノード（ヘッドノードＨ ５３１_Ｈを含む）はまた、以下に説明するように、シミュレーションアプリケーションのその対応するインスタンスにより計算資源の使用を動的に監視するハードウェア監視器（５３８_Ｈ、５３８_Ｈ１、．．．、５３８_Ｈｎ）を含む。ヘッドノードＨ ５３１_Ｈはまた、シミュレーションタスク全体の管理に関係する追加構成要素（一実施形態では、シミュレーションランナー５３３、出力ファイルパーサ５３４、再開ファイル監視器５３６、及びクラスタＤＢ５３５）を含む。このような構成要素の機能はクラスタ５３１のノードのすべての間で効果的に共有される。

【0132】

上に指摘したように（そして、図６と図７を参照して以下にさらに詳細に説明されるように）、シミュレーション資源マネジャ１１０は、その提供されたクラスタ上で実行し、様々な資源変更指標（ユーザのシミュレーションタスクに関係するアプリケーション固有情報だけでなく計算資源利用情報も含む）を探索する間に各ユーザのシミュレーションタスクの実行を連続的に監視する。一実施形態では、各ノード内のハードウェア監視器（５３８_Ｈ、５３８_Ｈ１、．．．、５３８_Ｈｎ）は、クラスタ５３１内の各ＣＰＵコアによるパーセントＣＰＵ利用率などの計算資源利用情報を取得する責任を負う。

【0133】

ある計算資源利用情報はハードウェアプラットホーム供給者１３０により提供される標準サービスを介し取得され得るが、ハードウェア監視器（５３８_Ｈ、５３８_Ｈ１、．．．、５３８_Ｈｎ）はまた、一実施形態では、この情報を、クラスタ５３１が常駐するハードウェアプラットホーム供給者１３０から入手可能でない追加情報（自由ＲＡＭの量、全体ネットワーク帯域幅利用率など）により補完する。ハードウェア監視器（５３８_Ｈ、５３８_Ｈ１、．．．、５３８_Ｈｎ）により取得される計算資源利用情報（ハードウェアプラットホーム供給者１３０により提供されるサービスを介し間接的に取得される情報を含む）はクラスタＤＢ５３５内に格納され、維持され、最終的にシミュレーション資源マネジャ１１０により利用される（図６と図７を参照して以下にさらに詳細に説明されるように）。一実施形態では、クラスタＤＢ５３５内に格納されたデータは、クラスタＤＢ５３５へのさらなるアクセスを妨げるクラスタ５３１内のハードウェア又はソフトウェア故障の場合に使用するためにサーバＤＢ１０５と定期的に同期される。

【0134】

上に指摘したように、シミュレーションランナー５３３は、ユーザのシミュレーションタスクの全体動作を管理し、一実施形態では、シミュレーションサービス１０３を介しシミュレーションサーバプラットホーム１０１と通信する。シミュレーションアプリケーションのインスタンス（５３９_Ｈ、５３９_Ｈ１、．．．、５３９_Ｈｎ）のそれぞれの実行を開始し、シミュレーションが終了した（又は異常に終了された）場合にクラスタをシャットダウンすることに加えて、シミュレーションランナー５３３はまた、様々な資源変更指標を取得する動的プロセスを管理する（例えば計算資源利用情報を取得するプロセスを管理するためにハードウェア監視器（５３８_Ｈ、５３８_Ｈ１、．．．、５３８_Ｈｎ）と通信することにより）。

【0135】

シミュレーションランナー５３３はまた、ユーザのシミュレーションタスク全体に（すなわちシミュレーションアプリケーションの複数のインスタンス全体にわたって）関係するアプリケーション固有情報の抽出を管理する。上に指摘したように、シミュレーションアプリケーションは様々なタイプのステータス情報を生成し出力ファイルへ書き込む。図５に示す実施形態では、シミュレーションアプリケーションはこれらの出力ファイルをヘッドノードＨ ５３１_Ｈ内のクラスタＤＢ５３５へ書き込むように構成される。図６と図７に関して以下でさらに詳細に説明されるように、出力ファイルパーサ５３４は、計算資源の変更が是認されたかどうかをシミュレーション資源マネジャ１１０が推論し得る情報（例えば、その潜在的将来計算資源要件の指標を含むシミュレーションアプリケーションの計算資源の使用の効率に関係する情報）を抽出するためにこれらの出力ファイルを解析する。

【0136】

シミュレーションアプリケーションはまた（上に指摘したように）時折、この実施形態ではクラスタＤＢ５３５へも書き込まれる再開ファイルを生成し書き込む。再開ファイルは、シミュレーションアプリケーションが再開され得る現在の中間シミュレーション状態を含む。上に指摘したように、シミュレーションアプリケーションは通常、シミュレーションアプリケーションが実行されることになるＣＰＵコアの数を示す事前構成情報（すなわちＣＰＵコア当たり１つのインスタンス）を必要とする。例えば、シミュレーションアプリケーションの８つのインスタンスは当初８つのＣＰＵコア上で実行し得る。しかし、再開ファイル内で識別された中間シミュレーション状態から再開されると、シミュレーションアプリケーションは、より少ない又は多いＣＰＵコア用に構成され得る。

【0137】

一実施形態では、再開ファイル監視器５３６は、シミュレーションアプリケーションにより時折書き込まれる再開ファイルを監視し解析し、計算資源の変更が是認されたかどうかのその判断においてシミュレーション資源マネジャ１１０により利用される情報を提供する。このような情報は、再開ファイルが書き込まれた時間などのより一般的情報だけでなく特定変数が捕捉された「スナップショット」状態を含み得る。例えば、他の資源変更指標が、計算資源の変更が是認されたということを他の方法で示唆する可能性があるが、十分に最新の再開ファイルの欠如がこのような判断に対して情勢を変化させ得る。

【0138】

図６に移ると、ブロックダイヤグラム６００は、シミュレーションタスクへ現在提供されている計算資源を修正すべきかどうか、いつ修正するか、そしてどの程度修正するかをユーザのシミュレーションタスクが実行中に動的に判断するシミュレーション資源マネジャ１１０の主要構成要素の一実施形態を示す。シミュレーション監視サービス６１５は、現在実行中のシミュレーションタスクに関連付けられた各クラスタ５３１内のシミュレーションランナー５３３との通信を管理する。

【0139】

上に指摘したように、シミュレーションランナー５３３からシミュレーション監視サービス６１５により取得される情報は、ＣＰＵコアのパーセント利用率、各物理的又は仮想的サーバ上の利用可能メモリ及びディスクスペース、ディスク読み取り／書き込み情報（例えば、所定期間内に特定記憶装置から読み取られる及びそれへ書き込まれるバイト数）、及びネットワーク帯域幅利用率（例えば仮想サーバ全体にわたって転送されるバイト数）に関係する計算資源利用情報を含む資源変更指標を含む。過去の計算資源利用情報もまた、シミュレーションタスクが実行中の時間にわたってクラスタＤＢ５３５内に維持され、このような利用の効率に関するシミュレーション資源マネジャ６１０による推論を可能にする。

【0140】

シミュレーション監視サービス６１５はまた、ユーザのシミュレーションタスクに関係するアプリケーション固有情報（別のタイプの資源変更指標）を取得する（シミュレーションランナー５３３から）。上に指摘したように、このような情報は、シミュレーションアプリケーションにより生成される出力ファイルから抽出され、例えばシミュレーションアプリケーションがユーザのシミュレーションモデルに関して処理しているセルの現在数への直接及び間接的参照子を含む。

【0141】

例えば、シミュレーションが進むにつれ、シミュレーションアプリケーションは、モデルの一部分又はすべての部分内のセルの数を組み合わせる又は分割し、シミュレーション監視サービス６１５が、処理されているセルの現在数を推測することを可能にし、そして他の実施形態では、将来処理されるセルの数を予測することを可能にし得る。他のケースでは、セルの数は、それらの長さ（例えば２ｍｍ）又は体積（例えば１立方メートル）などのセル特性から推定され得る。コア当たりセルの所定標的数を所与として、シミュレーション監視サービス６１５は、他の計算資源の標的に影響を与え得るＣＰＵコアの新しい標的数を推測する（例えば、比較的多い５１２個のＣＰＵコアは、１０Ｇイーサーネット又は利用可能であれば恐らく４０Ｇ ＩｎｆｉｎｉＢａｎｄなどのより高いネットワーク帯域幅から恩恵を受け得る）。

【0142】

上に指摘したように、ユーザのシミュレーションデータモデルのセルは、モデル化されるシステムとユーザのシミュレーションデータモデルに対してシミュレーションアプリケーションにより行われる機能とに依存して時間の経過と共に変更を受ける様々な特性（例えば長さ、体積、密度、温度、圧力など）を有する。例えば、「計算流体力学」（ＣＦＤ：computational fluid dynamics）シミュレーションでは、シミュレーションアプリケーションは、離陸時に（又は所与の高度における飛行中に、又は着陸のための下降中に）空気中を進むことに伴う翼への乱流の影響をシミュレーションするために飛行機翼のユーザのモデルに関する計算を行い得る。この例では、飛行機翼のセルは、体積、温度、圧力などのいくつかの初期特性を有し得る。しかし、翼が空気中を進み、空気分子（類似特性を有するセルとしても表される）に遭遇すると、翼上のいくつかのセルの特性は、例えば標準的乱流及び関連式に基づき変化し得る。これらの計算の結果として、例えば、圧力（これら及び他の隣接セルの特性の変化を生じ得る）が、シミュレーションが進むにつれて翼のいくつかのセル上などで増加し得る。

【0143】

時間の経過に伴うこれらの計算の無数の反復にわたって、セル特性の変化は、継続し、そして出力ファイルへ時折書き込まれるステータス情報に反映される。様々なシミュレーションアプリケーションが様々なタイプの情報を出力ファイルへ書き込むということにも注意すべきである。例えば、いくつかのシミュレーションアプリケーションは、セルとＣＰＵコアとを相関付け、セルの数が所定量又はパーセントだけ増加又は低減するとデータを出力ファイルへ書き込む。他のシミュレーションアプリケーションは、必要とされる量のＲＡＭをユーザのシミュレーションデータモデルの仕様に基づき判断し、シミュレーションが実行中の様々な時間に必要とされるＲＡＭの最小及び最大効率量を出力ファイルへ書き込む。さらに他のシミュレーションアプリケーションは、ディスクへ書き込まれるデータの量及び頻度を示す出力ファイルへ書き込まれた情報に基づくＲＡＭ要件に関する推論を必要とする。

【0144】

シミュレーション監視サービス６１５はこれらの様々なタイプのアプリケーション固有情報（出力ファイルから抽出された後にシミュレーションランナー５３３から取得された）を監視し、シミュレーションアプリケーションによる計算資源の使用に関する（例えばセルの現在数、自由ＲＡＭの現在量などに関係する）推論を行い、最適計算資源評価エンジン６２０による評価のためにこのデータを編成しフォーマット化する。シミュレーション監視サービス６１５はまた、シミュレーションアプリケーションにより時間の経過と共に生成された再開ファイル（特に計算資源の変更が是認されたときのその解析を容易にするために最適計算資源評価エンジン６２０へ提供する）をシミュレーションランナー５３３から取得する。

【0145】

一実施形態では、最適計算資源評価エンジン６２０は、シミュレーション監視サービス６１５からのこのデータを評価するための一組の「トリガー評価器」を含み、計算資源の変更が是認されたかどうかを判断する。計算資源利用データ（すなわち、各計算資源（ＣＰＵ、ＲＡＭ、記憶装置、ネットワーク帯域幅など）の現在の利用率と過去の利用率）を評価するためにハードウェアレベルトリガー評価器６２３が採用される。

【0146】

ユーザのシミュレーションタスクに関係するアプリケーション固有データ（例えばシミュレーションアプリケーションにより生成された出力ファイルからシミュレーションランナー５３３により抽出される）を評価するためにシミュレーションレベルトリガー評価器６２１が採用される。一実施形態では、計算資源毎に個々のトリガーが採用される。セルの数に関係する情報が、ＣＰＵコアの数の増加又は低減をトリガーし得る。時間の経過に伴う「コア」間通信の増加を証拠付ける情報が、ＣＰＵコアの数の減少と恐らくＲＡＭの量の増加とをトリガーし得る。

【0147】

アプリケーション固有情報はまた、シミュレーションの多少ＣＰＵ集約的な局面への遷移を証拠付け得、これによりＣＰＵコアの数の増加又は低減をトリガーする。例えば、シミュレーションアプリケーションの特定タイプの構成要素（例えば特定のタイプの計算の「ソルバ」）への遷移はしばしば、シミュレーションのそれほどＣＰＵ集約的でない「局面」を示す。さらに、シミュレーションが一連の又は階層的繰り返し「反復工程」（例えば一定期間にわたる反復シミュレーション、平衡状態方向に収束するセル圧力などの特殊解方向への数学的収束、又は他の同様な繰り返される反復）うちの１つを完了したという証拠は、計算資源の過去の利用がその後の「反復工程」のために繰り返される可能性があるということを示し得る。このようなシナリオでは、１つ又は複数の反復工程中の現在の提供計算資源の使用の過去の証拠は、将来の反復工程中のこのような使用に関する推論を提供、且つ容易にし、したがって（一実施形態では）計算資源の変更が是認されたかどうかの判断に関するより大きなウェイトを担う。

【0148】

一実施形態では、シミュレーションレベルトリガー評価器６２１とハードウェアレベルトリガー評価器６２３は合成され、より複雑な機能又は規則を可能にする。例えば、ＣＰＵコアの増加のトリガーは、セルの数とＣＰＵ利用率との両方の閾値増加を要する可能性がある。

【0149】

最後に、ユーザレベルトリガー評価器６２２が、一実施形態では、計算資源の割り振りに関するユーザの所定全体ゴール（一実施形態では任意選択的な）に照らした最適計算資源評価エンジン６２０による判断を容易にするために、採用される。例えば、１人のユーザは、最小費用のために最適化することを選択し得、一方、別のユーザは最小全体シミュレーション時間のために最適化することを選択し得る。別の実施形態では、ユーザは、所定閾値を有する機能と、最適計算資源評価エンジン６２０の規則ベース実施形態により利用される規則又は他の発見的方法を有する機能とを含むトリガーを提供し得る。

【0150】

一実施形態では、最適計算資源評価エンジン６２０は、シミュレーションアプリケーションの振る舞いの予測モデルを所与の組の提供された計算資源上に含む学習エンジン（その構成要素トリガー評価器間に分散された）を採用する。例えば、１つのこのような予測モデルは、シミュレーションの過程中の時間の経過と共にユーザのシミュレーションデータモデル内に存在するセルの数を予測する（出力ファイルから抽出されるアプリケーション固有データに基づき）。この予測モデルはシミュレーションが進むにつれて連続的に精緻化され、新情報がシミュレーション監視サービス６１５により取得される。予測セルの数が所定閾値を越えると、シミュレーションレベルトリガー評価器６２１は、ＣＰＵコアの現在数の増加のための推奨を「トリガー」する。

【0151】

例えばＣＰＵコア（又はＲＡＭ、記憶装置、ネットワーク帯域幅又は他の計算資源）のパーセント利用率が所定閾値を越えると、他のトリガーが例えばハードウェアレベルトリガー評価器６２３により生成される。これらのトリガーは一実施形態では１つ又は複数の計算資源の変更が是認されたかどうかに関する単一判断を生成するために合成される。例えば、一実施形態では、所定機能が、様々なトリガーを組み合わせて所定重み付けを各トリガーへ適用するために採用される。この実施形態では、ユーザレベルトリガー評価器６２２は、所定ユーザゴールを考慮することによりこれらの機能内のトリガーの重み付けを修正するために採用される。例えば、最小全体シミュレーション時間を最適化するユーザゴールは、ＣＰＵコア増加のトリガーを、全体費用を最適化するユーザゴールより高く重み付けし得る（追加のその結果の費用にもかかわらず）。

【0152】

他の実施形態では、学習エンジンの代わりに、最適計算資源評価エンジン６２０は、シミュレーションタスクにより計算資源の将来利用を予測しない所定規則（例えば知識ベースエキスパートシステムにより採用される）であるがその代りにシミュレーション監視サービス６１５により監視される現在データと時間の経過と共に監視された過去の傾向とだけに基づくトリガーを生成する所定規則を含む。例えば、この実施形態において採用される１つのこのような規則又は発見的方法は、ＣＰＵ利用率のパーセントが所定閾値を越えるとＣＰＵコアの増加をトリガーし、セルの数は、さらに別の閾値期間にわたって別の所定閾値パーセントだけ増加した。さらに別の実施形態では、より単純な一組の所定機能が知識ベース又はエキスパートシステム無しに採用される。

【0153】

最適計算資源評価エンジン６２０は、採用されたエンジンの形式にかかわらず個々の計算資源の変更が是認されたかどうかを継続ベースで判断する。一実施形態では、このような判断に達する前に、最適計算資源評価エンジン６２０は、十分に最新な再開ファイルが利用可能かどうかを判断するために再開ファイルを解析する。例えば、最新の再開ファイル内のある情報の状態が、このような情報の現バージョンが至るであろうものとは異なる結論に至れば、最適計算資源評価エンジン６２０は、一実施形態では、提供された計算資源への無変更が是認されたということを判断する。別の実施形態では、最適計算資源評価エンジン６２０は、１つ又は複数のトリガーの所定重み付けをこのような情報のバージョン間の差異の程度に基づき調整する。

【0154】

計算資源の変更が是認されたということを最適計算資源評価エンジン６２０が判断した場合、最適計算資源計算器６３０は、ユーザのシミュレーションタスクへ割り振られる各計算資源の最適量を判断し、最適組の計算資源を１つ又は複数のハードウェア供給者プラットホーム１３０から提供される実際の物理的又は仮想的サーバ内へ翻訳するために採用される。例えば、最適計算資源評価エンジン６２０内の様々なトリガーにより提供される結果に基づき、最適計算資源計算器６３０は、ＲＡＭの量が低減されるべきである一方でＣＰＵコアの増加が是認されるということを判断し得る。しかし、正確なＣＰＵコアの数及びＲＡＭの量は、一実施形態では、過去の傾向と予測される将来の計算資源要件との両方と最新再開ファイル内で利用可能なシミュレーション状態により課される制約とを考慮して、様々なトリガーにより行われる評価から外挿することにより判断される。

【0155】

例えば、ＣＰＵコアに関して、必要とされるＣＰＵコアの予測数は過去の傾向又は予測学習エンジンに基づき得る。いずれにしても、セルの数は、コア当たりの所定最適数のセルを考慮してシミュレーションタスクの残りに必要とされる所望数のＣＰＵコアを生じるであろう（又は少なくとも、別の変更が実際の使用率データに基づき是認されるまで）一定速度で増加すると予測され得る。この所望数は、例えば最新再開ファイルが生成された時刻からの実績が考慮されると若干低減され得る。

【0156】

一実施形態では、単純平均が採用され、例えば予測される必要性がシミュレーションの残り（最新再開ファイル内の利用可能な中間状態からの）に対して１４〜４６個のコアの範囲であれば３０個のＣＰＵコアを選択する。別の実施形態では、所定機能は、例えば最小費用又は最小全体シミュレーション時間、又はいくつかの他の所望ゴールを最適化するユーザの要望を考慮して、異なる結果を生じ得る。

【0157】

同様な計算は、それぞれが各特定タイプの計算資源のシミュレーション監視サービス６１５により抽出され監視されたデータに基づく他の計算資源（ＲＡＭ、記憶装置、ネットワーク帯域幅など）に関して行われる。いずれの場合も、計算は当該特定計算資源の予測利用率に基づく。

【0158】

所望組の計算資源が判断されると（最新利用可能再開ファイルを考慮して）、これらの量は、１つ又は複数のハードウェア供給者プラットホーム１３０から実際に提供され得る一組の計算資源に効果的に翻訳される。例えば、計算はＣＰＵコア当たり３０個のＣＰＵコア及び３ＧＢのＲＡＭの要件を生成し得るが、最も整合した利用可能な物理的又は仮想的サーバは、それぞれが１６個のＣＰＵコアと６４ＧＢのＲＡＭを有する２つの仮想サーバであり得る。

【0159】

現在の一組の構成された計算資源は例えば異なるタイプの仮想サーバ（例えば８個のＣＰＵコアと６４ＧＢのＲＡＭを有するもの）を含み得るということに留意されたい。これは、本発明の一実施形態では、新しいクラスタが、場合によっては新しいハードウェア供給者プラットホーム１３０からでさえも提供されるので問題を提示しない。

【0160】

最適計算資源計算器６３０が、新しいクラスタとして提供されるべき新しい所望組の計算資源を判断すると、シミュレーション資源マネジャ１１０は、現在のクラスタを終了するためのプロセスを指揮し、新しいクラスタを提供及び構成し、当該の新しいクラスタに対するユーザのシミュレーションタスク（最新再開ファイルに含まれる中間シミュレーション状態からの）の実行を再開する。このプロセスは、以下の図７のフローチャート７００に示され、ユーザのシミュレーションタスク実行中に提供される計算資源のこの動的修正から恩恵を受けるタイプのシミュレーションシナリオの実施例と共に説明される。

【0161】

図７に移ると、フローチャート７００は、本発明のシミュレーションサーバプラットホーム１０１上のシミュレーション資源マネジャ１１０の動的動作の一実施形態を示す。このプロセスは、工程７０１において（シミュレーション資源マネジャ１１０が呼び出される前に）ユーザのシミュレーションタスク要求のシミュレーションサーバプラットホーム１０１による受信で開始する。上に指摘したように、クラスタサービス１０４は、要求タスクに関係するユーザ情報（ユーザのデータモデル、シミュレーションアプリケーションの識別子、及び当該ユーザ入力パラメータを含む）を取得するために工程７０２において呼び出される。

【0162】

工程７０４において、シミュレーション資源マネジャ１１０は最適計算資源評価エンジン６２０を初期化するために呼び出される。すべての式、閾値、規則及び他のトリガーは、ユーザのシミュレーションタスクが実行している間に、その後の使用のための所定値により初期化される。すなわち、現在提供された一組の計算資源のシミュレーションタスクによる使用を監視し、当該組の提供された計算資源を修正すべきかどうか、いつ修正すべきか、そしてどの程度修正すべきかを評価する。

【0163】

一実施形態では、この情報は、ほぼすべてのシミュレーションタスクに対して予め判断され、他の実施形態では、この情報は特定タイプのシミュレーション及びシミュレーションアプリケーションに合うように調整される（例えば、異なるシミュレーションアプリケーションは異なる最適なセル対コア比により、よりうまく行くということを考慮して）。他の実施形態では、この情報はシミュレーションサーバプラットホーム１０１又はユーザにより行われた以前のシミュレーション実行又は他の解析に基づく。

【0164】

最適計算資源評価エンジン６２０が初期化されると、最適計算資源計算器６３０が工程７１０において呼び出され、ユーザのシミュレーションタスクへ提供される最適組の計算資源を計算する。一実施形態では、工程７１０は、ユーザのシミュレーションタスクが開始される前に提供された初期組の計算資源とユーザのシミュレーションタスクが実行中に計算資源の変更が是認された場合のその後の組の計算資源とを計算するために行われるということに注意すべきである。別の実施形態では、ユーザは、シミュレーションサーバプラットホーム１０１により提供された選択肢から初期組の計算資源を選択し、この工程７１０は変更が是認された場合だけ行われる。

【0165】

初期組の計算資源に関して、最適計算資源計算器６３０は、ユーザのシミュレーションタスクが未だ開始されていないので、最適計算資源評価エンジン６２０によるいかなる解析へも未だアクセスしない。しかし、最適計算資源計算器６３０は、ユーザのシミュレーションデータモデル、シミュレーションタスクへの入力パラメータ、及び任意のユーザ提供最適化ゴールへアクセスする。さらに、サーバＤＢ１０５内に維持された過去のデータ（例えば以前のシミュレーション実行の結果に関係する）もまた利用可能かもしれない。

【0166】

例えば、シミュレーションアプリケーションは、ユーザのシミュレーションデータモデル内のセルの初期数に基づき最適数のＣＰＵコアを生じ得る最適数のコア当たりセルを推奨し得る。しかし、最適計算資源計算器６３０は、ユーザのシミュレーションタスクの同様な実行からの過去のデータの解析に基づき、異なる数の初期ＣＰＵコアを選択し得る。一実施形態では、初期時間ステップ反復（シミュレーションタスクの実行中に何度も繰り返されることになる）の以前の「事前実行」もまた、異なる数のＣＰＵコア又は他の計算資源を示唆し得る。

【0167】

いくつかのケースでは、セルの初期数がユーザのデータモデル内に明示的に定義され、一方、他のケースでは、最適計算資源計算器６３０が、例えば入力ファイルの大きさから、又は生成されるメッシュの幾何学形状及び特性に関係する他のパラメータからセルの数を推測する。例えば、１０ｍｍセルサイズと１立方メートルの領域サイズを仮定すると、最適計算資源計算器６３０は初期セルカウント１００万個のセルを計算することになる。最適計算資源計算器６３０は、シミュレーションアプリケーションがコア当たり最大１０，０００個のセルを支援することができれば恐らく１００個のＣＰＵコアの初期数を推測することになる。

【0168】

さらに、このコアの初期数は、多くのＣＰＵコアを調整するのに必要とされる特定量のＲＡＭ（例えばシミュレーションアプリケーションにより課される最小２ＧＢのＲＡＭ／コア要件に基づき）又は特定ネットワーク帯域幅（例えば２０Ｇ又は４０Ｇ ＩｎｆｉｎｉＢａｎｄ）などの他の初期計算資源を事実上規定し得る。以下に論述されるように、最適組の計算資源は利用可能な物理的又は仮想的サーバタイプに照らして精緻化される必要があり得る。

【0169】

一実施形態では、最適計算資源計算器６３０は様々なタイプのシミュレーションアプリケーションを調整する。例えば、いくつかのシミュレーションアプリケーションはセルとＣＰＵコアとを関連付けるが、他のものはユーザのシミュレーションデータモデルに基づき最小又は所望量のＲＡＭを規定し得る。

【0170】

シミュレーションタスクが、初期組の計算資源により定義される提供されたクラスタ上で実行し、最適計算資源評価エンジン６２０が、計算資源の変更が是認されたと判断すると、最適計算資源計算器６３０は、シミュレーション状態に対して発生した変更に照らした新しい最適組の計算資源を判断するために再び呼び出される。このシナリオでは、追加情報が今や利用可能である。

【0171】

例えば、ユーザのシミュレーションモデル内のセルの数が著しく増加又は低下したかもしれない。一実施形態では、最適計算資源評価エンジン６２０はシミュレーションタスクの残りのシミュレーションタスクのセルの数（又は他の計算資源）を予測する−すなわち、少なくともシミュレーションタスクが計算資源のさらに別の変更を是認する別の「局面」に入るまで。さらに、上に暗示されるように、シミュレーション監視サービス６１５により監視され最適計算資源評価エンジン６２０により評価される他の資源変更指標の評価は、シミュレーションタスクが開始される前にその初期状態からのこの新しいシミュレーション状態のいくつかの変更を反映し得る。

【0172】

例えば、出力ファイルから抽出されシミュレーションレベルトリガー評価器６２１により評価されるアプリケーション固有情報は、シミュレーションタスクが依然として初期の「メッシュイング（meshing）段階」（シミュレーションアプリケーションがユーザのシミュレーションモデルに基づきメッシュを生成している段階）にあるということを示し得る。しかし、計算資源利用情報は、ＣＰＵ利用率が期待範囲内にあった間にＲＡＭ利用率が期待されるものより著しく高かったということを示し得る。この結果、この期待以上のＲＡＭ利用の程度に基づき、最適計算資源計算器６３０は、一実施形態では、コア要件当たり増加されたＲＡＭに基づきＲＡＭの量を再計算する一方でＣＰＵコアの数を不変のままにする。

【0173】

別のシナリオでは、シミュレーションレベルトリガー評価器６２１からの情報は、シミュレーションタスクがシミュレーションのよりＣＰＵ集約的局面に入ったということと、追加ＣＰＵコアが必要とされる（又は逆に、局面が完了するとより少ないＣＰＵコアが必要とされる）ということとを示し得る。計算「式」は同じかもしれないが、ＣＰＵコアのその結果の数は、シミュレーションタスクが実行している間に生成された出力ファイルから抽出されるシミュレーション状態の変更に起因して（現在のクラスタ内に提供されたものより）より多い又は少ないかもしれない。別の実施形態では、様々な式が様々な所定シミュレーション局面のために採用され得る。さらに別の実施形態では、最適計算資源評価エンジン６２０は埋め込まれた学習エンジンを介しこのような様々な式を生成し得る。

【0174】

さらに別のシナリオでは、シミュレーションレベルトリガー評価器６２１からの情報は、シミュレーションタスクがシミュレーションのディスク集約的局面（例えば、ＣＰＵ集約的局面が完了するとシミュレーション結果をディスクへ書き出す局面）に入ったということと、より少ないＣＰＵコアが必要とされるが追加格納スペース（そして恐らく追加ネットワーク帯域幅）が必要とされるということとを示し得る。様々な組の計算資源を必要とする様々な他のシナリオはシミュレーションと他のＨＰＣコンピュータ環境とを含む並列処理の技術分野の当業者には明らかになる。

【0175】

最適計算資源計算器６３０は、工程７１０を完了し、ユーザのシミュレーションタスクへ提供される最適組の計算資源を計算する（その初期シミュレーション状態においてかその後の中間シミュレーション状態においてかにかかわらず）と、工程７１２において、この一組の最適計算資源を利用可能クラスタ内に翻訳することにより精緻化する。換言すれば、最適計算資源計算器６３０は、１つ又は複数のハードウェア供給者プラットホーム１３０上の物理的又は仮想的サーバの現在利用可能クラスタを識別するためにクラスタサービス１０４内のハードウェア供給者アダプタ１０４ｂを採用する。

【0176】

例えば、工程７１０において生成された計算資源（例えば２００個のＣＰＵコア、コア当たり３ＧＢのＲＡＭ、及び２０Ｇ ＩｎｆｉｎｉＢａｎｄ）の特定割り振りに正確に整合することは可能ではないかもしれない。最適計算資源計算器６３０は、当該タイプの３つの仮想サーバを割り振ることによりこれらの要件に厳密に整合する６４個のＣＰＵコア、２５６ＧＢのＲＡＭ及び４０Ｇ ＩｎｆｉｎｉＢａｎｄを有する仮想サーバタイプを見出し得る。しかし、追加計算資源が、ある追加費用のトレードオフを必要とするであろう。代替的に、それぞれが３２個のＣＰＵコア、１２８ＧＢのＲＡＭ及び２０ＧＢのＩｎｆｉｎｉＢａｎｄを有する６個の仮想サーバもまた利用可能かもしれない。一実施形態では、最適計算資源計算器６３０は、それぞれの実際の計算資源が利用可能クラスタ選択肢にどれだけ近いかに基づく重み付けパラメータを有する所定機能を採用することにより判断を行う。別の実施形態では、ユーザのゴール（例えば、より少ない全体シミュレーション時間とは対照的に低費用を最適化する）が、重み付けをこれらのパラメータへの割り当てる際に考慮される。さらに別の実施形態では、規則ベースエンジン（例えば、各計算資源が工程７１０において生成された仕様に等しい又はそれを越えることを保証する）が採用される。

【0177】

最適計算資源計算器６３０が工程７１２を完了し、ユーザのシミュレーションタスクへ割り振られる計算資源（当該ハードウェア供給者プラットホーム１３０、並びにそれらのプラットホーム上の各物理的及び／又は仮想的サーバの数及びタイプを含む）のクラスタを識別すると、クラスタサービス１０４は工程７２０において呼び出されて当該クラスタを提供する（上に論述したように）。次に、シミュレーションサービス１０３は、工程７２２において呼び出されて、クラスタを構成し（図５を参照して上述したように）、当該クラスタ上のシミュレーションアプリケーションの各インスタンスの実行を開始する。

【0178】

しかし、シミュレーションタスクが次に開始される前にこのクラスタが当初提供されていなければ（すなわち計算資源の変更がユーザのシミュレーションタスクが実行中に是認されるということをシミュレーション資源マネジャ６１０が判断すれば）、現在のクラスタはシミュレーションタスクの実行が、新たに提供されたクラスタ上で再開する前に終了されるということに留意されたい。

【0179】

一実施形態では、シミュレーション資源マネジャ６１０は、工程７５２において、新しいクラスタが生成され提供された後にシミュレーションタスクの実行を再開するのに必要な情報によりサーバＤＢ１０５を更新する。この情報はそうでなければ現在のクラスタが終了すれば失われることになる。例えば、シミュレーション資源マネジャ６１０は、ユーザのシミュレーションタスクが実行を再開する計算資源及び新しいクラスタの計算（工程７１０、７１２における）を容易にし得るクラスタＤＢ５３５からの他の情報だけでなく最新再開ファイルも保存する。一実施形態では、クラスタＤＢ５３５の全体は現在のクラスタが終了する前にサーバＤＢ１０５へ保存される。

【0180】

次に、シミュレーション資源マネジャ６１０は現在のクラスタを終了又は「提供解除」するために工程７５２においてクラスタサービス１０４を呼び出す。次に、最適計算資源計算器６３０は上に論述したように工程７１０、７１２を実行するために呼び出される。別の実施形態では、工程７１０、７１２は工程７５２、７５４の前に行われる（例えば、新しいクラスタを生成することが実現可能でないということが判断され、そしてシミュレーションタスクの当該実行は現在のクラスタ上で継続すべきである場合）。このシナリオでは、シミュレーション監視サービス６１５は、以下に論述されるように工程７３０においてユーザのシミュレーションタスクの実行を監視続けるために呼び出される。

【0181】

そうでなければ、工程７１０、７１２が実行された後、クラスタサービス１０４が新しいクラスタを提供するために呼び出され、そして、シミュレーションサービス１０３は、ほぼ上に論述されたやり方で当該の新しいクラスタを構成するために呼び出される。しかし、ユーザのシミュレーションタスクの実行は最新再開ファイル内に含まれる中間シミュレーション状態から再開するので、ある追加作業が工程７２２においてシミュレーションサービス１０３により行われる。例えば、クラスタＤＢ５３５が中間シミュレーション状態に従って「初期化」される。さらに、シミュレーションアプリケーションは任意のアプリケーション強要制約（新しいクラスタ内のＣＰＵコアの数を規定すること、又は新しいクラスタ内に提供された計算資源に関係する任意の同様な制約など）に従って構成される。

【0182】

次に、工程７２４では、シミュレーションサービス１０３は、新しいクラスタ内の各物理的又は仮想的サーバ内の各ＣＰＵコア上でシミュレーションアプリケーションの各インスタンスの実行を開始する。しかし、このシナリオでは、シミュレーションタスクの実行はその中間シミュレーション状態から事実上「再開」される。ユーザのシミュレーションタスクが最初に（すなわちその初期シミュレーション状態から）開始されるシナリオでは、工程７２２、７２４はその初期シミュレーション状態に関して行われる。

【0183】

ユーザのシミュレーションタスクの実行が開始される（又は再開される）と、シミュレーション監視サービス６１５は工程７３０において呼び出されてそのシミュレーションタスクの実行を監視する。上に暗示されるように、この工程は、シミュレーションタスクが実行している間にシミュレーションアプリケーションが提供された計算資源を利用する（そして、より重要なことには、利用し続ける）効率を監視することに事実上関与する。換言すれば、シミュレーション監視サービス６１５がシミュレーションタスクの実行を監視し、様々な資源変更指標を抽出すると、最適計算資源評価エンジン６２０は、計算資源の変更が是認されるかどうか（すなわち、提供された計算資源の１つ又は複数が、シミュレーションの実行が進むにつれて修正されるべきかどうか）を判断するためにこれらの資源変更指標を評価する。

【0184】

例えば、工程７３２において、シミュレーション監視サービス６１５は、上述したように計算資源利用情報を取得し、計算資源の変更が是認されるかどうかを評価するために計算資源評価エンジン６２０によるその後の評価のためにこの情報を処理する。連続的に列挙されたが、工程７３２、７３４、７３６は一実施形態ではシミュレーションタスクが実行中に並列に行われる。したがって、工程７３４において、アプリケーション固有情報は出力ファイルから抽出され、一方、工程７３６では、中間シミュレーション状態が、シミュレーションアプリケーションにより生成されると再開ファイルから取得され保存される。

【0185】

本質的に、シミュレーション監視サービス６１５は、ユーザのシミュレーションタスクの連続的に変化するシミュレーション状態を監視している。シミュレーション又は他の並列処理タスクが、計算資源に関し知られたパターンの使用率により容易に予測可能なシミュレーション段階又は局面に関与すれば、適切な一組の計算資源をこのような知られた各シミュレーション局面へ予め簡単へ割り振ることができる。これはまれなケースであるので、シミュレーション監視サービス６１５は計算資源評価エンジン６２０が将来の使用パターンに関する推論を行うための資源変更指標を抽出する。

【0186】

例えば、シミュレーションアプリケーションにより生成される出力ファイルは、コア間通信の程度だけでなく、時間の経過と共に各ＣＰＵコアにより処理されるセルの数に関する情報を含む。ＣＰＵ、ＲＡＭ、及び他の計算資源利用傾向と併せてこの情報は、シミュレーションが多少ＣＰＵ集約的な局面に入りつつあるかどうか、又は、もともと提供されたものより多い又は少ない計算資源を単に必要としているかどうかへの窓を提供する。しばしば繰り返すシミュレーション反復工程の検出もまた将来の計算使用パターンの予測を可能にする情報を提供する。

【0187】

工程７３２、７３４、７３６においてこの情報を抽出することに加えて、シミュレーション監視サービス６１５は、この情報を、計算資源評価エンジン６２０により利用され得る形式に編成することにより処理する。例えば、一実施形態では、工程７３２において抽出された計算資源利用情報は、個々の計算資源上の時間ベース照会（シミュレーション時間の過去の１５分にわたるＣＰＵ利用率のパーセント増加など）を支援するためにクラスタＤＢ５３５内でフォーマット化される。他の実施形態では、コア当たりセルの現在数、ディスクへの書き込み閾値回数、又はさらには再開ファイルの存在などの情報は、追加要因又は単なる時間を越えた事象同士を関連付ける照会を容易にするために編成される。換言すれば、シミュレーション監視サービス６１５により抽出された情報の編成は、その構成要素トリガー評価器を妨げる要因の計算資源評価エンジン６２０による評価を容易にする。

【0188】

工程７４０における計算資源評価エンジン６２０による資源変更指標の評価はまた、一実施形態では、連続的に列挙されるが並列に行われる一組の工程（７４２、７４４、７４６、７４８）に関与する。例えば、ハードウェアレベルトリガー評価器６２３により採用される規則又は発見的方法はＣＰＵ利用率が９０％を越えるとトリガーされ得、一方、別の規則は、ＣＰＵ利用率が９０％を越え、出力ファイルから抽出される情報が、シミュレーションの現在のＣＰＵ集約的局面が完了した（例えば、シミュレーションレベルトリガー評価器６２１により検出された）ということを示す場合だけ、トリガーされ得る。別の規則は、ＣＰＵ利用率が規定閾値を下回り、ディスクＩ／Ｏが規定閾値を越え、より広いネットワーク帯域幅を有する物理的又は仮想的サーバの必要性を示唆すると、トリガーされ得る。

【0189】

換言すれば、工程７４２において、ハードウェアレベルトリガー評価器６２３は計算資源利用に関係するトリガー条件又は事象を生成し、一方、工程７４４では、シミュレーションレベルトリガー評価器６２１は、出力ファイルから抽出されたアプリケーション固有情報に関係する条件又は事象を生成する。上に指摘したように、このようなアプリケーションレベル事象は、反復工程（例えば、鼓動、バルブの開閉、自動車衝突などのシミュ―ション事象の秒、又はさらにはセル圧力、温度、速度を別々に計算する反復工程の階層などの繰り返される現実世界事象をシミュレーションすること）の検出を含む。

【0190】

いくつかのシナリオでは、その後の反復工程は様々なタイプの計算に関与する。例えば、化学的シミュレーションでは、初期工程は分子など広い領域の物質全体にわたる比較的短い計算に関与し得る。このような工程は、多くのＣＰＵコア全体にわたる比較的高いレベルの並列性から恩恵を受け得る。しかし、その後の計算は、順次複雑となり、完了するのにより長い時間がかかり得るが、ますます少ない物質全体にわたるものである（したがって、比較的低い並列性と少ないＣＰＵコアから恩恵を受ける）。シミュレーションレベルトリガー評価器６２１によるこのような局面の検出は将来のＣＰＵ使用の予測を容易にする。一実施形態では、シミュレーションレベルトリガー評価器６２１は、ＣＰＵコアの数の変更をトリガーするだけでなく、このようなシナリオでは、新しいクラスタ内に提供される最適数のＣＰＵコアの最適計算資源計算器６３０による計算を容易にすることになる条件又は事象を生成する。

【0191】

同様に、工程７４６では、ユーザレベルトリガー評価器６２２はユーザ強要ゴールに従って条件又は事象を生成する。一実施形態では、このようなゴールは、他のトリガー評価器からの規則のパラメータを重み付ける（例えば、追加ＣＰＵコアがユーザへ追加費用で追加される前にＣＰＵ利用率の閾値を９５％へ引き上げさせる）ことにより実施される。逆に、ＣＰＵ利用率の下側閾値は、ＣＰＵコアが低減される前に４０％から４５％へ上昇され得、これによりユーザのお金を節約する。一実施形態では、いくつかの要因（例えば自由ＲＡＭの下側閾値）の極端な重み付けが、ＲＡＭを使い果たすことによりシミュレーションをクラッシュすることなどの破局的事象を場合によっては回避するために採用される。

【0192】

工程７４８において、シミュレーションレベルトリガー評価器６２１は、シミュレーションアプリケーションにより生成される再開ファイルに関係する条件又は事象を生成する。一実施形態では、閾値期間内の再開ファイルの存在がこのような条件をトリガーする。他の実施形態では、条件は、シミュレーションアプリケーションの構成要素ソルバの呼び出しなど再開ファイルのコンテンツから抽出又は推論された特定事象（例えば、シミュレーションのよりＣＰＵ集約的であるがそれほどディスク集約的でない局面へのエントリの証拠付け）に基づきトリガーされ得る。

【0193】

上に指摘したように、計算資源評価エンジン６２０は、一実施形態では、時間の経過と共に監視される過去の情報に基づき計算資源の将来利用を予測する学習エンジンとして実現され、知識ベースからの所定規則よりむしろ動的に生成されたトリガーを採用する。別の実施形態では、経験的規則は連続的に拡張する知識ベースから動的に生成され、一方、さらに別の実施形態では、所定「静的」式及び閾値が採用される。

【0194】

以下のシナリオは、工程７５０において計算資源の変更が是認されたかどうかに関する判断を行う際に計算資源評価エンジン６２０の動作（特に工程７４２、７４４、７４６及び７４８の性能）を示す。このような変更が是認されれば、シミュレーション資源マネジャ６１０は、（新しいクラスタが生成され提供された後にシミュレーションタスクの実行を再開するのに必要な情報によりサーバＤＢ１０５を更新するために）上述したように工程７５２において呼び出される。そうでなければ、シミュレーション監視サービス６１５は、工程７３０においてユーザのシミュレーションタスクの実行を監視し続けるために呼び出される。

【0195】

１つのシナリオでは、ユーザのシミュレーションタスクは、例えば自動車エンジンの燃焼をシミュレーションするＣＦＤ（計算流体力学）アプリケーションの燃焼モデルに関与する。このシナリオでは、燃焼事象が発生すると、シミュレーションは、セルサイズが減少し、セルの数が著しく増加するＣＰＵ集約的局面に入る。換言すれば、シミュレーションアプリケーションは各セルを複数（例えば８つ）のセルに分割する。このようなシミュレーションアプリケーションは通常、発生し得るスプリットの数を制限するように構成される（又は逆に、多数の複数セルが単一セルに合成される）が、燃焼又は同様な事象の発生は予め容易には予測され得ない。

【0196】

このシナリオでは、シミュレーションアプリケーションは時折、ユーザのシミュレーションモデル内のセルの現在数に関係する情報を含む出力ファイルを生成する。上に指摘したように、これらの出力ファイルは、ユーザがモデル内のバグ（すなわち、シミュレーションをシャットダウンすることと、バグが修理されるとシミュレーションを始めから再び実行することとを是認する非常に普通でない状況）を手動で検出することを可能にするために生成される。しかし、本発明では、シミュレーションレベルトリガー評価器６２１は、工程７４４において、燃焼事象が開始したことを、出力ファイルから抽出される情報に基づき検出する。例えば、このような情報は、セルの数の急増、又は明示的「スプリット」事象を示し得る。いくつかのケースでは、この事象は出力ファイル内の他の情報（燃焼事象を処理するように設計された特定ソルバの呼び出しなど）により確認され得る。

【0197】

シミュレーションレベルトリガー評価器６２１はまた、工程７４８において、シミュレーションが燃焼局面に入る前に再開ファイルが比較的最近生成されたということを検出し、最終的に計算資源評価エンジン６２０にＣＰＵコアの数を増加させ得る。他の計算資源も同様に影響を受け得る。例えば、ハードウェアレベルトリガー評価器６２３は、工程７４２において、既存数のＣＰＵコアに対する要求の増加から生じる１つ又は複数の条件（例えばディスクへの書き込みの増加及び利用可能ＲＡＭの著しい減少）をトリガーしたかもしれない。

【0198】

しかし、この実施形態では、計算資源評価エンジン６２０は、どのようにＣＰＵコアの数の将来増加（例えば、６４〜１２８個）がこれらの他の計算資源の利用率に影響を与えるかを予測する。例えば、ＣＰＵコア当たりＲＡＭの現在量は、追加計算の負荷が多数のＣＰＵコア全体にわたって拡散される（各物理的又は仮想的サーバへの負荷を緩和する）と十分であり得、一方ネットワーク帯域幅はコア間及びサーバ間通信の増加により増加される必要があるかもしれない。

【0199】

したがって、その結果、最適計算資源計算器６３０は計算資源のこれらの変更を計算するために工程７１０において呼び出され、新しいクラスタが工程７２０において提供され、工程７２２において構成される。この新しいクラスタは、多くのＣＰＵコア、同じ量のＲＡＭ、及びより広いネットワーク帯域幅から構成されるので、恐らく異なるハードウェア供給者プラットホーム１３０上に異なるタイプの物理的又は仮想的サーバを必要とし得る（例えば現在利用可能性に起因して）。

【0200】

比較的最新の再開ファイルの存在により、シミュレーションタスクは、シミュレーションの燃焼局面の始まりの前に工程７２４において新しいクラスタ上で実行を再開し得る（したがって、不十分な量のＲＡＭに起因するあまりにも少ないＣＰＵコアを有する場合によってはクラッシュするという非効率性を回避する）。さらに、この燃焼局面の終了を同様なやり方で後で検出するとシミュレーション資源マネジャ６１０は計算資源を再び修正し（例えば、ＣＰＵコアの数を低減し、これに従って他の計算資源を修正し）、シミュレーションタスクの実行を再開するためにさらに別のクラスタを提供することになる。

【0201】

したがってこの燃焼シナリオでは、シミュレーションタスク実行中に３つの異なるクラスタが提供される。各クラスタは、資源変更指標を監視及び抽出し、将来利用パターンを予測し、そしてこれらの将来利用パターンを調整するために様々な組の計算資源を有する新しいクラスタを生成することにより判断された、その実行中の様々な時点におけるシミュレーションタスクへの計算資源の最適割り振りに基づく。

【0202】

他のシナリオでは、新しいクラスタはシミュレーションタスクの実行中の複数の異なる時点に提供され得る。上に指摘したように、いつこれらの時点が発生するかとシミュレーション中のどれくらい多くの異なる時点に計算資源の変更が是認され得るかとを予め予測するのはしばしば困難である（事象の発生が知られている上記燃焼例においてですら）。例えば、各工程中に行われる計算が、時間、複雑性、又は他の点で異なる（ランダムに、徐々に増加又は低下する、又はその他の方法で、かに関わらず）であろう「可変」反復工程に関わるシミュレーションの場合、いつ各反復工程が発生するかを予め予測することは実質的に不可能であり、ましてどの組の計算資源を各特定工程へ割り振るべきかを予め予測することは不可能である。

【0203】

しかし、シミュレーションタスク実行中にシミュレーション状態を監視し、資源変更指標（シミュレーションアプリケーションにより生成される出力ファイルからのアプリケーション固有情報だけでなく計算資源利用情報も含む）を抽出することにより、本発明は将来の計算資源活用パターンを予測し（例えばその後の反復工程が各個々の計算資源の増加又は低減を必要とするかどうかを評価することにより）、シミュレーションタスクへ割り振られる最適組の計算資源（物理的及び／又は仮想的サーバのクラスタ内に翻訳された）を判断する。さらに、シミュレーションアプリケーションにより生成された再開ファイルをてこ入れすることにより、本発明は既存クラスタを終了し、新しいクラスタを提供し（計算資源の変更が是認されかつ実現可能であると判断した場合）、新たに提供されたクラスタ上でシミュレーションタスクの実行を再開する。このプロセスは、シミュレーションタスクが実行中に是認されるのと同じぐらい何度も繰り返され得る。

【0204】

計算資源は、新しいクラスタを終了及び提供するオーバーヘッドが計算資源のより効率的な割り振りの恩恵を正当化しないかもしれないので、あまり頻繁には都合よく変更することができないということに注意すべきである。一実施形態では、このトレードオフは、計算資源の変更が実際に是認されたかどうかを判断する（例えばクラスタ変更間の時間に基づき）際のシミュレーション資源マネジャ６１０による一因子と考えられる。

【0205】

上述の本発明のシステム及び方法の実施形態は著しい利点をシミュレーションサーバプラットホーム１０１のユーザへ提供する。このようなユーザは、それらのシミュレーションタスクの全体へ割り振られる単一組の計算資源に依存する必要はない。さらに、このようなユーザ自身は、それらのシミュレーションタスクの実行中に計算資源の変更が是認されるかどうか、いつ是認されるか、どの程度是認されるかを判断する必要はない（例えばAmazonのＥＣ２自動スケーリングサービスにより必要とされるのとは異なり）。最後に、ユーザは、それらのシミュレーションタスクの実行中に生じるアプリケーション強要制約及びコア間（そしてサーバ間）依存性に対処するそれらのシミュレーションアプリケーションを有する恩恵を保持する。

【0206】

他の利点は、ユーザがそれらのシミュレーションタスクにより実際に使用された計算資源だけの代金を支払うことと、それらのシミュレーションタスクの実行中に常時は必要ない計算資源の代金を過剰に払うことを回避することとを可能にする自動ハードウェア及びソフトウェア計測を含む。以下に出願当初の請求項を付記する。
条項１． インスタンス間依存性を有するタスクを実行するアプリケーションの実行のための計算資源の提供を動的に最適化するシステムであって、前記アプリケーションは、正しく実行し、前記インスタンス間依存性を解決するために、前記アプリケーションへ割り振られたる前記計算資源の少なくとも１つの計算資源の事前構成仕様を必要とする１つ又は複数のアプリケーション強要制約を含み、前記システムは、
（ａ）前記アプリケーションを実行するためのハードウェア供給者プラットホーム上に計算資源のクラスタを提供するクラスタサービスと；
（ｂ）前記アプリケーション強要制約に従って前記アプリケーションを構成し、前記提供されたクラスタ上の前記アプリケーションの実行を開始するアプリケーションサービスと；
（ｃ）（ｉ）複数の計算資源変更指標及び（ｉｉ）前記アプリケーションにより生成される１つ又は複数の再開ファイルに関する前記アプリケーションの実行を監視するアプリケーション監視サービスと；
（ｄ）（ｉ）現在の計算資源の修正が是認されたかどうかを判断し、そうであれば（ｉｉ）前記アプリケーションの実行中に前記現在の計算資源の変更を実施するために前記計算資源変更指標及び前記再開ファイルを連続的に解析する計算資源評価エンジンと、を含むシステム。
条項２． （ａ）前記クラスタは前記アプリケーションの独立サブタスク計算を並列に実行するための複数のＣＰＵコアを含み、前記独立サブタスク計算は、第１のＣＰＵコア上で前記アプリケーションの第１のインスタンスにより行われる第１のサブタスク計算と、第２のＣＰＵコア上で前記アプリケーションの第２のインスタンスにより行われる第２のサブタスク計算とを含み；
（ｂ）前記第１のインスタンスにより行われる第３のサブタスク計算は、前記第２のインスタンスにより行われる前記第２のサブタスク計算の結果に依存し、これによりインスタンス間依存性を構成する、条項１に記載のシステム。
条項３． 前記複数の計算資源変更指標は：
（ａ）前記計算資源の前記アプリケーションの現在の利用の程度を反映する計算資源利用データと；
（ｂ）アプリケーション固有データであって、その実行中に前記アプリケーションにより生成される出力ファイルから抽出されるデータを含み、前記アプリケーションの将来利用の計算資源の予測を容易にするアプリケーション固有データとを含む、条項１に記載のシステム。
条項４． 前記計算資源変更指標は、（ａ）前記アプリケーションへの入力として提供されるシミュレーションデータモデル内のセルの数の変更、（ｂ）前記アプリケーションにより行われる前記タスク内の１つ又は複数の繰り返し反復工程、（ｃ）前記アプリケーションにより呈示されるコア間通信の程度の変更、及び（ｄ）前記アプリケーションにより行われる前記タスクの多少計算資源集約的な局面への変更のうちの１つ又は複数の指標を含む、条項１に記載のシステム。
条項５． 前記計算資源評価エンジンは、前記計算資源変更指標のその解析に基づき、前記アプリケーションの計算資源の将来利用の程度に関する予測を生成する、条項１に記載のシステム。
条項６． 前記計算資源評価エンジンは、前記現在の計算資源の修正が是認されたかどうかのその判断の基礎を、時間の経過と共に前記アプリケーション監視サービスにより監視される過去の情報に置く、条項１に記載のシステム。
条項７． 前記アプリケーション強要制約は、前記提供されたクラスタ内のＣＰＵコアの数の事前構成仕様を含む、条項１に記載のシステム。
条項８． 計算資源の前記変更は１つの計算資源の増加と別の計算資源の低減とを含む、条項１に記載のシステム。
条項９． 各再開ファイルは、前記アプリケーションの現在の中間状態を反映するデータを含み、これにより、将来再開される場合に前記アプリケーションが前記中間状態からの実行を再開することを可能にする、条項１に記載のシステム。
条項１０． 前記計算資源評価エンジンは、前記アプリケーションの実行中に：
（ａ）前記クラスタサービスに、選択されたハードウェア供給者プラットホーム上に計算資源の新しいクラスタを提供するように指示すること；
（ｂ）前記アプリケーションが実行されている前記現在のクラスタを終了すること；及び
（ｃ）前記アプリケーションサービスに、前記アプリケーションを前記アプリケーション強要制約に従って再構成し、前記提供された新しいクラスタ上の前記アプリケーションの実行を前記再開ファイルのうちの選択された１つに含まれる前記中間状態から開始するように指示することにより、前記現在の計算資源の変更を実施する、条項１に記載のシステム。
条項１１． 前記提供されたクラスタ上の前記アプリケーションの実行を開始することを各ユーザに許容する前に、対応するライセンスサーバにより前記アプリケーションの前記各ユーザを認証するライセンスサービスをさらに含む条項１に記載のシステム。
条項１２． 前記提供されたクラスタ上の前記アプリケーションの前記構成要素の実行を開始することを各ユーザに許容する前に、前記アプリケーションの構成要素の前記各ユーザを認証するライセンスサービスをさらに含む条項１に記載のシステム。
条項１３． （ａ）前記提供された計算資源が前記タスクの実行中に使用される全時間を監視するハードウェア計測モジュールと、
（ｂ）前記アプリケーションが前記タスクの実行中に使用される全時間を監視するソフトウェア計測モジュールとをさらに含む条項１に記載のシステム。
条項１４． 前記ソフトウェア計測モジュールは、前記アプリケーションの構成要素が前記タスクの実行中に使用される全時間を監視する、条項１３に記載のシステム。
条項１５． 前記アプリケーションは前記提供されたクラスタ上で終了され、異なる計算資源を有する新しいクラスタ上で再開され、
前記ソフトウェア計測モジュールにより監視される前記全時間は、前記アプリケーションが前記提供されたクラスタ及び前記新しいクラスタ上で前記タスクの実行中に使用される時間の合計を含む、条項１３に記載のシステム。
条項１６． 前記ソフトウェア計測モジュールは前記タスクを実行する複数のアプリケーションを監視する、条項１３に記載のシステム。
条項１７． インスタンス間依存性を有するタスクを実行するアプリケーションの実行のための計算資源の提供を動的に最適化する方法であって、前記アプリケーションは、正しく実行し、前記インスタンス間依存性を解決するために、前記アプリケーションへ割り振られた前記計算資源の少なくとも１つの計算資源の事前構成仕様を必要とする１つ又は複数のアプリケーション強要制約を含み、前記方法は、
（ａ）前記アプリケーションを実行するためのハードウェア供給者プラットホーム上に計算資源のクラスタを提供する工程と；
（ｂ）前記アプリケーション強要制約に従って前記アプリケーションを構成し、前記提供されたクラスタ上の前記アプリケーションの実行を開始する工程と；
（ｃ）（ｉ）複数の計算資源変更指標及び（ｉｉ）前記アプリケーションにより生成される１つ又は複数の再開ファイルに関する前記アプリケーションの実行を監視する工程と；
（ｄ）現在の計算資源の修正が是認されたかどうかを判断し、そうであれば前記アプリケーションの実行中に前記現在の計算資源の変更を実施するために前記計算資源変更指標及び前記再開ファイルを連続的に解析する工程と、を含む方法。
条項１８． （ａ）前記クラスタは、前記アプリケーションの独立サブタスク計算を並列に実行するための複数のＣＰＵコアを含み、前記独立サブタスク計算は、第１のＣＰＵコア上で前記アプリケーションの第１のインスタンスにより行われる第１のサブタスク計算と、第２のＣＰＵコア上で前記アプリケーションの第２のインスタンスにより行われる第２のサブタスク計算とを含み；
（ｂ）前記第１のインスタンスにより行われる第３のサブタスク計算は、前記第２のインスタンスにより行われる前記第２のサブタスク計算の結果に依存し、これによりインスタンス間依存性を構成する、条項１７に記載の方法。
条項１９． 前記複数の計算資源変更指標は：
（ａ）前記計算資源の前記アプリケーションの現在の利用の程度を反映する計算資源利用データと；
（ｂ）アプリケーション固有データであって、その実行中に前記アプリケーションにより生成される出力ファイルから抽出されるデータを含み、前記アプリケーションの将来利用の計算資源の予測を容易にするアプリケーション固有データとを含む、条項１７に記載の方法。
条項２０． 前記計算資源変更指標は、（ａ）前記アプリケーションへの入力として提供されるシミュレーションデータモデル内のセルの数の変更、（ｂ）前記アプリケーションにより行われる前記タスク内の１つ又は複数の繰り返し反復工程、（ｃ）前記アプリケーションにより呈示されるコア間通信の程度の変更、及び（ｄ）前記アプリケーションにより行われる前記タスクの多少計算資源集約的な局面への変更のうちの１つ又は複数の指標を含む、条項１７に記載の方法。
条項２１． 前記計算資源変更指標の前記解析に基づき、計算資源の前記アプリケーションの将来利用の程度に関する予測を生成する工程をさらに含む条項１７に記載の方法。
条項２２． 前記現在の計算資源の修正が是認されたかどうかの前記判断は時間の経過と共に監視される過去の情報に基づく、条項１７に記載の方法。
条項２３． 前記アプリケーション強要制約は前記提供されたクラスタ内のＣＰＵコアの数の事前構成仕様を含む、条項１７に記載の方法。
条項２４． 計算資源の前記変更は１つの計算資源の増加と別の計算資源の低減とを含む、条項１７に記載の方法。
条項２５． 各再開ファイルは、前記アプリケーションの現在の中間状態を反映するデータを含み、これにより、将来再開される場合に前記アプリケーションが前記中間状態からの実行を再開することを可能にする、条項１７に記載の方法。
条項２６． 前記アプリケーション実行中の前記現在の計算資源の変更の前記実施は：
（ａ）選択されたハードウェア供給者プラットホーム上に計算資源の新しいクラスタを提供する工程と；
（ｂ）前記アプリケーションが実行されている前記現在のクラスタを終了する工程と；
（ｃ）前記アプリケーション強要制約に従って前記アプリケーションを再構成する工程と、
（ｄ）前記提供された新しいクラスタ上の前記アプリケーションの実行を前記再開ファイルのうちの選択された１つに含まれる前記中間状態から開始する工程とを含む、条項１７に記載の方法。
条項２７． 前記ユーザに、前記提供されたクラスタ上の前記アプリケーションの実行を開始することを許容する前に、対応するライセンスサーバにより前記アプリケーションの各ユーザを認証する工程をさらに含む条項１７に記載の方法。
条項２８． 前記提供されたクラスタ上の前記アプリケーションの前記構成要素の実行を開始することを各ユーザに許容する前に、前記アプリケーションの構成要素の前記各ユーザを認証する工程をさらに含む条項１７に記載の方法。
条項２９． （ａ）前記提供された計算資源が前記タスクの実行中に使用される全時間を監視する工程と、
（ｂ）前記アプリケーションが前記タスクの実行中に使用される前記全時間を監視する工程とをさらに含む条項１７に記載の方法。
条項３０． 前記アプリケーションの構成要素が前記タスクの実行中に使用される全時間を監視する工程をさらに含む条項２９に記載の方法。
条項３１． 前記アプリケーションは前記提供されたクラスタ上で終了され、異なる計算資源を有する新しいクラスタ上で再開され、前記アプリケーションが前記タスクの実行中に使用される全時間は、前記アプリケーションが前記提供されたクラスタ及び前記新しいクラスタ上で前記タスクの実行中に使用される時間の合計を含む、条項２９に記載の方法。
条項３２． 前記タスクを実行する複数のアプリケーションを監視する工程をさらに含む条項２９に記載の方法。
条項３３． 複数のユーザのために複数のアプリケーションにより行われるタスクのハードウェア及びソフトウェア計測を容易にするシステムであって、
（ａ）ユーザのためにアプリケーションを実行するための複数のハードウェア供給者プラットホームのうちの１つの上に計算資源の第１のクラスタを提供し、前記アプリケーションの実行中に計算資源の変更が是認されると、計算資源の第２のクラスタを提供し、前記第１のクラスタ上の前記アプリケーションを終了する、クラスタサービスと；
（ｂ）前記アプリケーションを構成し、前記提供された第１のクラスタ上の前記アプリケーションの実行を開始し、前記第２のクラスタが前記クラスタサービスにより提供されると、前記アプリケーションを再構成し、前記第２のクラスタ上の前記アプリケーションの実行を再開する、アプリケーションサービスと；
（ｃ）前記提供された第１及び第２のクラスタ上の前記アプリケーションの実行を開始することを各ユーザに許容する前に、対応するライセンスサーバにより前記アプリケーションの前記各ユーザを認証するライセンスサービスと、
（ｄ）前記提供された計算資源が前記タスクの実行中に使用される全ハードウェア時間を監視するハードウェア計測モジュールであって、前記全ハードウェア時間は、前記提供された計算資源が前記第１のクラスタ及び前記第２のクラスタ上で使用される時間の合計を含む、ハードウェア計測モジュールと；
（ｅ）前記アプリケーションが前記タスクの実行中に使用される全ソフトウェア時間を監視するソフトウェア計測モジュールであって、前記全ソフトウェア時間は、前記アプリケーションが前記第１のクラスタ及び前記第２のクラスタ上で使用される時間の合計を含む、ソフトウェア計測モジュールとを含むシステム。
条項３４． 前記ライセンスサービスは、前記提供された第１及び第２のクラスタ上の前記アプリケーションの前記構成要素の実行を開始することを各ユーザに許容する前に、前記アプリケーションの構成要素の前記各ユーザを認証する、条項３３に記載のシステム。
条項３５． 前記ソフトウェア計測モジュールは、前記アプリケーションの構成要素が前記タスクの実行中に使用される全ソフトウェア時間を監視する、条項３３に記載のシステム。
条項３６．前記ソフトウェア計測モジュールは前記タスクを実行する複数のアプリケーションを監視する、条項３３に記載のシステム。
条項３７． 前記アプリケーションはインスタンス間依存性を有するタスクを実行し、前記アプリケーションは、正しく実行し、前記インスタンス間依存性を解決するために、前記アプリケーションへ割り振られた前記計算資源の少なくとも１つの計算資源の事前構成仕様を必要とする１つ又は複数のアプリケーション強要制約を含み、前記システムは、
（ａ）（ｉ）複数の計算資源変更指標及び（ｉｉ）前記アプリケーションにより生成される１つ又は複数の再開ファイルに関する前記アプリケーションの実行を監視するアプリケーション監視サービスと；
（ｂ）（ｉ）前記現在の計算資源の修正が是認されたかどうかを判断し、そうであれば（ｉｉ）前記アプリケーションの実行中に前記現在の計算資源の変更を実施するために前記計算資源変更指標及び前記再開ファイルを連続的に解析する計算資源評価エンジンと、をさらに含む条項３３に記載のシステム。
条項３８． （ａ）前記クラスタは、前記アプリケーションの独立サブタスク計算を並列に実行するための複数のＣＰＵコアを含み、前記独立サブタスク計算は、第１のＣＰＵコア上で前記アプリケーションの第１のインスタンスにより行われる第１のサブタスク計算と、第２のＣＰＵコア上で前記アプリケーションの第２のインスタンスにより行われる第２のサブタスク計算とを含み；
（ｂ）前記第１のインスタンスにより行われる第３のサブタスク計算は、前記第２のインスタンスにより行われる前記第２のサブタスク計算の結果に依存し、これによりインスタンス間依存性を構成する、条項３７に記載のシステム。
条項３９． 前記複数の計算資源変更指標は：
（ａ）前記計算資源の前記アプリケーションの現在の利用の程度を反映する計算資源利用データと；
（ｂ）アプリケーション固有データであって、その実行中に前記アプリケーションにより生成される出力ファイルから抽出されるデータを含み、前記アプリケーションの将来利用の計算資源の予測を容易にするアプリケーション固有データとを含む、条項３７に記載のシステム。
条項４０． 前記計算資源変更指標は、（ａ）前記アプリケーションへの入力として提供されるシミュレーションデータモデル内のセルの数の変更、（ｂ）前記アプリケーションにより行われる前記タスク内の１つ又は複数の繰り返し反復工程、（ｃ）前記アプリケーションにより呈示されるコア間通信の程度の変更、及び（ｄ）前記アプリケーションにより行われる前記タスクの多少計算資源集約的な局面への変更のうちの１つ又は複数の指標を含む、条項３７に記載のシステム。
条項４１． 前記計算資源評価エンジンは、前記計算資源変更指標のその解析に基づき、前記アプリケーションの計算資源の将来利用の程度に関する予測を生成する、条項３７に記載のシステム。
条項４２． 前記計算資源評価エンジンは、前記現在の計算資源の修正が是認されたかどうかのその判断の基礎を、時間の経過と共に前記アプリケーション監視サービスにより監視される過去の情報に置く、条項３７に記載のシステム。
条項４３． 前記アプリケーション強要制約は前記提供された第１及び第２のクラスタ内のＣＰＵコアの数の事前構成仕様を含む、条項３７に記載のシステム。
条項４４． 計算資源の前記変更は１つの計算資源の増加と別の計算資源の低減とを含む、条項３７に記載のシステム。
条項４５． 各再開ファイルは、前記アプリケーションの現在の中間状態を反映するデータを含み、これにより、将来再開される場合に前記アプリケーションが前記中間状態からの実行を再開することを可能にする、条項３７に記載のシステム。
条項４６． 前記計算資源評価エンジンは、前記アプリケーションの実行中に、
（ａ）前記クラスタサービスに、選択されたハードウェア供給者プラットホーム上に計算資源の前記第２のクラスタを提供するように指示すること、
（ｂ）前記アプリケーションが実行されている前記第１のクラスタを終了すること、及び
（ｃ）前記アプリケーション強要制約に従って前記アプリケーションを再構成し、前記再開ファイルの選択された１つに含まれる前記中間状態から前記第２のクラスタ上の前記アプリケーションの実行を再開することにより、前記現在の計算資源の変更を実施する、条項３７に記載のシステム。
条項４７． 複数のユーザのために複数のアプリケーションにより行われるタスクのハードウェア及びソフトウェア計測を容易にする方法であって、
（ａ）ユーザのためにアプリケーションを実行するための複数のハードウェア供給者プラットホームのうちの１つの上に計算資源の第１のクラスタを提供し、計算資源の変更は前記アプリケーションの実行中に是認されると、計算資源の第２のクラスタを提供し、前記第１のクラスタ上の前記アプリケーションを終了する工程と；
（ｂ）前記アプリケーションを構成し、前記提供された第１のクラスタ上の前記アプリケーションの実行を開始し、前記第２のクラスタが前記クラスタサービスにより提供されると、前記アプリケーションを再構成し、前記第２のクラスタ上の前記アプリケーションの実行を再開する工程と；
（ｃ）前記提供された第１及び第２のクラスタ上の前記アプリケーションの実行を開始することを各ユーザに許容する前に、対応するライセンスサーバにより前記アプリケーションの前記各ユーザを認証する工程と、
（ｄ）前記提供された計算資源が前記タスクの実行中に使用される全ハードウェア時間を監視する工程であって、前記全ハードウェア時間は、前記提供された計算資源が前記第１のクラスタ及び前記第２のクラスタ上で使用される時間の合計を含む、工程と；
（ｅ）前記アプリケーションが前記タスクの実行中に使用される前記全時間を監視する工程であって、前記全ソフトウェア時間は、前記アプリケーションが前記第１のクラスタ及び前記第２のクラスタ上で使用される時間の合計を含む、工程とを含む方法。
条項４８． 前記提供された第１及び第２のクラスタ上の前記アプリケーションの前記構成要素の実行を開始することを各ユーザに許容する前に、前記アプリケーションの構成要素の前記各ユーザを認証する工程をさらに含む条項４７に記載の方法。
条項４９． 前記アプリケーションの構成要素が前記タスクの実行中に使用される全ソフトウェア時間を監視する工程をさらに含む条項４７に記載の方法。
条項５０． 前記タスクを実行する複数のアプリケーションを監視する工程をさらに含む条項４７に記載の方法。
条項５１． 前記アプリケーションはインスタンス間依存性を有するタスクを実行し、前記アプリケーションは、正しく実行し、前記インスタンス間依存性を解決するために、前記アプリケーションへ割り振られた前記計算資源の少なくとも１つの計算資源の事前構成仕様を必要とする１つ又は複数のアプリケーション強要制約を含み、前記方法は、
（ａ）（ｉ）複数の計算資源変更指標及び（ｉｉ）前記アプリケーションにより生成される１つ又は複数の再開ファイルに関する前記アプリケーションの実行を監視する工程と；
（ｂ）前記現在の計算資源の修正が是認されたかどうかを判断し、そうであれば前記アプリケーションの実行中に前記現在の計算資源の変更を実施するために前記計算資源変更指標及び前記再開ファイルを連続的に解析する工程と、をさらに含む、条項４７に記載の方法。
条項５２． （ａ）前記クラスタは、前記アプリケーションの独立サブタスク計算を並列に実行するための複数のＣＰＵコアを含み、前記独立サブタスク計算は、第１のＣＰＵコア上で前記アプリケーションの第１のインスタンスにより行われる第１のサブタスク計算と、第２のＣＰＵコア上で前記アプリケーションの第２のインスタンスにより行われる第２のサブタスク計算とを含み；
（ｂ）前記第１のインスタンスにより行われる第３のサブタスク計算は、前記第２のインスタンスにより行われる前記第２のサブタスク計算の結果に依存し、これによりインスタンス間依存性を構成する、条項５１に記載の方法。
条項５３． 前記複数の計算資源変更指標は：
（ａ）前記計算資源の前記アプリケーションの現在の利用の程度を反映する計算資源利用データと；
（ｂ）アプリケーション固有データであって、その実行中に前記アプリケーションにより生成される出力ファイルから抽出されるデータを含み、前記アプリケーションの将来利用の計算資源の予測を容易にするアプリケーション固有データとを含む、条項５１に記載の方法。
条項５４． 前記計算資源変更指標は、（ａ）前記アプリケーションへの入力として提供されるシミュレーションデータモデル内のセルの数の変更、（ｂ）前記アプリケーションにより行われる前記タスク内の１つ又は複数の繰り返し反復工程、（ｃ）前記アプリケーションにより呈示されるコア間通信の程度の変更、及び（ｄ）前記アプリケーションにより行われる前記タスクの多少計算資源集約的な局面への変更のうちの１つ又は複数の指標を含む、条項５１に記載の方法。
条項５５． 前記計算資源変更指標の前記解析に基づき計算資源の前記アプリケーションの将来利用の程度に関する予測を生成する工程をさらに含む条項５１に記載の方法。
条項５６． 前記現在の計算資源の修正が是認されたかどうかの前記判断は時間の経過と共に監視される過去の情報に基づく、条項５１に記載の方法。
条項５７． 前記アプリケーション強要制約は前記提供された第１及び第２のクラスタ内のＣＰＵコアの数の事前構成仕様を含む、条項５１に記載の方法。
条項５８． 計算資源の前記変更は１つの計算資源の増加と別の計算資源の低減とを含む、条項５１に記載の方法。
条項５９． 各再開ファイルは、前記アプリケーションの現在の中間状態を反映するデータを含み、これにより、将来再開される場合に前記アプリケーションが前記中間状態からの実行を再開することを可能にする、条項５１に記載の方法。
条項６０． 前記アプリケーション実行中の前記現在の計算資源の変更の前記実施は：
（ａ）選択されたハードウェア供給者プラットホーム上に計算資源の前記第２のクラスタを提供する工程と；
（ｂ）前記アプリケーションが実行されている前記第１のクラスタを終了する工程と；
（ｃ）前記アプリケーション強要制約に従って前記アプリケーションを再構成了する工程と、
（ｄ）前記再開ファイルの選択された１つに含まれる前記中間状態から前記第２のクラスタ上の前記アプリケーションの実行を再開了する工程とを含む、条項５１に記載の方法。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】