dynamic 1d pipe model with heat exchange

[atpeterz]

[adowling2]

@atpeterz Welcome to the IDAES discussion board. I will let another member of the IDAES team speak to your specific questions about a 1DControlVolume.

As a fallback, if you are only interested in quickly simulating the PDEs you posted, you can try using Pyomo directly. Here are two relevant examples:
https://jckantor.github.io/ND-Pyomo-Cookbook/notebooks/05.03-Heat_Conduction_in_Various_Geometries.html
https://jckantor.github.io/ND-Pyomo-Cookbook/notebooks/05.04-Diffusion_Adsorption_in_Polymers.html

If the dynamic 1D pipe model is just a starting point for a larger project, I encourage you to try to simulate this system with IDAES. IDAES will allow you to build more complex systems by coupling various unit operations from the modeling library.

[andrewlee94]

@atpeterz Welcome to the IDAES discussion board. It is definitely possible to solve the types of models you are interested in IDAES, although dynamic models are always a little bit tricky to work with. Unfortunately, we haven;t had the time or resources to put together good examples of working with dynamic models yet, but we have solved dynamic systems, including heat exchangers, before.

As a place to start, I would recommend looking at the 1D heat exchanger model - the case you discussed is similar in many ways to this: https://github.com/IDAES/idaes-pse/blob/main/idaes/models/unit_models/heat_exchanger_1D.py.

Regarding control volume,s the first thing to emphasize is that these are meant to be be convenience tools which can automate common tasks/activities for you - you do not need to use them if you do not want to. For example, the second equation you showed appears to be the energy balance for the fluid phase with a heat transfer term - the control volume can automate the construction of that for you. The add_total_energy_balance method can add the constraint V*d(rho*h)/dt = - dF/dx + Q for you - you just need to provide a constraint that defines Q=U*A*deltaT somewhere else.

Next, the place to implement your additional equations (the wall material energy balance and the definition of Q) is either the unit model or the control volume (we would generally use the unit model). Note that an instance StateBlock is created at every point in the spatial domain, so you do not want to have any derivative variables in there (you would end up with n-instance of the derivative, rather than a single instance with n-elements).

Finally, a comment on general solvability of these types of systems: the system you showed above does not seem to be too bad, but you do have two different time-dependent derivatives which quite likely have different time constants (fluid and wall hold-ups). If these time constants are significantly different then the system of equations will become very stiff and difficult to solve. If you have a case where the time constants are extremely different, you generally need to decide which of the two terms is more important and simplify the other (generally by assuming steady-state over the time interval of interest). We have tried solving these types of systems before, and we found htat we needed to make these sorts of assumptions in order to be able to solve the model.

[atpeterz]

@andrewlee94 Thank you for your quick reply

Well I thought that my steady-state model already works correct - at least it had the output that i expected: a temp inside the controlvolume rising from 300 up to 350 K, or anything that is set as start and end temperature; This was the reason I thought I could move on to dynamic modelling.

But I fixed for steady state all pressures and temperatures for initialization. I thought the pressure fixing was needed for the add_momentum_balance_type.totalpressure method and the temperatures to tell the model where i wanted them to have (temperature rise from inlet up to outlet). And I fixed flow at inlet and outlet for the material balance, but only for initialization. For the final solve everything expect the inlet for all three state variables and the outlet of temperature was unfixed again.
Since the modeled temperatures had very small deviations from the initialized ones I assumed the model solved correct.

I am using my own written property package, not the IAPWS properties.

I thought that the model is actually solved after the initialization. Therefore I assumed its no problem to fix temperatures everywhere since they are anyway unfixed for the final solve. But your last argument makes also sense, thanks for the explanations!

[atpeterz]

regarding your point 1) from last reply: Here I am considering an in-compressible fluid. For the beginning, I wanted nothing more than when having a constant flow into the pipe with changing temperatures to model the change of temperatures inside the pipe. So to speak, at the outlet I wanted to see the same "temperature curve" as given at the inlet, only shifted in time. This was my thinking of dynamic behaviour of the starting model, for later being able to model the heatexchange with environment (the 2 coupled PDEs given in my opening question of this thread).

[andrewlee94]

The problem is with the way you implemented it however - if the system is in-compressible, then the mass balances should ensure that flow in equals flow out at all times. Thus, you should not be fixing the outlet flow rate. What you have ended up doing is creating a degenerate system, where the degrees of freedom appear to be zero overall but in reality part of the system is over constraint and part is under constrained. In short, this means that you have a system with an infinite number of solutions; importantly this means that a solver can still find a solution to the problem but the solution it is essentially meaningless.

In short - I suspect that your steady-state model is incorrect even before you consider the dynamic aspect.

[atpeterz]

yeah i am back working an the steady state model. With the pressure Flow relation included also their I don´t need to fix outlet conditions except for temperature any more. But then i am still left with 3 dof, when I have 5 space points at all (finite elements = 4).
To me it makes sense that I have to fix the temperatures also inside the cv, because I haven´t defined a constraint for temperatures. It is only occuring in the get_energy_density terms and get_enthalpy_flow_terms methods, that are defined in the stateblockdata class in the prop package.

I will try my best to make it working

[andrewlee94]

You should not need to fix outlet temperature either - if you have to fix that then it means you are not solving for temperature in the system. Temperature should be coupled to enthalpy and thus be defined by the energy balance equations.

However, looking at the code you posted earlier, it looks like you are including heat transfer terms in your model - I suspect these are your extra degrees of freedom. You need to provide some constraint on heat transfer at each finite element in order to define the model, otherwise how does the solver know how much heat should be added or removed at each stage? This would also explain why you saw weird temperature behaviour, as there is nothing to force the temperature to move away from its default value (rather than change the temperature and disturb everything else, the solver can just set the heat transfer to whatever is necessary to keep temperature whee it is).