You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The pattern of "inertial pressure" calculated as difference between "pressure" and "steady pressure" from ThermoFluidStream library can be generalized even for chemical domain as a "inertial electro-chemical potential" and may be also for another domains.
The idea is to hide topology (e.g. implemented in ThermofluidStream.Topology.JunctionNM or in Chemical.Topology.JunctionNM https://github.com/MarekMatejak/Chemical/tree/ThermofluidStream ) behind keyword "inertial" in connector variable. These equations in case of "inertial" connector variable could be generated in similar way that "flow" or "stream" connector variable generates equations.
The goal of this should be to simplify definition of these kind of models for users, because they do not need to explicitly use splitters or junctions.
The text was updated successfully, but these errors were encountered:
Can you explain this in more detail? I don't fully understand this; is it "steady" as a fixed inertial frame of reference (like atmosphere pressure), or a possibly time-varying "steady-state" pressure?
Yes, this issue is definitely not a trivial thing. However, it could make Modelica much user friendly for these types of models. Should I prepare some initial materials for this issue?
The pattern of "inertial pressure" calculated as difference between "pressure" and "steady pressure" from ThermoFluidStream library can be generalized even for chemical domain as a "inertial electro-chemical potential" and may be also for another domains.
The idea is to hide topology (e.g. implemented in ThermofluidStream.Topology.JunctionNM or in Chemical.Topology.JunctionNM https://github.com/MarekMatejak/Chemical/tree/ThermofluidStream ) behind keyword "inertial" in connector variable. These equations in case of "inertial" connector variable could be generated in similar way that "flow" or "stream" connector variable generates equations.
The goal of this should be to simplify definition of these kind of models for users, because they do not need to explicitly use splitters or junctions.
The text was updated successfully, but these errors were encountered: