WIP: feat(yaml): introduce INTERSTAGE process system type and PRESSURE_CON…#1453
WIP: feat(yaml): introduce INTERSTAGE process system type and PRESSURE_CON…#1453
Conversation
2f01beb to
507f040
Compare
| class YamlInterstageProcessSystem(YamlBase): | ||
| type: Literal["INTERSTAGE"] | ||
| name: ProcessSystemReference | ||
| items: list[YamlInterstageItem] = Field( | ||
| default_factory=list, | ||
| title="ITEMS", | ||
| description="Ordered list of choke, mixer, and splitter units at this interstage location.", | ||
| ) |
There was a problem hiding this comment.
Do we actually need this? Can we instead just have a list of units in addition to CompressorStages when setting up the train?
| type: Literal["SERIAL"] | ||
| name: ProcessSystemReference | ||
| items: list[YamlItem[YamlCompressorStageProcessSystem]] | ||
| items: list[YamlItem[YamlCompressorStageProcessSystem | YamlInterstageProcessSystem]] |
There was a problem hiding this comment.
| items: list[YamlItem[YamlCompressorStageProcessSystem | YamlInterstageProcessSystem]] | |
| items: list[YamlItem[YamlCompressorStageProcessSystem | YamlInterstageChoke | YamlInterstageSplitter | YamlInterstageMixer]] |
|
|
||
| class YamlProcessConstraints(YamlBase): | ||
| outlet_pressure: YamlExpressionType | None = Field( | ||
| discharge_pressure: YamlExpressionType | None = Field( |
There was a problem hiding this comment.
Should we use discharge instead of inlet? inlet/outlet seems to work for streams, is it different for pressure?
| title="DISCHARGE_PRESSURE", | ||
| description="Target discharge pressure [bara].", | ||
| ) | ||
| pressure_control: YamlPressureControl | None = Field( |
There was a problem hiding this comment.
Will constraint, anti-surge and pressure control always go hand-in-hand?
I think we also should consider introducing a type for constraint, maybe switch to a list. That gives us more flexibility in case we need to introduce different constraints.
If combining constraint and 'how to solve' like this we should also consider a different name than constraint
9fa2c2a to
043a36d
Compare
All types live in yaml_process_system.py. Topology types first,
simulation types after.
Process system topology (PROCESS_SYSTEMS):
- COMPRESSOR_STAGE: single compressor stage with inlet temperature
- PRESSURE_DROP: interstage pressure drop element
- MIXER: stream injection point (topology only, one mixer for each stream injected)
- SPLITTER: stream extraction point (topology only, one splitter for each stream extracted)
- SERIAL: ordered list of named item references; carries ANTI_SURGE
(INDIVIDUAL_ASV or COMMON_ASV, defaults to INDIVIDUAL_ASV)
Interstage types (PRESSURE_DROP, MIXER, SPLITTER) are new — they allow
expressing the legacy multiple streams compressor trains in the new Yaml
Process simulation (PROCESS_SIMULATIONS):
TARGETS: list of YamlSimulationTarget, each with:
- TARGET: reference to a SERIAL process system
- CONSTRAINTS: map of item name / train name -> YamlSegmentConstraint
(constraints carry both OUTLET_PRESSURE and PRESSURE_CONTROL and they allow expressing
the legacy multiple pressures compressor train in the new Yaml. Now also with more than
one interstage pressure)
- MIXER_STREAMS: map of mixer name -> inlet stream ref
- SPLITTER_RATES: map of splitter name -> extraction rate
STREAM_DISTRIBUTION: required; COMMON_STREAM or INDIVIDUAL_STREAMS
(both accept StreamRef | YamlInletStream)
Serial = 1 target, parallel = N targets — implicit from count.
Validators in YamlAsset (parse-time):
- Every simulation target must reference a known SERIAL process system
- Every train must have an outlet constraint (keyed by train name)
- Every MIXER in a train must have a MIXER_STREAMS entry per target
- Every SPLITTER in a train must have a SPLITTER_RATES entry per target
- Constraint keys must be item names in the train or the train name itself
- Constraints must appear in topological order (matching SERIAL.items)
- UPSTREAM_CHOKE only valid on the first constraint in topological order
- DOWNSTREAM_CHOKE only valid on the last constraint in topological order
043a36d to
08d553e
Compare
Context
The existing YAML supports a
MULTIPLE_STREAMS_AND_PRESSUREScompressor train type for trains where additional streams are injected or extracted between stages, and where intermediate pressures must be controlled. This type is separate fromCOMMON_SHAFTand requires its own set of fields and mapper logic.This PR is a design proposal for how the same physical concept — and more — can be expressed using the general
PROCESS_SYSTEMSstructure, without a dedicated train type.Approach
The key design principle is full separation of equipment and operation:
PROCESS_SYSTEMSdescribes physical topology — compressors, how they are connected, and what anti-surge equipment is installed. No streams, no rates, no targets.PROCESS_SIMULATIONSdescribes operational scenarios — what flows through the system, what pressure targets to hit, and how to achieve them.A serial compressor train with interstage elements is expressed as a
SERIALprocess system containing an ordered list of named items. Six item types are supported:COMPRESSOR_STAGEPRESSURE_DROPMIXERSPLITTERSERIALPARALLELAnti-surge equipment (
INDIVIDUAL_ASVorCOMMON_ASV) is declared on theSERIALtrain — it is physical equipment, not an operational choice. Defaults toINDIVIDUAL_ASV.Segment constraints
Intermediate pressure targets are expressed in a
CONSTRAINTSblock on the simulation, keyed by item name. Each entry defines a segment boundary: the solver resolves all items up to and including that item as one segment.Using the train name itself as a key targets the train outlet — independent of which stage happens to be last.
Each constraint requires:
OUTLET_PRESSURE: the pressure target [bara]PRESSURE_CONTROL(optional): defaults toDOWNSTREAM_CHOKEfor the train outlet,INDIVIDUAL_ASV_RATEfor intermediate segmentsConsistency between
PRESSURE_CONTROLand the train'sANTI_SURGEis validated at parse time.Validation
All cross-reference checks run at parse time in
YamlAsset, before any domain calculations:MIXERin the target train must have a stream inMIXER_STREAMSSPLITTERin the target train must have a rate inSPLITTER_RATESOUTLET_PRESSUREsetCOMMON_ASVpressure control requiresCOMMON_ASVon the trainBackward compatibility
A
SERIALtrain with a single constraint continues to use the existing solver path. Multi-constraint trains are resolved byMultiPressureSolver(separate work). No existing YAML is affected.Mapping from YAML to domain is separate work.
Example YAML