0% found this document useful (0 votes)
16 views7 pages

Dynamic Flow Solver in Mimic Simulation

The document discusses Mimic's two dynamic flow solvers: the Node Solver and the Pressure Flow Solver. The Node Solver uses an iterative, sequential method to calculate flows and pressures between objects, while the Pressure Flow Solver calculates pressures and flows simultaneously across the entire model. Both solvers automatically balance flows. The Pressure Flow Solver generally provides a smoother transient response but requires more computational resources. Model boundaries are handled differently by the two solvers, which can impact the dynamic response.

Uploaded by

Harikrishnan L
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views7 pages

Dynamic Flow Solver in Mimic Simulation

The document discusses Mimic's two dynamic flow solvers: the Node Solver and the Pressure Flow Solver. The Node Solver uses an iterative, sequential method to calculate flows and pressures between objects, while the Pressure Flow Solver calculates pressures and flows simultaneously across the entire model. Both solvers automatically balance flows. The Pressure Flow Solver generally provides a smoother transient response but requires more computational resources. Model boundaries are handled differently by the two solvers, which can impact the dynamic response.

Uploaded by

Harikrishnan L
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Open topic with navigation

Dynamic Flow Solver


Mimic uses pressure difference and piping characteristics to dynamically calculate the
material transfer when using Advanced Modeling Objects. There are two dynamic flow
solvers, Node Solver and Pressure Flow Solver. The default solver (Node Solver or NS)
uses a sequential and iterative method to calculate flows and pressures. Alternatively, the
dynamic Pressure Flow Solver (PFS) calculates pressures and flows simultaneously. Both
solvers automatically balance and coordinate the flow between passive and active objects
using the selected flow model.

Selection of the flow solver is done when configuring the model in the Properties menu of
Simulation Studio. The solver calculates the flow for passive nodes such as the Stream Tee
objects and coordinates flow for active nodes such as the Valve or Pump objects. The
dynamic flow solver may require user intervention to configure or tune to balance the flows
from object to object. The tuning required depends on the selected flow model (Velocity
Head Loss Coefficient or MiMiC Cv).

The number of the MiMiC models using either NS or PFS is limited only by the intended
extent of advanced simulation and computational resources of the simulator machine. This
methodology provides flexibility in model fidelity level selection by combining in one
simulation the model segments that need the advanced objects and PFS with more simple
segments that need just basic balance simulations.

Selected solvers are specific for each model, i.e., one model may use the default NS while
another may use the PFS. Flows from one model to the next are handled by the use of
SIP/SOP object pairs. A SOP is a stream output object located in a source model. A SIP is a
stream input object located in a destination model and references the SOP object in the
source model. Standard models (non-object based models) using the Thermo Source block
and SOP block as a pressure/flow source for Advanced Models must be connected to a
model using the default Node Solver.

Figure 1 - Flow network of MiMiC Advanced Modeling Objects using MiMiC Dynamic Flow
Solver
Pressure Flow Solver
In the Pressure Flow Solver (PFS) the process flow sheet (i.e., a model) is considered as a
local flow network that includes the Nodes and Transport Units, connecting these nodes.
The advanced objects of the simulation flow sheet are mapped to the flow network as shown
in Figure 2.

Figure 2 - Pressure Flow Network

The nodes of the flow network are defined as Active and Passive nodes. The active nodes
include the accumulation objects that have their own models for the pressure calculation
(such as Separator and Vessel objects, containing the vapor holdup, the Distillation Column
objects). The active nodes include also the compressors and pumps that calculate head and
outlet pressures depending on its state (ON/OFF) and flow demand at the outlet of this unit.
The passive nodes include the Stream Tee objects, serving for connections (junction and
branching of the streams) of the advanced unit operations.

In Figure 2, P1, P3, P5, and P6 are all active nodes. P2 and P4 are stream tees. C12, C23, C24,
C45, and C46 all represent paths between nodes with a given flow resistance. Figure 3 shows
an example model that might result in the network in Figure 2.

Figure 3 - Pressure Flow Network Example Model

The transport units are the directed edges of the flow network graph. The PFS uses the
transport units for calculation of the pressure values at the passive nodes and flow rates
between the nodes. The transport units include the Stream object with parameters specified
based on selected flow methodology (represents the pipe segment, connecting two nodes)
and/or the combination of two Stream objects and Valve object, representing the serial
connection Stream - Valve – Stream.

