Power connectors are not locally balanced because they only contain one flow variable : W

[pierre-eliep-met]

Connectors should have the same number of flow and other normal variables, how should we handle this in MML3 ?

[AndreaBartolini]

With reference to the Modelica Spec. 9.3.1:
For each non-partial non-expandable connector class the number of flow variables shall be equal to the number of variables that are neither parameter, constant, input, output, stream nor flow.

The only way to satisfy this requirement in MML3 is to add a "dummy" effort variable in both the power Inlet and Outlet connectors (e.g., Real NotUsed "not used effort variable to balance the connector"). For each connection-set that involves power connectors the value of the dummy variable must be written by one and only one component

Looking at MML3 I saw that the all the connection-set that involve power connectors contain one and only one Inlet connector, so the dummy variable could be written by the components that have a power input connector (e.g. the Generator). This can be done for example by adding a bounding equation where the connector is instantiated:

MetroscopeModelingLibrary.Power.Connectors.Inlet C_in(NotUsed = 0);

This solve also #100 and #118

[pierre-eliep-met]

Thanks for the clarification.
I've tested the solution that you propose, but here are the issues I've encountered :

Since the NotUsed = 0 binding equation can only be defined once per connection, some components cannot be locally balanced. For instance, we have the Power.Source and Power.Sink components, which respectively have only one outlet and one inlet. But we cannot define the binding equation NotUsed = 0 in both component, because otherwise we could not connect a source to a sink...

[pierre-eliep-met]

I defined a connector input in the Source component as a workaround to keep Power.Source locally balanced. Does it seem suitable to you ? See #278 for the modifications I've proposed to fix the problem

[AndreaBartolini]

Thanks for the clarification. I've tested the solution that you propose, but here are the issues I've encountered :

Since the NotUsed = 0 binding equation can only be defined once per connection, some components cannot be locally balanced. For instance, we have the Power.Source and Power.Sink components, which respectively have only one outlet and one inlet. But we cannot define the binding equation NotUsed = 0 in both component, because otherwise we could not connect a source to a sink...

The idea is that only the component that have an "inlet" connector should also have the binding equation, so in this case only the "sink" component.

[AndreaBartolini]

I defined a connector input in the Source component as a workaround to keep Power.Source locally balanced. Does it seem suitable to you ? See #278 for the modifications I've proposed to fix the problem

This should be not necessary, the point is that only the Connectors.Inlet instances should have the binding equation. In your commits the binding equation is also present in the case of Connectors.Outlet instances. These binding equations should be removed.

[AndreaBartolini]

Consider also that the model should be balanced itself (not only their connectors). For example the Power.Sink model defines the variable Units.PositivePower W_in but not the equation that calculates it.
If it is intended that the variable shall be fixed by an external boundary condition the variable should be defined as input.
If it is intended that the equation that calculates the variable is put outside the component but non necessarily it is a binding equation then the model is structurally unbalanced.

[pierre-eliep-met]

This should be not necessary, the point is that only the Connectors.Inlet instances should have the binding equation. In your commits the binding equation is also present in the case of Connectors.Outlet instances.

Yes I had done this mistake before but I corrected it, it should be only on inlets now, excepted for the source.
The point is that if I don't modify the Source.Sink component the model is not balanced, that's why I put it as connector input

[AndreaBartolini]

This should be not necessary, the point is that only the Connectors.Inlet instances should have the binding equation. In your commits the binding equation is also present in the case of Connectors.Outlet instances.

Yes I had done this mistake before but I corrected it, it should be only on inlets now, excepted for the source. The point is that if I don't modify the Source.Sink component the model is not balanced, that's why I put it as connector input

This is because now the connector is balanced but not the model (see also the comment before).
If you use balanced connectors you have to give an equation for one between the effort and the flow variable. In case of Inlet connectors this equation is the binding on the NotUsed effort variable, for the Outlet you should supply the equation of the flow variable or declare it as Input, meaning that the top level model will have a binding equation for said flow variable.

[casella]

We had a meeting today with @pepmts, @casella and @AndreaBartolini to discuss the issue. After some internal discussion, we came up with an assessment of the current status and a proposal, that will be posted here ASAP. We should then call another meeting with @pepmts to ensure he understands it fully and agrees with it, or possibly to change it according to his further input.

