ionworks-api Python パッケージは、パイプラインの実行と管理のための client.pipeline を提供します。インストールと認証については Python API クライアント を参照してください。
パイプラインの送信
client.pipeline.create() は iws.Pipeline インスタンスでも .to_config() が返す dict でも受け取れます。スキーマインスタンスは送信前にローカルで検証されるため、形状エラーは即座に表面化します。
パイプラインを JSON にシリアライズする
送信前のペイロード確認、キャッシュ、バージョン管理へのコミット、あるいは別プロセスへの受け渡しなど、パイプラインを JSON として扱いたい場合は.to_config() を使用してください。
送信メタデータの上書き
create() は、スキーマに含まれる値を上書きするための project_id、name、description、options を kwargs として受け付けます。
project_id を省略した場合、クライアントは Ionworks(...) のデフォルト、または環境変数 IONWORKS_PROJECT_ID にフォールバックします。
パイプライン内のデータ参照
パイプライン設定でデータソースを参照するには、これらのプレフィックスを使用します:folder: スキームは time_series ファイルと steps ファイルを含むディレクトリを想定しています。.parquet と .csv の両方がサポートされ、両方が存在する場合は parquet が優先されます。例えば、time_series.parquet と steps.parquet(または .csv)を含むフォルダは正しく読み込まれます。PyBaMM モデルのサポート
モデルを名前で指定する代わりに、PyBaMM モデルオブジェクトを目的関数に直接渡すこともできます。設定を構築する際に自動的にシリアライズされるため、登録手順も文字列名の参照も必要ありません。完了待ち
raise_on_failure=False を指定します。
結果の取得
各要素は型付きの結果オブジェクトを返します。要素に付けた名前で取り出し、フィット済みパラメータを参照し、そのままプロットできます。OptimizationResult、PosteriorResult、ValidationResult など。いずれも BaseResults を基底とします)。そのため parameter_values、to_config()、各プロットはどの型でも同じように使えます。result.results は全要素を名前をキーとして返します。
プロットにはオプションの extra が必要です: pip install ionworks-schema[plot]
オーバーレイとオプティマイザトレースは結果オブジェクトの生成時ではなく、最初にアクセスした時点で取得されます。したがって
parameter_values の参照に追加のコストはかかりません。result.result、要素ごとの辞書は result.element_results で、キーは iws.Pipeline(elements=...) に渡したものと一致します。
要素のメタデータ
要素は大きなフィールド(たとえば検証の全点比較)をelement_results ではなくメタデータ blob に書き込みます。結果オブジェクトは必要な内容をそこから自動で読み取るため、blob を直接取得するのは結果オブジェクトが公開していないフィールドが必要な場合だけです。
データフィッティングのパラメータトレース
fit.plot_trace() がオプティマイザの反復ごとの進行状況を描画します。自分でプロットしたい場合は fit.trace が生のレコードを返します。スキーマは
パラメータトレースの取得を
参照してください。いずれも要素のジョブ ID は不要です(結果オブジェクトが解決します)。
データフィットのモデル vs データプロットデータ
上記のfit.plot_fit_results() で通常の用途は足ります。生のトレースが必要な場合 — 独自のプロット基盤に渡す、あるいはユーザーのズームに応じて詳細を再取得する場合 — は client.job.get_plot_data を使います。これはデータフィットジョブのモデル vs データのトレース、つまり Studio がフィット結果ページに描画するのと同じオーバーレイを返します。データフィットはベストフィットのパラメータで検証を再実行し、そのオーバーレイを自身のメタデータに保存するため、別の Validation 要素を追加したり、生のメタデータ blob を解析したりせずに、フィットのジョブ ID から直接取得できます。
このエンドポイントはジョブ ID をキーとします。ジョブ ID は要素一覧に含まれています。
max_points 点までダウンサンプリングされます(デフォルトは 2000、範囲は 100–80000)。ユーザーがズームインするたびにより詳細を再取得する セマンティックズーム を実装したい場合は、現在のビューポートに対応する x_min と x_max を渡します。
パイプライン一覧
単一送信の取得
SimplePipeline
SimplePipeline は、高コストな要素が最大 1 つ(単一の DataFit、ArrayDataFit、または Validation)のワークフロー向けの、Pipeline の軽量な代替手段です。ファイア・アンド・フォーゲット方式で実行され、parameter_values、cost、そして(検証の場合は)summary_stats を含むフラットな結果を返します。送信とポーリングは client.simple_pipeline を通じて行います。
設定の構築
SimplePipeline は Pipeline からすべてを継承し、高コストな要素を複数含む設定を拒否するクライアントサイドの検証を追加します。
複数の
DataFit、ArrayDataFit、または Validation 要素を渡すと、SimplePipeline は即座に ValueError を発生させます。サーバー側で拒否されるのを待つ必要はありません。送信とポーリング
client.pipeline.wait_for_completion と同様に、poll_interval(ポーリング間隔 [秒]、デフォルト 2)、verbose(ステータス出力、デフォルト True)、raise_on_failure(デフォルト True。False を指定すると、例外を発生させず失敗レスポンスを返します)も引数として受け付けます。実行が終端ステータス — completed、failed、canceled のいずれか — に達すると完了します。
client.simple_pipeline.create() は client.pipeline.create() と揃えられており、iws.SimplePipeline スキーマインスタンス、または .to_config() が返す dict のいずれも受け取れます。スキーマインスタンスを推奨します: 自分で .to_config() を呼び出す必要がなく、スキーマオブジェクトを構築した時点で形状エラーがローカルに表面化します。生の dict はそのまま送信されるため、不正な dict はサーバー側で HTTP 422 として初めて拒否されます。
一覧、フィルタリング、ソート
list は items、count、total を含むページ分割されたレスポンスを返します。文字列フィルタは、完全な値または ilike.%foo%(大文字小文字を区別しない部分一致)や in.(completed,failed)(集合のいずれかに一致)のような演算子プレフィックス付きの式を受け入れます。
実行オプション
シンプルパイプライン内の
data_fit 要素は、通常のパイプラインと同じ分散ワーカープールを使って並列に評価されます。追加の設定は不要です。通常どおり optimizer.population_size を設定すれば、サーバーが集団の評価をワーカー間に分散します。create に options 辞書を渡すことで、送信したパイプラインの実行時の挙動を制御できます。オプションは送信メタデータであり、サーバーがジョブをどのように実行するかに影響しますが、パイプライン設定の一部としては保存されません。
options(および project_id、name、description)は設定辞書に直接埋め込むこともできます。create は送信前にこれらを設定から取り出します。create に明示的に渡された引数は、設定内の値より優先されます。
更新、キャンセル、削除
エラー処理
検証パイプライン
SimplePipeline は単一の Validation 要素もサポートします。結果には parameter_values に加えて summary_stats が含まれます。
エンドツーエンドの例
より多くのエンドツーエンド例(エントリのみ、計算のみ、データフィット、検証)は SDK リポジトリの
packages/ionworks-api/examples/pipeline/ を参照してください。