Redesign flashtank

[pierre-eliep-met]

Goal

Work to fix #113 by redesigning the flash tank, using a partial volume instead.

Type of change

• [x] Bugfix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Release & Version Update (when cumulative changes justify a release)
• [ ] Documentation Update

Checklist

You can also fill these out after creating the PR, but make sure to check them all before submitting your PR for review.

• [x] I have added the appropriate tags, reviewers, projects and linked issues to this PR
• [ ] I have performed a self-review of my own code
• [ ] Existing tests pass.
• [ ] I have added/updated tests that prove my development works and does not break anything.
• [ ] I have made corresponding changes or additions to the documentation
• [ ] I have added corresponding entries to the Changelog
• [ ] I have checked for conflicts with target branch, and merged/rebased in consequence

[pierre-eliep-met]

I have some problems with this change :

• Metroscopia_NPP_reverse does not simulate, while it does on main branch
• Local balance :
  • If I don't impose C_in.h_outflow = 0 in the PartialVolume, my component is locally balanced, but I get warning that this connector is removed because not used in simulation, and after Metroscopia is not locally balanced
  • If I impose C_in.h_outflow = 0 to explicitly state that the C_in is an inlet port, and to get metroscopia balanced, my flash tank model is not locally balanced

@casella and @AndreaBartolini do you have an idea of what I should do to fix that ?

[AndreaBartolini]

Hi, I need some clarifications regarding the PhaseSeparationVolume model:

1. in the base model it seems that the input contribution is missing in the energy balance, I would have expected something like this: Q_in*inStream(C_in.h_outflow) + C_steam_out.Q *C_steam_out.h_outflow + C_liquid_out.Q *C_liquid_out.h_outflow = 0

Note that this is valid because the flow directions are fixed "at priori", otherwise the actualStream() operator should be considered...

2. When you fix the x_steam_out = 1 in the extended model what is the result that you want to obtain (i.e., what is the variable that should be back-calculated by fixing the output steam mass fraction). It seems to me that this equation is an overconstraint for the model (maybe the idea is to give the possibility to fix it from the top level...).

[AndreaBartolini]

  * If I don't impose `C_in.h_outflow = 0` in the `PartialVolume`...

When you use the stream connectors the stream variable shall be always assigned by the component that instantiate the connector, also if it is never used because the flow direction is fixed "at priori".

[casella]

@pepmts regarding the balancedness, MetroscopeModelingLibrary.Partial.Volumes.PhaseSeparationVolume is not partial at all: if you connect the inlet to a source flow model, the steam outlet to a pressure sink model, and the liquid outlet to a sink flow model, the volume model is closed and is able to compute all of its variables, including x_steam_out. There are no degrees of freedom left. If you want to fix the steam quality on the steam outlet, you need to "free" one degree of freedom in the system (not in the component itself, because it has no inputs that you can leave unconnected).

For example, you could put a pump model on the liquid outlet, leave the rotational speed input unconnected (+1 d.o.f.) and add one equation to set x_steam_out = 1, so the overall system will remain balanced.

[pierre-eliep-met]

Hello, sorry for the late response !

in the base model it seems that the input contribution is missing in the energy balance

Agreed, I added it, @AndreaBartolini

PhaseSeparationVolume is not partial at all

I agree it is not, and that is my main concern, it should, since we should have x_steam_out as a degree of freedom... I've tried to investigate using the elements from the article you had pointed in https://github.com/Metroscope-dev/metroscope-modeling-library/issues/99#issuecomment-1270737037, but could not figure out the issue...

Just to recall I did this new component because we had discussed a while ago on the fact that the FlashTank was not locally balanced, and you advised to create a component with only three connectors and no connections between them, but now it seems that I am back to the initial problem, though the model is much simpler. I would want PhaseSeparationVolume to adapt to the imposed x_steam_out, but I don't understand what should be removed from the model. Furthermore, I tried to connect PhaseSeparationVolume to a source and two sinks and it had missing equation, but could simulate when I added x_steam_out=1, which is even weirder to me...

[AndreaBartolini]

