Can't add `pressure_dx` in 1-D control volume without adding `pressure_balance` as well

[Robbybp]

For the pipeline models, I'd like to add a pressure_dx variable, and would like to use ControlVolume1D's method for doing so. I do not, however, want a deltaP variable or pressure_balance constraint. I propose we split the add_total_pressure_balances method into two methods: one which adds the pressure derivative and one which adds the pressure balance. The method to add the pressure derivative could be re-used if we decide to support different types of momentum/pressure balances.

If this is a reasonable idea I can open a PR.

[andrewlee94]

@Robbybp Could you comment a bit more on what you wish to do instead of the pressure balance constraint?

The biggest issue I see with this idea is that it raises the question of if this should be done for all the other methods as well for consistency (including potentially 0D models).

[Robbybp]

This issue was related to the design of gas pipeline unit models. I needed to add my own momentum balance (as far as I could tell, adding a custom momentum balance with time and space derivatives was/is not supported by 1d control volumes), so I needed a pressure_dx variable, but did not want a deltaP variable or pressure_balance equation. I ended up implementing a small add_pressure_dx method to just add this pressure derivative, which can be seen here: https://github.com/IDAES/idaes-pse/blob/4d0343d8af4b13a2dad00f9b1797bda9338c73bb/idaes/models_extra/gas_distribution/unit_models/pipeline.py#L330 . Ideally, something like this could get added into the control volume, and used in any/all of the methods that add pressure_dx.

[andrewlee94]

Firstly, there is nothing wrong with what do did in that example - control volumes are intended to be general helper objects, not the be-all-and-end-all of creating unit models. I.e., you should feel free to only use those parts that make sense for a given model (the caveat being that things in the core model library are expected to be a bit more standard).

However, for your cases here, what exactly did you want to use the DerivativeVar for? I will note that for just about any case I can think of -deltaP[x] == DerivativeP[x], so whilst not the most efficient implementation it should be equivalent (and a good case for using the equality elimination transformation).

[Robbybp]

I needed the DerivativeVar for the momentum balance equation, and I didn't want the "auxiliary" deltaP variable. I agree that it's not the biggest deal if deltaP (and its equality constraint) exists, I just prefer to not write additional unnecessary variables and constraints when possible.

[andrewlee94]

One potential option would be to make deltaP a Reference to the pressure derivative instead of a separate variable, but I wonder if there might be too many edge cases or confusion if we tried that.

[Robbybp]

I would prefer to just split up the API between constructing the derivative and constructing deltaP (and its equation). Making deltaP a reference would eliminate the auxiliary equation, but would still clutter the namespace, which I also try to avoid. It would also break backwards compatibility, as any code referencing the pressure_balance constraint would break.