PF Solver Mode
PFS contains two methods to handle the boundaries between models. The first, Single-
Model, handles each model independently, assuming that the pressure on the other side of
a SIP/SOP pair is constant for a given model scan. This can cause unintended transient
behavior when the flow rate or pressure is rapidly changing between two models. The
second mode, Dependency Based, will ignore model boundaries for the purposes of defining
the network. It will use active nodes (except for pumps and compressors) as the boundaries
between the flow networks. This normally provides smoother transient behavior when
crossing a model boundary.

Note: It is suggested that Dependency Based mode for PF Solver is used for
new simulations. Single-Model mode should normally only be used for
completed simulations, to preserve their behavior from previous version of
Mimic.

Node Solver
Node solver uses the object execution order to walk through all the objects in a model,
determining the flow rates for all streams entering and leaving the object. Node solver is
iterative in that, executing one object causes connected objects to execute. When the object
finishes, it moves on to the next object, which may have already been executed. The solver
will execute it again, but since it is already executed, it does not have to iterate as much to
resolve. This continues until all objects are executed.

The node solver ignores model boundaries. If it is tracing a path between objects and
encounters a SIP/SOP pair, it will continue to the next model, looking for either a holdup
block, or a block that calculates its pressure from the flow (such as a Pump or Stream Tee).
If a SIP/SOP pair leads to a model using Pressure-Flow solver, the network tracer stops and
uses the pressure in the SIP as if it were constant for this model scan.

When using the default Node Solver each model is limited to a maximum of five Stream Tee
objects. If more than five are used, execution slippage may occur. Dynamic Pressure Flow
Solver is recommended if more than five Stream Tee objects are required in the model.
Selecting a Flow Solver
Both flow solvers will result in the same steady state flow values for a given situation, since
they use the same flow equations. The main differences between them are the transient flow
response, CPU time required each scan, and how the boundaries between models
(SIP/SOP pairs) are handled.

Transient Flow Response


In general, Node Solver has a steeper rate of change in the flow rate, given the same
pressure differences, when compared to the Pressure Flow Solver. This is mostly due to the
way that the objects are recalculated multiple times per model scan, and that the Node
Solver will ignore model boundaries when locating a flow path. The Pressure Flow Solver
generally results in a slower rate of change in the flow, especially around model boundaries
(SIP/SOP pairs) and fluid movers (pump and compressor).

CPU Time Per Scan


In this category, the Pressure Flow Solver is better than the Node Solver; it generally
requires less CPU time per model scan to solve the same flow network. The Node Solver
can potentially waste time re-executing objects that do not need it. This category should only
be a concern when the model is stressing the hardware, or when future model expansion is
expected.

Model Boundary Handling


This category is related to the transient flow response, but it deserves special mention. The
Node Solver will essentially ignore model boundaries while executing. This causes the flow
network in one model to respond to changes (i.e., valve position changes) in other models
after fewer modeling scans. The Pressure Flow Solver (single-model mode) treats SIPs and
SOPs in a given model as a constant pressure for a given scan. The two solvers are
basically identical when there are holdup objects, such as the Vessel, on either side of a
SIP/SOP pair. If, however, there is a pump connected to a SOP, which, in another model is
then connected to a valve, then a vessel (Figure 4), the dynamic behavior of the two solvers
becomes different.
Figure 4 - Model Boundary example

In this situation, the steady state flow rate will be similar, but the transient flow through the
pump after a state change, such as changing the valve position, will vary greatly between
the two flow solvers. The Node Solver will return to steady state in fewer model scans when
compared to the Pressure Flow Solver (single-model mode). Inside a single model scan the
Node Solver will recalculate the pressure of the SIP/SOP multiple times, while the Pressure
Flow solver (single-model mode) will only re-evaluate the SIP/SOP pressure once per model
scan. If the pressure did not change drastically, then both solvers should have similar
dynamic responses. Pressure Flow solver (Dependency Based mode) solves this problem in
a similar manner to the Node Solver; it ignores the SIP/SOP model boundaries for the
purpose of defining the edges of the flow network. See PF Solver Mode for more
information.

This difference between the solvers can be mitigated with careful model boundary
placement. For similar behavior, model boundaries should be placed such that a holdup
block (i.e., Vessel) is just before a SOP, or right after the SIP. This will smooth the pressure
change in both networks, reducing the differences between the dynamic responses of the
solvers.

Interaction with Solids