[casella]

Part 1: Connector definitions

The first issue is that the Power.Connectors.Inlet and Outlet connectors on mml3-main are not balanced, because they have a flow variable but no associated effort variable

connector Inlet
  import MetroscopeModelingLibrary.Units;
  flow Units.PositivePower W;
end Inlet;

connector Outlet
  import MetroscopeModelingLibrary.Units;
  flow Units.NegativePower W;
end Outlet;

For truly physical models (e.g. electrical or mechanical) one would have also a physical effort variable. For example, in mechanically connected components, this could be the angle or angular velocity of the mechanical flanges, which are then connected (-> welded) together to enable the power exchange. For electrically connected components, this could be the voltage of the electrical ports, which are then connected (-> plugged) together to enable the power exchange. These models would then in general contain an equation establishing some relationship between the power and the velocity/voltage. Something akin to a voltage-current relationship in DC electrical components. This is for example useful when modelling turbojet engines, where you have compressors, turbines, and fans on the same shaft, whose behaviour strongly depends on speed.

What you need here, however, is a lot more abstract, i.e., you need to model transfer of power, regardless of the concrete physical phenomenon behind it. Furthermore, your models do not need generic flow-effort relationships, but fall only in two categories

• components that produce or consume a certain amount of power (e.g. turbine, pumps), regardless of the other components attached to the power connector
• components that accept whatever power is produced by the other components connected to the Power port, without any influence from their internal state, e.g. electrical generators.

In some sense, even though you use completely general flow-effort connectors, your components are akin to either ideal voltage sources or ideal current sources. No resistors, and no real generators with internal impedance.

Therefore, you can define connectors with a dummy effort variables.

connector PowerWriter "Writes the power flow based on the inner working of the component"
  import MetroscopeModelingLibrary.Units;
  flow Units.Power W;
  Units.NotUsed dummy "dummy effort variable to balance the connector, value not used";
end PowerWriter;

connector PowerReader "Reads the power flow coming from the other components that write it"
  import MetroscopeModelingLibrary.Units;
  flow Units.Power W;
  Units.NotUsed dummy "dummy effort variable to balance the connector, value not used";
end PowerReader;

Components that generate or consume a certain power regardless of the other connected components will set the flow variable (power) on the connector; note that the actual direction of power flow (entering or leaving) is irrelevant, what matters it what this power flow depends upon.

Components that instead take in (or out) whatever power is generated (or consumed) by the other connected components will set the dummy variable, to a dummy value of zero. Notice that you must have one and only one such component in the same connection set; if you have none, the power generated by the components of the other type would have nowhere to go. If you have more than one, the system of equations will be balanced, but over- and under-determined at the same time (thus singular) because you are setting the dummy variable many times, and there is no way to determine how the power flow is split among them.

Some remarks, compared to the current tentative implementation in the fix-power-connector-balance branch:

• We suggest to use dummy, which is more appropriate instead of not_used, which is a bit misleading. You can write "value not used" in the comment
• The two connectors are structurally identical. They will differ by their icon (e.g. empty for writer and full for reader), which gives an important visual cue, namely only one reader (full icon) connector must be present in every connection set, otherwise the system will be balanced, but singular
• As will become clearer in the next comment, the PowerWriter component must be used both for outgoing power flows (e.g. turbines) and for incoming power flows (e.g. pumps). As already said, the sign doesn't matter, what matters is who decides what in the system. Hence, the min/max attribute of the W variable is not set.
• Hence, we chose PowerReader and PowerWriter instead of PowerInput and PowerOutput, or Inlet and Outlet, because all other alternatives refer (or can be interpreted as referring to) to the direction of the energy flow, not to the causality. Reader and Writer explicitly point to the causality, instead, which is what characterizes these two different connectors

[casella]

Part 2: Component definitions

When tackling component definitions, we consider the basic design decision of Metroscope, regarding the change of causality to solve inverse problem: each component has certain connector input variables, which are the "default" prescribed variables. The default structure of the component is thus obtained when all the connectors are connected: the ones carrying the fluid, the power connectors, and the input connectors (e.g. the rotational speed in pumps). It is then possible to change the causality and solve inverse problems by not connecting those input connectors, and by adding other suitable equations to the system model instead.

