1D Heat exchanger DAE help

[bjl25]

Hello all,

I am trying to model a heat pump with a fixed condenser area and then vary the sink (cold side) conditions (i.e. 15°C- 85°C for one case then 15°C - 45°C and so on). This heat exchanger will have a desuperheating and condensing region with the minimum DT at that transition point. I want the model to minimize the pressure ratio of the compressor (saturation temperature) without temperature cross in the transition region.

Two questions: Can I see the temperature at each of the finite elements across the length to check if there is a temperature cross and what the DT is? Second question (less important): can I vary the U value along the length?

Any help or advice would be appreciated.

[andrewlee94]

@bjl25 That all depends on what model you use (or how you write the model if you create a custom one), but in general you can see everything that goes on inside the model. Given your application, you might want to look at the FeedwaterHeater models: https://github.com/IDAES/idaes-pse/tree/main/idaes/models_extra/power_generation/unit_models

If you use a 1D heat exchanger (or equivalent), you will be able to check the temperatures at any finite element (e.g. print(value(model.hot_side.properties[time, x].temperature)) - note that the name will likely be different for your model). As for varying U, that will depend on whether the model defines U as a scalar variable or a variable indexed by space (and time).

Also note, that with a good set of thermophysical properties and suitable finite element spacings you will never see a temperature cross-over as the equations (and the physics behind them) do not allow it. What you might find however is that the solver is unable to find a feasible solution due to overly large (or small) finite elements causing the numerical errors and instability (model stiffness).

[bjl25]

Thank you so much @andrewlee94, I will investigate this today.

[bjl25]

I ran a few tests with the advice you gave @andrewlee94 for the 1DHX and it worked well. I then included the 1DHX into my full heat pump model. I checked the degrees of freedom with the statistical tool and it calculated 0. I then ran it through my sequential decomposition initialization routine like I would normally do and then I found that the degrees of freedom subtracts to -3 after the SD routine. This makes it unsolvable of course. I was wondering, is there a difference in how the 1D initializes that would cause this error to occur and how would I fix the issue.?

[andrewlee94]

@bjl25 First of all - did any of the initialization steps fail during initialization? With some of the older initialization routine, if there is a critical failure the initialization can terminate without cleaning up after itself, resulting in changes to the DoF.

The first thing to do is look at what the changes in the DoF are as that will tell you where to start looking.

[bjl25]

@andrewlee94 The HX output in listed below and the rest of the operations say Initialization Complete: optimal - Optimal Solution

I found that the internal HX would lose 3 degrees of freedom during the initialisation. It is difficult to explain but I originally had some constraints equating the enthalpy and pressure out of the iHX to the inlet of the expansion valve (I did this so I would have to recycle mass flow to make initialisation easier). This had worked in the past with the condenser being a 0DHX but changing to the 1D made the constraint fix the outlet variables for the IHX lessening the DOF.

I have resolved this by using arcs instead of the constraint method and sequentially decomposing the refrigerant stream as well. Not 100% how that occurred. I linked some of the outputs below.

Thank you for your help @andrewlee94.

Before initialisation:

Unit: condenser
Degrees of freedom: 6

Unit: subcooler
Degrees of freedom: 3

Unit: internalHX
Degrees of freedom: 6

Unit: valve
Degrees of freedom: 2

Unit: evaporator
Degrees of freedom: 3

Unit: compressor
Degrees of freedom: 3

The DOF is 0

After initialisation:
Unit: condenser
Degrees of freedom: 6

Unit: subcooler
Degrees of freedom: 3

Unit: internalHX
Degrees of freedom: 3

Unit: valve
Degrees of freedom: 2

Unit: evaporator
Degrees of freedom: 3

Unit: compressor
Degrees of freedom: 3

====================================================================================
Unit : fs_main.HP_1.hXCOND Time: 0.0

Unit Performance

Variables:

Key    : Value  : Units      : Fixed : Bounds
  Area : 1.0000 : meter ** 2 : False : (None, None)
Length : 1.0000 :      meter :  True : (None, None)

---

Stream Table
                     Units         Hot Side Inlet  Hot Side Outlet  Cold Side Inlet  Cold Side Outlet
Molar Flow          mole / second        4.9793          1.0000           18.968            1.0000
Mass Flow       kilogram / second       0.21956        0.044096          0.34171          0.018015
T                          kelvin        396.90          333.35           322.20            270.49
P                          pascal    3.6299e+06      2.1256e+06       2.0000e+06        1.1032e+07
Vapor Fraction      dimensionless        1.0000         0.40530           0.0000            0.0000
Molar Enthalpy       joule / mole        32956.          20885.           3730.7          0.011021

====================================================================================
2024-06-18 09:33:47 [INFO] idaes.init.fs_main.HP_1.hXCOND.hot_side: Initialization Complete
2024-06-18 09:33:47 [INFO] idaes.init.fs_main.HP_1.hXCOND.cold_side: Initialization Complete
2024-06-18 09:33:47 [INFO] idaes.init.fs_main.HP_1.hXCOND: Initialization Complete.

[andrewlee94]

If I understand what you said, you had added some additional constraints to the HX model to define the inlet conditions in some way. This would create the effect you observed, as the HX initialization is not aware of these constraints, and the first thing it does is fix all the inlet conditions to their current state. Thus, if you have additional constraints you added to the HX model to define some of these, the problem will now be overdefined.

In general, these sorts of constraints are OK, but should be added to the flowsheet, not the unit model (that is effectively what Arcs do). You should only add constraints to a unit model that affect things internal to the unit (and inlets are not strictly internal as they are affected by upstream conditions).