Nonphysical pump behavior vs gravity change

[mestinso]

The current behavior found in Modelica.Fluid.Machines.BaseClasses.PartialPump exhibits non-physical behavior vs. changes to gravity.

While "head" should change when gravity changes, the flow rate itself should not change if you change the system gravity but otherwise keep the pump boundary conditions the same. Currently, the flow rate will change vs. changes in gravity!

Example cases where this might be especially problematic: 1) Pump curve measured/parameterized on earth, but used on moon 2) Pump curve measured/parameterized on earth, but used in microgravity 3) Of course, there are more mundane examples where somebody just uses a slightly different value during calibration and simulation: say 9.8 vs. 9.80665, which will introduce a little error if the user is not careful.

The current flow characteristic is as follows: head = (N/N_nominal)^2*flowCharacteristic(V_flow_single*N_nominal/N) The fix to get the proper physical behavior should be: head = (g_nominal/g)*(N/N_nominal)^2*flowCharacteristic(V_flow_single*N_nominal/N) This fix requires a new parameter: g_nominal, which should default to Modelica.Constants.g_n Also note that head = dp_pump/(rho*g) and g = system.g elsewhere in the code

Alternatively, I would personally be in favor of just switching to a specific energy (H) formulation (which may also be numerically nice for g=0 use case): H = (N/N_nominal)^2*flowCharacteristic(V_flow_single*N_nominal/N) and H = dp_pump/rho with head separately defined for those that care about it as head = dp_pump/(rho*g) with g = system.g For this formulation, the need for g_nominal would not be required.

A 3rd option could even be: head_nominal = (N/N_nominal)^2*flowCharacteristic(V_flow_single*N_nominal/N) head_nominal = dp_pump/(rho*g_nominal) head = head_nominal*g_nominal/g and g = system.g

[beutlich]

@casella @rfranke Can you please have a look at it, Thanks.

[casella]

@mestinso the reason why we used head instead of specific energy is that manufacturers of pumps usually provide data in terms of head vs. volumetric flow curves, so the most convenient way to parameterize the component is to use that.

Unless of course you are talking about pumps which are employed aboard missiles, but then you need completely different hydraulic models also for other components, because g is not even constant. Or, you are considering pumps working on other planets, such as the Moon or Mars. But I would argue that this is a very special case.

Anyway, the implicit unwritten assumpion of the pump model, that you can infer by looking at the equations, is that the head vs. flow rate curve you provide is referred to system.g. Which means, if you have a pump that will be used on the Moon, the manufacturer will compute the static head according to the Moon gravity, not to the Earth gravity, and provide you with a head vs. flow curve computed accordingly. I think the last time this happened was with the LEM on the Apollo missions, and that was a long time ago, so I have no idea what convention they used. Probably they used specific energy, but again, the LEM pumps work in time-varying gravity, which is beyond the scope of Modelica.Fluid.

Under this assuption, it is obvious that if you reduce the gravity constant and you don't change the gravity vs. flow rate curve, the flow will remain the same if the load is static, but it will be reduced if the load is due to friction, because you are giving less specific energy to the fluid. I'd say this is the intended behaviour, not a bug.

Summing up

• space applications with variable gravity are outside the scope of Modelica.Fluid, because the momentum equations in the library assume fixed g and inertial reference frame
• space applications with fixed gravity (e.g. water supply plants on Moon or Mars colonies) are fine, as long as the head vs. flow curve is provided using the local value of gravity, which I'd say just makes sense for engineering applications.
• you may argue that gravity on Earth can be slightly different at the equator and at the poles, but I'd say the difference is so small compared to the typical uncertainty of fluid system models that we should probably not bother.

If you are interested in space applications, you may develop an extension of Modelica.Fluid that is coupled to the Modelica.Mechanics.MultiBody library, and takes into account variable gravity and non-inertial frame of reference, according to the information from the world model (for gravity) and from the mechanical connector (for rotation and acceleration). But that's a completely different model library w.r.t. Modelica.Fluid, and a lot more complicated.

That said, introducing g_nominal with a default value system_g is no big deal, and we can certainly do that, but I doubt it will be of any practical use, and thus look a bit of an overkill. Do you have any practical application in mind for this feature?

What do you think?

In other

[HansOlsson]

I would say a more mundane similar example of varying "gravity" would be a car when braking (or accelerating) heavily.

That may be about 1g, but vertical - not horizontal and the fluid systems are designed to handle that (however, it would be good to be able to verify that in a simulation).

(And acceleration and gravity are just the same according to general relativity.)

[casella]

@HansOlsson I completely agree. In any case, handling that case requires a different library, because the acceleration is time-varying, so it's beyond the scope of Modelica.Fluid.

[mestinso]

@casella Maybe I shouldn't have led with my space examples. That is neither my primary use case or my primary concern. Though I still think it's a valid concern at least in an academic sense. Also, to clarify, I'm not suggesting simulations with varying g over the course of the simulation. I was suggesting situations where the pump might be parameterized with one g and used at another g.

My primary concern/issue with the current implementation is that the pump parameterization/behavior is effectively set by two parameter sets: 1) The flow characteristic parameter within the pump 2) The system.g parameter

And there are two reasons this is problematic, one physical and one practical: 1) Physically: the pump parameterization can/should be expressed independently of the gravity the pump is sitting within. This is where g_nominal comes into play: ie the gravity corresponding to the "head" on the pump curve. By adding this g_nominal parameter the pump's parameterization is now self-contained, which is physically correct. 2) Practically: this is now error-prone since it requires the two components to be coordinated. It might very well be one person's job to parameterize the pump curve and another person's job to assemble components, set system-level parameters (like gravity), and do system-level simulations. If these two people don't coordinate and use the same gravity value then we have a small introduction of error.