fmi-standard
fmi-standard copied to clipboard
modelica
Missing fluid interface
Reported by anonymous on 18 Dec 2015 15:04 UTC Dear Sir or Madam,
using FMI for co-simulation of fluid systems requires both a fluid library within the master software and a fluid library within the slave software. Hence, it must be ensured, that the libraries are identical.
Proposal for solution: FMI should also describe an interface to the fluid library used in the master software in order to provide access to the same fluid library. Then, no fluid library within the FMU will be required.
Use case: Two fluid circuits should be simulated which are connected by a heat exchanger. One fluid circuit is modeled as a closed loop including the heat exchanger. Since the heat exchanger model should not be separated, the heat exchanger's other fluid side is also modeled with this fluid circuit. Because of this, the other fluid circuit is modeled as an open loop. Assumed that fluid A flows in the open loop and fluid B in the closed loop, the closed loop model contains fluid A and fluid B, whereas the open loop model just contains fluid A. If one of the fluid circuit models is put into an FMU, fluid A will be used inside the FMU and outside the FMU. Then, access to the same fluid library should be provided.
Migrated-From: https://trac.fmi-standard.org/ticket/363
Comment by andreas.nicolai on 4 Jan 2016 08:12 UTC The problem of ensuring matching library/module functionality and meaningful and matching input/output variables is in my opinion a task for the physical model and interface developer and shall be done specifically for each physical domain. I believe this is not a matter of the FMI standard.
Comment by Edo on 20 Dec 2017 16:35 UTC Indeed, I am the opinion that it is extremely important to keep the FMI specification tool and domain agnostic. Furthermore, if you actually split the heat exchanger such that only heat transfer (conduction) takes place you omit the problem implicitly. Conduction actually has robust energy preserving non-iterative co-sim support, where as convection (fluid flow over the co-sim interface) does not seem to have this.
Comment by cbertsch on 1 Jun 2018 14:31 UTC Is this covered by FCP_005 Services (which is not on the FMI 3.0 feature list)?
FMI Regular Design meeting: Klaus: there exist "Hacks" that pass function pointers to media libraries
I think that this is an issue of the fluid property library and not an issue of the FMI. There is not "the one and only" interface to fluid libraries. The fluid library needs to be defined independently, and this strongly depends on the use cases (Process industry, HVAC, thermal stress simulation of metal, gas tubing, partially freezing fluids, heatexchanger icing...).
I could recommend the C-Interface of our fluid library TILMedia... For our use cases we solved this problem, because we defined the C-Interface of the dll and the interface to Modelica (to create FMUs which link the library). We have different long term use cases where the dll is loaded by the master in advance and shared with the FMU.
there exist "Hacks" that pass function pointers to media libraries
Could one use a binary input or parameter to do something like this in a cleaner way in FMI 3.x than the hacks in FMI 2.0? Naively, by defining something like a "function pointer MIME type"? Or could one use intermediateUpdateMode in CS FMUs to exchange fluid property information between FMU and importer? Or would we still need something like FCP_005 Services to realize a fluid interface?
Generally, defining a fluid interface should be a layered standard, but the FMI interface should provide means to realize this.
