Opened 5 years ago

Last modified 5 years ago

#5683 new defect

Mediums in fluid systems require explicit redeclare in OMEdit

Reported by: anonymous Owned by: somebody
Priority: normal Milestone: Future
Component: *unknown* Version: v1.14.0-dev-nightly
Keywords: Fluid, Medium Cc: adrpo, perost

Description

Fluid components across many libraries (Modelica.Fluid, BuildSysPro.IBPSA.Fluid, OpenHydraulics.Fluids) all require adding "redeclare package Medium = Medium" (where the second "Medium" is the name of the medium you want to that component to have flowing through it.

It seems, since fluid models already require adding a "system" component and most models will be based around a single fluid, that the components should default to a Medium that is defined by either the system block or by naming a specific medium to "Medium" in order to invoke it as the default.

Writing this I realize that this may in fact be an issue with the language of Modelica and not with OMEdit but not entirely sure.

Change History (4)

comment:1 Changed 5 years ago by casella

  • Cc adrpo perost added

This would be indeed very useful in a number of applications. I understand what you'd like to do is something like this:

model System
  replaceable package Medium = Modelica.Media.Interfaces.PartialMedium;
end System;

model MyComponent
  outer System system;
  package Medium = system.Medium;
end MyComponent;

Unfortunately this cannot be done with the current lookup rules of the Modelica Specification. If you check Section 5.3.2, you read

For a composite name of the form A.B or A.B.C , etc. lookup is performed as follows:

  • The first identifier ( A ) is looked up as defined above.
  • If the first identifier denotes a component, the rest of the name (e.g., B or B.C ) is looked up among the declared named component elements of the component.
  • If not found, and if the first identifier denotes a scalar component, or component[j] where component is an array of components and the indices j can be evaluated at translation time and component[j] is a scalar; and if the composite name is used as a function call, the lookup is also performed among the declared named class elements of the scalar component, and must find a non-operator function. All identifiers of the rest of the name (e.g., B and B.C] must be classes.
  • If the identifier denotes a class, that class is temporarily flattened (as if instantiating a component without modifiers of this class, see Section 7.2.2) and using the enclosing classes of the denoted class. The rest of the name (e.g., B or B.C ] is looked up among the declared named elements of the temporary flattened class. If the class does not satisfy the requirements for a package, the lookup is restricted to encapsulated elements only. The class we look inside may not be partial in a simulation model.

In this case we have to look up system.Medium. system is defined directly in the scope of the class, and is a component (not a class). Then, you look up Medium among the declared named component elements of system, but you don't find it as such, because Medium is a class, not a component. The only other chance you have now is that the composite name is used as a function call, like world.gravity in the MultiBody library.

If you are interested, we can open an issue on the Modelica Specification github repository and start the process to change the standard to allow this. It won't be fast, but it's doable.

@adrpo, @perost, can you also comment on that?

comment:2 Changed 5 years ago by anonymous

That explanation makes sense.

I feel like such a capability would be quite helpful because having to write in "redeclare package Medium = Medium" on every single component in a fluid model even if it only uses a single medium is a bit tedious. But I also get that there are probably more important changes to work on so you should decide whether it is worth opening a ticket or not.

Thanks for the quick response.

comment:3 follow-up: Changed 5 years ago by Christoph Buchner <buchner@…>

I don't remember specifics, but I think there was once a discussion about having the Medium choice automatically propagate from one component to others that are connected to it, by some clever design or connector tweaking?
Also, could the OP's goal also be achieved by using the inner/outer mechanism? I.e. define a medium outside, and all Fluid components use that automatically? I don't know off the top of my head how to enable more than one fluid in this setting, though.

comment:4 in reply to: ↑ 3 Changed 5 years ago by casella

Replying to Christoph Buchner <buchner@…>:

I don't remember specifics, but I think there was once a discussion about having the Medium choice automatically propagate from one component to others that are connected to it, by some clever design or connector tweaking?

There were lots of talks several years ago about type inference for automatic medium propagation, but the thing never really got off the ground: people were looking for general and comprehensive solutions, and there was never enough consensus on any specific mechanism.

We could of course restart the discussion, if there is enough interest in the community.

Also, could the OP's goal also be achieved by using the inner/outer mechanism? I.e. define a medium outside, and all Fluid components use that automatically? I don't know off the top of my head how to enable more than one fluid in this setting, though.

If the restriction mentioned above was lifted, you could define as many media as you wanted, for example Refrigerant and Air for AC systems or Steam and FlueGas for steam power plants.

Note: See TracTickets for help on using tickets.