Furthermore, I tried to connect PhaseSeparationVolume to a source and two sinks and it had missing equation, but could simulate when I added x_steam_out=1, which is even weirder to me...

This is exactly the point. The PhaseSeparationVolume is not partial itself (i.e., it has no degree of freedom) but the overall model that instantiates the PhaseSeparationVolume should introduce the degree of freedom you need to prescribe the x_steam_out.

My opinion is that the PhaseSeparationVolume model should be moved to the MetroscopeModelingLibrary.WaterSteam.Volumes package, and the specific scenario that use it (i.e. the top-level model that instantiates it) will define the proper degree of freedom.

An additional note: in the energy balance

Q_in` * inStream(C_in.h_outflow) + C_steam_out.Q * C_steam_out.h_outflow = C_liquid_out.Q * C_liquid_out.h_outflow;

it seems to me that the term

C_liquid_out.Q * C_liquid_out.h_outflow;

should be placed in the left side of the balance... (both C_steam_out.Q and C_liquid_out.Q should be negative...)

Q_in` * inStream(C_in.h_outflow) + C_steam_out.Q * C_steam_out.h_outflow + C_liquid_out.Q * C_liquid_out.h_outflow = 0;

[pierre-eliep-met]

I completely agree on the second point, it was a mistake

[pierre-eliep-met]

To me it seems really weird that this model is globally balanced (since it has no inputs nor connector inputs) but that we can specify x_steam_out from an outer model... Isn't it ?

[AndreaBartolini]

the model is balanced because it has the same number of equations and variables (14) were: variables are:

• P, Q, h_outflow for each connector (3 connectors --> 9 var)
• internal pressure P (1 var)
• inlet flow Q_in (1 var)
• saturation enthalpies h_vap_sat and h_liq_sat (2 var)
• steam mass fraction at steam outlet x_steam_out (1 var)

equations are:

• alias assignement (1 eq)

Q_in = C_in.Q;

• isobaric system (3 eq)

P = C_in.P;
C_steam_out.P = P;
C_liquid_out.P = P;

• saturation enthalpies (2 eq)

h_vap_sat = WaterSteamMedium.dewEnthalpy(WaterSteamMedium.setSat_p(P));
h_liq_sat = WaterSteamMedium.bubbleEnthalpy(WaterSteamMedium.setSat_p(P));

• h_outflow assignements (3 eq)

C_in.h_outflow = 0;
C_steam_out.h_outflow = x_steam_out * h_vap_sat + (1-x_steam_out)*h_liq_sat;
C_liquid_out.h_outflow = h_liq_sat;

• balances (2 eq)

Q_in + C_steam_out.Q + C_liquid_out.Q = 0;
Q_in * inStream(C_in.h_outflow) + C_steam_out.Q * C_steam_out.h_outflow + C_liquid_out.Q * C_liquid_out.h_outflow = 0;

• flow balances at connectors (sum(Q)=0 for each connector) (3 eq)

So the local model is balanced but the overall model has four degree of freedom between: Qin, Qout_liquid, Qout_steam, isobaric P, x_steam_out. Suppose that you connect a source that prescribes the Qin, one sink that prescribes the Qout_liquid and another sink that prescribes the Qout_steam. You can then decide to prescribe the x_steam_out so that the overall model calculates the pressure P necessary to produce that steam fraction or you can prescribe the pressure P and the overall model will calculates the produced x_steam_out.

By the same way you can in general prescribe four of the above listed degree of freedom and the overall model will calculate the fifth.

[AndreaBartolini]

To me it seems really weird that this model is globally balanced (since it has no inputs nor connector inputs) but that we can specify x_steam_out from an outer model... Isn't it ?

BTW, you can prescribe the x_steam_out outside the model because it is public, and you can do this only by using an external equation because x_steam_out is not an input.

[AndreaBartolini]

we will better discuss this matter in the next follow-up meeting

[pierre-eliep-met]

The current state is that the Flash tank is really locally balanced but then the steam dryer is not, because we need to fix the x_steam_out, so we have to free somehing, like the liquid flow rate, but there is no direct way to do that at the moment