From this point of view, the turbine and the pump are similar. The turbine model implicitly assumes a fixed speed, corresponding to 50 Hz synchronous behaviour. The pump model instead has a rotational speed input, so by default it has a fixed speed as well. If one connects the fluid inlet and outlet ports, e.g. to two fixed-pressure and enthalpy components, and also connects the rotational speed input in the case of the pump, then the behaviour of the machine is completely determined, in terms of flow rate and power production/consumption. The only difference is that the turbine will have a negative flow variable on the connector, the pump will have a positive one, but in both cases the power flow it will be determined by the machine, not by some other component connected to it.

From this point of view, note that the current Pump model in the fix-power-connector-balance branch seems wrong (it has one equation missing), because the nominal rotational speed Vrotn, which we assume should be know a priori, is not declared as an input variable, but as a regular variable. Therefore, even if you connect the rotational speed input to a constant generator, the actual normalized speed that determines the pump curves is not determined, because there is still one degree of freedom. So, we think that the fact that @pepmts managed to get one balanced example with the pump in the fix-power-connector-balance branch is probably questionable. We believe VRotn should be a parameter. If you want to optionally allow to make it free and determine it via another equation at the system level, then it should be a connector input.

Both turbine and pump models will contain an equation setting the C_power.W variable to the power variable that shows up in the energy balance equation, which is conceptually an output if all the other connectors have been connected. Hence, you need a PowerWriter connector both for pump and turbine.

On the other side, we have the Generator model. This one instead will have a PowerReader port and an equation setting C_power.dummy = 0. It will conceptually see C_power.W as an input, which is computed as the summation of the flows of all the other connected components by solving the connection equations for flow variables. Of course if you also want to explicitly represent the electrical power flow leaving the Generator model, that will require adding a PowerWriter connector to the other side of the Generator model.

The handling of the connection between turbines and electrical generator will be exactly the same as in the currently developed fix-power-connector-balance branch. Instead, the connection between the pump and the electrical generator will have to be different. More specifically, in the default situation, where the pump rotational speed inlet is connected, the solved pump model will actually calculate the pump consumption, so the PowerSource model will be conceptually similar to the Generator: it will have a PowerReader port, and just read that value. For convenience, it could contain an internal variable W and an equation such as C_power.W = -W, in order to get positive values of the power W when the pump is running, rather than the negative one that shows up on the port. This is the default scenario.

If instead you want to explicitly prescribe the power input to the pump, and get the rotational speed as a consequence, then you need to enable the inverse computation configuration: disconnect the rotational speed input connector of the pump, so that this becomes a free variable, then add a system equation such as powerSource.W = 1e6 to actually prescribe the power flow out of the power source component.

It is also possible to define a PowerSink model, which will have the same causality as the PowerSource, only containing an equation C_power.W = W with the opposite sign. Again, what matters is not the actual direction of the power flow, but who is determining what in the system.

In this way, connectors are balanced, individual models are balanced, and the design of the library is totally symmetric, consistent, and easy to document and explain. Once more, one has to be careful to always have one and only one full power connector in each connection set involving power connectors, otherwise one would get some singular system diagnostics, either at compile time or at runtime.

[pierre-eliep-met]

Okay ! That was indeed a long story ! It seems to me that this solution works most of the time, but we sometimes have a connection from the turbine power connector to the pump power connector (for turbopump) but in that case we have no PowerReader to set the dummy variable...

Maybe I misunderstood some part, could you propose an implementation if I am wrong ?

[casella]

Okay ! That was indeed a long story ! It seems to me that this solution works most of the time, but we sometimes have a connection from the turbine power connector to the pump power connector (for turbopump) but in that case we have no PowerReader to set the dummy variable...

I think a solution can be found, but I need to understand exactly what you want to model in that case: are the turbine and the pump free to change their rotational speed, until they reach some kind of equilibrium? In that case, you need some way to get the shaft speed into the turbine model, this is really not possible with such abstract power connectors, because they don't convey that information. You would need physical mechanical connectors to do that.

[pierre-eliep-met]

There are two possible causalities in such models :

• Reverse : the power needed by the pump is computed by the outlet boundary conditions, such as pump's outlet pressure.
• Direct : the power needed by the pump is computed by the pumps parameters, and if the needed power increases, the turbine will adapt by taking more mass flow

Can we still use this dummy variable to equilibrate the connectors ?

[casella]

@pepmts, this is still not clear to me. Let me get there in steps.

Case 1: pump with electric drive (this case is already covered by our proposal)

Assume you have a pump actuated by a variable speed drive.

In forward mode, the input rotational speed is given. This corresponds to operating the variable speed drive with a fixed speed set point. In this case, obviously, the pump power will be an output of the calculation, and you may represent that explicitly as coming from a PowerSource model,as we discussed already.

In reverse mode, the pump speed is used to control something, a temperature, a pressure, a flow rate, the absorbed power, whatever. In this case, you leave the rotational speed unconnected, and then add one more equation to specify what you want to control. This corresponds implicitly to representing a control system that keeps what you want at its set point, by acting on the rotational speed, with a cascaded control strategy. Obviously, if you fix the controlled output to some set point, the rotational speed is completely determined by that, so it becomes a system output.

Case 2: turbo-pump (still unclear)

Assume now the pump is actuated by a turbine which is explicitly modelled in the system's flow diagram. As in the previous case, the actuator will need to have one degree of freedom to control it. For the electrically actuated pump, it was the rotational speed set point of the variable speed drive. I'm not sure what it is in the case of the turbine (this is a question for you). It could be, e.g. some throttling valve opening.

So, this turbine model in forward mode will compute its power output, that will also depend on this extra degree of freedom (e.g. throttling valve).

I can come up with a modular solution that deals with the dummy variable, but before we delve into actual mathematical modelling, we first need to understand how the turbine power is actually controlled in turbo-pump settings. I guess it's through some throttling valve, but maybe it's done differently.

@pepmts can you please comment on that?

[pierre-eliep-met]

(I did not forgot this question, I am currently diggig a bit)

[pierre-eliep-met]

I think the final answer of the turbopump causality is "it depends". Usually the pump would compute itself the needed power, if we lack some sensors we would add hypothesis, but the power would still be computed by the pump I think.

The "it depend" case is because we could have more sensors on the turbine side than on the pump side, leaving less degrees of freedom on the turbine and thus imposing more degrees of freedom, such as the pump's power.

@valentindrou if you want to comment this last part ?

[pierre-eliep-met]

In the end, this "it depends" case pushes me to think that the previous solution proposed by @AndreaBartolini that I implemented in #278 is the best one so far, but I am not sure I understood everything yet on this case

[AndreaBartolini]

It seems to me that, at the end, we need to manage the case in that a component (like pump or turbine) can have a power connector that works as either "reader" or "writer" depending on the overall model, but the reader/writer causality doesn't change during the simulation of the overall model (i.e, it is structurally defined in the overall model).
Is it correct?

[pierre-eliep-met]

Yes !

[pierre-eliep-met]

Causality never changes during the simulation

[casella]

I think the final answer of the turbopump causality is "it depends". Usually the pump would compute itself the needed power, if we lack some sensors we would add hypothesis, but the power would still be computed by the pump I think.

I'm sorry, but I'm afraid there is a misunderstanding here. The question is not how you model the turbopump from a mathematical point of view (hence who computes what). The question is, how is it operated in real life.

How is the turbine power actually controlled in a turbo-pump configuration? Is there some turbine throttling valve operated by a controller?

[valentind-met]

Yes there is a throttle valve, though we do not usually have its opening.

[casella]

Yes there is a throttle valve, though we do not usually have its opening.

That is not necessary. My point is that, conceptually, the throttling valve opening will be used to control something.

The solution to deal with the turbopump, without resorting to complicated solutions (e.g. conditional connectors) could then be the following, which uses the balanced components we already proposed

• By default, the pump and the turbine both compute their power flows, as we said in the past
• You connect their power ports together, and then connect them to the power port of a PowerSource, which sets the dummy variable
• You do not provide an input for the pump rotational speed and for the throttling valve opening, thus adding two degrees of freedom to the system
• You provide two extra equations, one setting the PowerSource power to zero (i.e., no net power coming from the outside), and one setting whatever variable is controlled by the throttling valve to its set point value.

That's it.

Providing no input for the pump rotational speed is easy: just leave the rotational speed input unconnected and do not provide any equation for it.

Providing no input for the throttling valve opening is a bit trickier, because that input has a default binding, and there is no way to remove it when instantiating it. I guess the easiest way to deal with that is to declare one extra free variable in the system and then pass its value as a binding equation to the turbine throttling valve opening. This will replace the default binding with a variable that has no equation, so it will add the required extra degree of freedom, to be matched by the equation prescribing the value of some controlled variable to its set point.

Is this OK?

[pierre-eliep-met]

I am sorry but from a user experience point of view this seems super complicated

You provide two extra equations, one setting the PowerSource power to zero (i.e., no net power coming from the outside), and one setting whatever variable is controlled by the throttling valve to its set point value.

As you said in the previous meeting, I would be a bit mad with my colleagues if I had to do this is because it is an unnecessary and counterintuitive modification, and it has no physical meaning. To me, having to add a power source, then set its power to 0, all this just to handle the dummy variable is really too complicated.
The turbopumps modeling is too dependant on the sensors that we have to be that much linked to some artificial modification, this does not seem robust enough to me.

To my mind, it is still better to do as in #278 :

• It handles the dummy variable
• power connectors are balanced
• the only issue is that the connectors do not correspond to the causality that you discussed above, but it is far simpler to understand for the user than this complex handling of power sources and connectors.

Maybe @valentindrou you would have a different point of view ?

[casella]

@pepmts, I am still a bit confused about what you want to do with the Pump model.

In #278 you set the dummy (or not_used) variable of the power port in the pump model. This means that the power port in the pump is a "power reader", as in the case of the generators.

But then, you showed us example models where you connect the pump to a generator. In this case you'd have two power readers, both trying to set the dummy variable. This of course cannot work.

My point is, you can't have it both ways. Either the pump port is a power reader, or it is a power writer. From my perspective, it is more natural to make it a writer, since the mathematical structure of a turbine model (which we all agree should compute the generated power by default) and the mathematical structure of a pump model are exactly the same. The only difference is the sign conventions.

Do I miss something?

Please also note that these power ports are not really physical connectors. They pretend to, but they aren't. A real physical connector would carry two coupled flow and effort variables, whose product is related to power transfer. That way, they could be connected in all the ways that make physical sense. These power ports are actually generalized inputs and output connectors, the generalization being that you can have multiple outputs which all get summed into a single input. Therefore, library users must be aware of this fact, lest they run into trouble.

[pierre-eliep-met]

you connect the pump to a generator

This should not happen, maybe thare was a misunderstanding, but this cannot happen since power is not produced by the generator nor by the pump. This connection set would make no sense, I am sorry if I wrote it some where, it is not something we encounter.

What I mean in #278 is that since for every power connection set, there is one and only one connector expecting a power with a negative sign (and this sign cannot change, no matter the causality), we can use this connector expecting a negative sign to set the dummy variable.

I agree these connectors don't really have a physical meaning, we only try to find a way to make them balanced with the dummy variable.
To me, using the sign convention to define the power ports has as much meaning as using the causality. And your previous comment points me to think that using the sign convention results in easier modeling than with the causality one.

These power ports are actually generalized inputs and output connectors, the generalization being that you can have multiple outputs which all get summed into a single input. Therefore, library users must be aware of this fact, lest they run into trouble.

Agreed, this is something that we must document, but it is much easier to understand than the causality approach, I think.

[pierre-eliep-met]

I'm afraid I am not clear above, so I'll add one point :

In #278 you set the dummy (or not_used) variable of the power port in the pump model. This means that the power port in the pump is a "power reader", as in the case of the generators.

I don't think it makes sense to interprete it like that. The causality approach and the sign one (in #278) are not equivalent : in the sign convention, a component that sets dummy=0 does not necessarily correspond to a PowerReader in your approach, same for PowerWriter.

It is just two different ways of handling the dummy variable, but nothing imposes the pump to be a PowerReader just because it sets dummy

I hope it makes things clearer but I am not sure ;) maybe another meeting would save us time ;)

[casella]

you connect the pump to a generator

This should not happen, maybe there was a misunderstanding, but this cannot happen since power is not produced by the generator nor by the pump. This connection set would make no sense, I am sorry if I wrote it some where, it is not something we encounter.

I can't follow you here. If the pumps are expected to have a power port, you have to connect them to something. Otherwise, the unconnected port will cause a default connection equation port.W = 0 to be generated. So, either you need to connect it to a turbine, or to a PowerSource. The only way to avoid this is to make that port conditional, and turn it on only when you want to connect the pump to a turbine.

I any case, I am quite sure I saw such pump-generator connections in some test cases. @AndreaBartolini do you remember where?

[casella]

I'm afraid I am not clear above, so I'll add one point :

In #278 you set the dummy (or not_used) variable of the power port in the pump model. This means that the power port in the pump is a "power reader", as in the case of the generators.

I don't think it makes sense to interpret it like that.

Of course it does. Physical ports have pairs of flow-effort variables. The idea is that the component internally enforces some relationship among them (e.g. V = R*I for a resistor), and then the connected component provides another relationship (e.g V = V0 or I = I0 or V = V0 - RI), closing the overall system model.

If the pump model sets the dummy variable, the other power variable is free, and needs to be set by the other connected components. Hence, the pump model will read whatever power value the other connected component(s) will set. That's how balanced connectors work.

