Towards version 4.0.0

[casella]

The ThermoPower library has lived for many years in a limbo where it was still needing MSL 3.2.3, but also needing some long overdue non-backward compatible improvements. Some of them required advanced GUI support that was not available in OpenModelica, but now is. There were no official releases, we always suggested people to use the latest version on master, that we strived to keep 100% backwards compatible. There were also some pull requests with suggestions to improve the library, but they would have required a bit more discussion to be merged onto master and the opportunity to do so never came.

Now, the original plan was to try to maintain backwards compatibility as much as possible, but after some discussion with @AndreaBartolini we came to the conclusion that after 20 years it's time to give up backwards compatibility to fix the library where it is needed. So, the idea is to seize the opportunity for these non-backwards compatible changes and couple them to the switch to MSL 4.0.0. In fact, we can actually switch to MSL 4.1.0, since the new library has already been out for a while.

So, the current plan is to work on the v4.0.0-dev branch, implementing the following changes/improvements:

• Change used(Modelica) annotation to 4.0.0, change SI import statement, and that should be enough, check
• Make the pressure loss model of Flow1DXX replaceable, similarly to what is suggested in PR Computation of friction coefficient by replaceable model #21, but without keeping backwards compatibility with the old embedded pressure loss models; the idea is to only use the replaceable model mechanism to specify the pressure loss model.
• Remove the PowerPlants package, which is still partially broken and in need of conversion to the new Flow1DFV models. This may be recovered as a separate library in the future
• Rename the Gas package as IdealGas and the Water package as FluidPh, to better reflect the scope of the contained components
  • IdealGas contains components that assume ideal gas fluid a priori, hence dh/dp|T == 0, and use p,T, X as states
  • FluidPh contains components that use a generic fluid with p,h as states, possibly undergoing phase transition. The default will still be IF97 water, but other fluids can be used, such as organic fluids, high-pressure CO2, cryogenic hydrogen, etc.
• Deprecated components will be removed
• For source components, use_in_T and use_in_h will be managed as "radio buttons" by using the enable annotation
• Default start values for liquid, two-phase and vapour enthalpy in Flow1Dxx components, which are currently hard-wired as 1e6, 2e6 and 3e6 J/kg, will become parametric, based on pstart and the specific fluid used, and some subcooling/superheating (e.g. 50 degC, possibly computed with a conventional cp value, e.g. 1000 J/kgK, so +/- 100 kJ/kg)

[AndreaBartolini]

@casella some examples in ThermoPower.Test.DistributedParameterComponents use deprecated components, we have to check them one by one.

[casella]

OK.

[AndreaBartolini]

@casella regarding the second point (Make the pressure loss model of Flow1DXX replaceable),

taking into account that:

• the structure of the friction factor is different in the following cases:
  • Kf and Cf are scalar in 1DFV
  • Kf and Cf have dimension N-1 in 1DFV2ph
  • Kf and Cf have dimension N in 1DFEM and 1DFEN2ph
• Some friction factor calculation are not available in some cases (like Colebrook or Knom in FEM2ph)

we can follow two different approaches:

1. we can define a general base interface in which the returned Kf and Cf are vectors (like done in the PR above cited), in this case:
   • is responsibility of each Flow1Dxxx model to use the interface according to its structure,
   • is responsibility of the user to properly select the right friction model according to the type of the Flow1Dxxx that is used,
2. we can define four base interfaces: 1DFV, 1DFV2ph, 1DFEM, 1DFEM2ph, each one with the right structure of Kf and Cf, in this case:
   • each Flow1Dxxx type has a specific interface to be used,
   • the specific interface can be used as constraining type so that the user may only select the friction model according to the type of the Flow1Dxxx that is used.

In my opinion the second approach is more robust.

Moreover, if we use the second approach we can follow two different rules in order to identify the Flow1Dxxx type associated to each friction model:
a) name based rule, like NullFriction1DFV, NulFriction1DFV2ph and so on ...
b) sub-packages based rule (one sub-package for the 1DFV models, one for the 1DFV2ph models and so on ...)

Personally I prefer the sub-packages based rule.

Please give me a feedback ...