Degrees of freedom drop to -5 after initialization when adding Heater unit in a simple system #1625
-
Hi everyone, I've built a simple RSOC system, as shown in Figure 1. The system first preheats the fuel and air streams (from room temperature to 1073 K), and then feeds them into the RSOC for hydrogen production. A Heater unit is used to ensure that the inlet gas temperature reaches 1073 K. After initializing the system (see lines 284–313 in the code), the degrees of freedom drop from 0 to -5. I found that this issue is caused by the oxygenheater unit. When I remove the oxygenheater and directly connect the oxygenfeed to the stack_oxygen_inlet, the system looks like Figure 2, and initialization completes without issues—the degrees of freedom remain at 0 and everything runs correctly. I'm quite confused and would really appreciate your insights: Additional information for reference:
Thank you in advance for your help!
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
Hi again, I’ve done some further testing and discovered a new situation that might be helpful. If I do not include the heat exchanger loop, the system can initialize and run successfully even with the oxygenheater present. This setup is shown in Figure 3. In this case, I manually applied the stack outlet conditions to the hot side of the heat exchanger (see lines 288–292 in the code), instead of forming a full loop. With this adjustment, the degrees of freedom remain at 0 after initialization. The code is included below. Just wanted to share this additional observation in case it helps identify the root cause. |
Beta Was this translation helpful? Give feedback.
-
I used the
Independent Block 2 was the easiest to look at, because it has a single constraint and zero variables. That constraint was the temperature equality constraint between the oxygen heater outlet, which was fixed as a design specification, and the solid oxide cell oxygen inlet. The oxygen inlet temperature is incorrectly fixed, as were all the other state variables on the port. Unfixing them should fix your immediate problem, but that doesn't explain why the issue occurred in the first place. My first thought was that it might be a bug in the SOC initialization method, but we already have a test verifying that port variables are unfixed as expected. I didn't see any obvious reason in your code about why they might remain fix. Perhaps it's an issue in the Pyomo |
Beta Was this translation helpful? Give feedback.
I used the
report_structural_issues
anddisplay_overconstrained_set
methods of the IDAES diagnostics toolbox in order to determine the issue: