SimplePipeline runs a workflow with at most one expensive element, meaning a single DataFit, ArrayDataFit, or Validation, and returns a flat result containing parameter_values, cost, and optional summary_stats. A regular Pipeline takes the same elements and covers the same case, so there is no longer a reason to start with SimplePipeline.
How it compares to Pipeline
A
Pipeline’s data fit also stores its own model-vs-data overlay, so you can plot a fit without adding a separate Validation element.
How it works
This describes existingSimplePipeline runs. A SimplePipeline follows the same three conceptual steps as a full pipeline, just with a single expensive element and a flatter result:
- Build a typed config.
SimplePipelineinherits everything fromPipeline, so you compose the same element types (aDirectEntryfor known values plus oneDataFit,ArrayDataFit, orValidation). It adds client-side validation that rejects configs with more than one expensive element. The error is raised immediately when you build it, so you never wait on a server-side rejection to find out. - Submit fire-and-forget. The config is sent to Ionworks, which runs it in the background. Because there is at most one expensive element, there is no per-element status to track. You just wait for the whole job to finish.
- Read a flat result. A fit returns
parameter_valuesandcost; a validation additionally returnssummary_stats. There is no cumulative parameter threading to unpack, because everything is at the top level of the result.
Migrating to Pipeline
Because the elements are the same, migrating means swappingiws.SimplePipeline for iws.Pipeline, client.simple_pipeline for client.pipeline, and reading results by element name. The method-by-method mapping, a before/after example, and the remaining SimplePipeline reference for code that has not migrated yet are in the Documentation tab:
Migrating to Pipeline
Map each
client.simple_pipeline call to its client.pipeline equivalent and read results by element name.