Some of the objects that are built to interact with solids, such as the conveyor or bin, behave
differently in the dynamic flow solver than object built to interact with vapors and liquids,
such as the vessel and valve. The solid objects calculate the outlet stream flow rates from
internal state, instead of following the dynamic flow solver. For example, the conveyor object
calculates the END_OUT flow rate from the mass on the belt and the current speed.

Because the solid objects calculate their own outlet flow rates care must be taken to
maintain balance in the overall system.
Solid Object Inlet Streams
Solid objects must accept mass from objects that have the dynamic flow solver calculate
their outlet flow rates. Because of this they must have a pressure. Many of the solid objects
are open to atmosphere, and will therefore use atmospheric pressure (101.325 kPa) as the
downstream pressure. If the object has a different pressure, it will be noted in the
documentation of that stream on the object.

These inlets almost always behave similar to advanced sinks in that they always allow flow.
Another way to say it is that inlet mass flow will never be rejected due to a "full" condition in
the solids object. The difference from the advanced sink is that the mass is not lost from the
system, it is transferred to the solids object. If the inlet mass cannot be contained in the
solids object, it will be diverted to a SPILLAGE (or similarly named) stream. If the spillage
stream is not handled, the material will be lost from the system.

Solid Object Outlet Streams


The most significant deviation for solid objects from the liquid-vapor objects is that their
outlet stream flow rates are almost always calculated from internal state and not based on
the downstream object's pressure or storage capacity. The most dramatic example is the
bin. The outlet flow rates are determined by a block reference to a standard model. Care
must be taken with these outlet streams to prevent invalidation of the overall system mass
balance.

Lets use two examples to illustrate the potential. The vessel is considered to be a liquid-
vapor object, even though it supports solids in its holdup. The bin is a solid object because it
performs layering of the incoming solid mass, something liquid-vapor holdup objects do not
perform.

Figure 5 - Vessel to Vessel example

Figure 5 shows a vessel connected to another vessel. The dynamic flow solver is calculating
the flow rate on the stream leaving VSL1. It uses the pressure change, elevation change and
the resistance of the stream, as defined by the selected flow model, to calculate the material
transfer rate. If the object reaches a condition where VSL1 has insufficient material to
sustain the calculated flow rate, the dynamic flow solver will reduce the flow rate to avoid
creating mass.

Suppose VSL1 contains a liquid. If VSL2 has insufficient volume to contain the new material,
the dynamic flow solver will reduce the flow rate to maintain mass balance. If VSL2 is full (or
too high a pressure), the dynamic flow solver will completely stop the flow. This "bi-
directional state communication" is a part of all liquid-vapor object in the dynamic flow solver.
Figure 6 - Bin to Vessel example

Figure 6 shows a bin outlet stream connected to an inlet of a vessel. In the bin configuration,
a block reference is defined for the flow rate leaving S_OUT_1. The stream will flow this
amount regardless of the condition of VSL3. The flow rate is not determined by the dynamic
flow solver. If BIN1 does not contain sufficient mass for the specified flow rate, it will reduce
the flow rate, maintaining balance inside the bin object. If VSL3 does not have sufficient
empty volume to contain the flow from BIN1, the excess material will disappear from the
model, thus invalidating the system mass balance.

It is possible that this mass loss is in accordance with the real process. Perhaps VSL3 is
open to atmosphere as well, and the material would naturally be lost to the plant floor. In this
case, the object behavior is correct. If VSL3 is sealed, then the pressure should have been
sufficient to stop the mass flow. This case will need to be handled in the model that
calculates the flow leaving BIN1.

Another side effect of this behavior is that most solid objects need to output into objects with
holdup. The capacity of the downstream blocks needs to be large enough that the standard
models setting the flow rate have sufficient model scans to react to changes in the
downstream.

Solids object outlet streams have the ability to flow material even when they are not
connected to a downstream object. In Figure 6, S_OUT_1 on VSL3 will never flow material,
because it is not connected. If S_OUT_1 on BIN1 had not been connected to VSL3, and the
block reference had a non-zero flow rate, material would leave the bin, effectively flowing to
an advanced sink that does not exist in the model. This behavior is used extensively for the
SPILLAGE and OVERFLOW type streams, where excess inlet material cannot be stored in
the solids object.

Outlet streams that are not connected display the flow rate in engine units (kg/s). This unit
can only be changed by attaching the stream to the inlet of another block and configuring the
units of the stream.

You might also like