The causality approach and the sign one (in #278) are not equivalent : in the sign convention, a component that sets dummy=0 does not necessarily correspond to a PowerReader in your approach, same for PowerWriter.

I'm not sure what you mean exactly by the "sign approach", but the concept of balanced connectors in Modelica is based on equations-variables count. It has nothing to do with the actual values of variables. In some cases causality and sign may actually coincide, and this may help the end user, but at the end of the day what matters for balancedness is the mathematical structure, not the actual values

It is just two different ways of handling the dummy variable, but nothing imposes the pump to be a PowerReader just because it sets dummy

See above.

[pierre-eliep-met]

@casella I don't think we link pumps to generators, but we do link them to a turbine, for the turbopump discussed above, otherwise we only link them to power sources

[pierre-eliep-met]

If the pump model sets the dummy variable, the other power variable is free, and needs to be set by the other connected components.

Do you mean that if the pump sets the dummy variable it cannot set the power W ?

[pierre-eliep-met]

I'm not sure what you mean exactly by the "sign approach",

I mean the one implemented in #278, and currently in MML, where power connectors are named PowerInlet when expecting W<0 and PowerOutlet for the opposite.

[pierre-eliep-met]

the concept of balanced connectors in Modelica is based on equations-variables count. It has nothing to do with the actual values of variables

I completely agree

but at the end of the day what matters for balancedness is the mathematical structure, not the actual values

I agree too.

But with the idea of "the connector that only accepts negative power sets the dummy variable", we have locally balanced power connectors, I agree it is not due to sign, it is just a convenient way of having a dummy variable that is set only once in the connection set and does not demand any further adaptation by the end-user, everything is transparent

[casella]

@casella I don't think we link pumps to generators, but we do link them to a turbine, for the turbopump discussed above, otherwise we only link them to power sources

Generators and power sources are the same story. They set the dummy variable and accept/read (i.e. supply, from a physical point of view) whatever sum of power flows in their port from the other components that determine them. Once again, the sign of the power flows is irrelevant.

[casella]

If the pump model sets the dummy variable, the other power variable is free, and needs to be set by the other connected components.

Do you mean that if the pump sets the dummy variable it cannot set the power W ?

Of course not. That would be an unbalanced component. Balanced components can only set one condition for each pair of flow/effort variables.

[casella]

the concept of balanced connectors in Modelica is based on equations-variables count. It has nothing to do with the actual values of variables

I completely agree

but at the end of the day what matters for balancedness is the mathematical structure, not the actual values

I agree too.

But with the idea of "the connector that only accepts negative power sets the dummy variable", we have locally balanced power connectors, I agree it is not due to sign, it is just a convenient way of having a dummy variable that is set only once in the connection set and does not demand any further adaptation by the end-user, everything is transparent

Sure. This means that for pump-power source connections, since the power source sets dummy, the pump cannot set it as well. The pump is a "power writer" (same as the turbine, with opposite sign), the source a power reader (same as generator, with opposite sign).

Hope this clarifies the issue 😅

[pierre-eliep-met]

Okay ! We've discussed this with @valentindrou and I think we can come up with a solution !

• We will remove the power connector from the pump, because it true that the pump often computes its power on its own
• We will create a turbopump component, so that we can still link turbine's power to a pump's power, using an equation

Concerning your causality approach of power connectors, I think we would still have problems wor what is happening after the generator (usually, a power sensor and a power sink), because the power sink is necessarily a PowerReader, but the power sensor would need, as an "inlet" a PowerReader to set the dummy variable, and at the "outlet", a PowerWriter, which in terms of causality is still a bit weird to me, and we don't have this issue with what I implemented in #278
In fact the power sensor is either a plain PowerReader or a plain PowerWriter, depending on the causality we choose...
So #278 this still seems a better solution to me because it covers those cases.

Dropping the pump power connector will probably simplify this conversation a lot

[pierre-eliep-met]

Balanced components can only set one condition for each pair of flow/effort variables.

Interesting, I didn't know that !

[casella]

Okay ! We've discussed this with @valentindrou and I think we can come up with a solution !
* We will remove the power connector from the pump, because it true that the pump often computes its power on its own

* We will create a turbopump component, so that we can still link turbine's power to a pump's power, using an equation

This is one option. However, a really satisfactory modular design shouldn't force you to do this tricks. I still wonder if there isn't some other way to deal with these power connectors, that is elegant, easy to use, easy to understand, and easy to code. The current solution is not ideal from this point of view.

Concerning your causality approach of power connectors, I think we would still have problems wor what is happening after the generator (usually, a power sensor and a power sink), because the power sink is necessarily a PowerReader, but the power sensor would need, as an "inlet" a PowerReader to set the dummy variable, and at the "outlet", a PowerWriter, which in terms of causality is still a bit weird to me, and we don't have this issue with what I implemented in #278 In fact the power sensor is either a plain PowerReader or a plain PowerWriter, depending on the causality we choose... So #278 this still seems a better solution to me because it covers those cases.

I'm not sure I understand the role of the PowerSensor. Why doesn'it simply have a power output, but rather a C_out power port? Is it because you still want to be able to sum many of them and get the total computed in a further PowerReader?

[casella]

@pepmts, as I understand once you remove the power connector from the pump, what I proposed and what you tried in #278 are the same thing. Do I miss something?

[casella]

Balanced components can only set one condition for each pair of flow/effort variables.

Interesting, I didn't know that !

Modelica Specification, Section 9.3.1:

For each non-partial non-expandable connector class the number of flow variables shall be equal to the number of variables that are neither parameter, constant, input, output, stream nor flow.

Section 2 of this paper clearly motivates why it has to be so.

When checking balanced components, the rules in Section 4.7 state that for each flow variable in top-level connectors you must count one extra equation. Combined with the rule of Section 9.3.1, this means that any physical model has one free degree of freedom for each pair of effort/flow variables in top connectors. This is the only way you can guarantee to always get balanced models no matter how you connect them.

When you connect two such balanced models you have two degrees of freedom, which match one equation for the effort variables being equal and one for the flow variables to sum to zero. When you connect three of them, you have three degrees of freedom that match effort1 = effort2, effort2 = effort3, flow1 + flow2 + flow3 = 0. And so on and so forth.

[pierre-eliep-met]

Once you remove the power connector from the pump, what I proposed and what you tried in #278 are the same thing. Do I miss something?

Almost, there is the issue with power sensor, which currently has two connectors

[pierre-eliep-met]

I'm not sure I understand the role of the PowerSensor. Why doesn'it simply have a power output, but rather a C_out power port? Is it because you still want to be able to sum many of them and get the total computed in a further PowerReader?

The power sensor is in the line because we usually do that for all sensors, to avoid some errors, but since power sensor are always put after the generator, yes it could be relevant to use only one PowerReader output