Q_flow in heat loss heat port stays zero when it probably shouldn't

[marcusfuchs]

I am simulating the Annex60.Experimental.Pipe.PipeHeatLoss_PipeDelayMod model in the setup of the Annex60.Experimental.Pipe.Examples.UseCases.TypeB_FlowReversal.UCPipeB02AD_Temperature example. While it seems like the heat loss correctly affects the outflowing temperature, Q_flow at the heat port stays zero despite temperature differences.

@bramvdh91 Should we try to fix this behavior?

[bramvdh91]

@marcusfuchs This is a good remark; at the moment, the heat loss is only calculated as the temperature difference between inlet and outlet for a given fluid package (as handled by heatLossPipeDelay) times the instantaneous mass flow rate. Hence, all the heat losses for a zero flow period are concentrated as a single spike when the flow picks up again. The error is introduced here by not taking the correct derivative when calculating the heat loss. For the zero mass flow case, it would be more correct to calculate the heat loss by means of Qloss = der(Tin-Tout)*cp_default*m, where m would be the appropriate water mass for the pipe. However, I'm not entirely sure of the Tin-Tout term, and in addition to that there will be difficulties to make sure that the heat loss at zero flow would be calculated only once. Otherwise both design and reverse heatLoss component would detect the zero flow condition and start tracking the alternative heat loss.

I will try to adapt the current splice function that we have.

[bramvdh91]

@marcusfuchs would be great if you could also add your working example on issue37_HeatLoss.

After thinking a bit more on how to implement the heat losses during zero flow, I think this is inherently very difficult with the method that we are using. While I think it is possible to (approximately) calculate the losses at standstill, the temperatures stored in the PipeAdiabaticPlugFlow remain the same. When they exit the pipe, the temperature will be calculated accordingly (and it will be high because of the long delay). So, the heat loss spike will remain until all fluid that was in the pipe at zero flow has left the pipe. Unless we also implement temperature decay in the spatialDistribution operator, I'm afraid it will be hard to have correct heat losses at all times.

[marcusfuchs]

I agree that it is quite hard to implement this correctly with the current pipe model. Personally, I wouldn't need a value for Q_flow calculated in the model at all. After all, in a real pipe, we would propably also try to measure heat losses by temperature differences before and after the pipe, so I would be fine with the pipe not trying to be too convenient here.

[marcusfuchs]

@bramvdh91 Just pushed the example I used above. You can find it at Annex60.Experimental.Pipe.Examples.UseCases.TypeB_FlowReversal.UCPipeB02Mod_Temperature. I think I raised this issue back when I thought that the Mod model gave better results than Annex60.Experimental.Pipe.PipeHeatLoss_PipeDelay. With #39 I am currently more in favor of Annex60.Experimental.Pipe.PipeHeatLoss_PipeDelay than Annex60.Experimental.Pipe.PipeHeatLoss_PipeDelayMod, as PipeHeatLoss_PipeDelayMod seems to have problems with flow directions. Maybe we should decide on one of the two implementations as the current HEAD of development. Would be interesting to also get @carlesRT 's and @GersHub 's opinion on this.

[bramvdh91]

@marcusfuchs , thanks, I have duplicated the example under Experimental.Pipe.Examples.Comparisons in order to compare the two versions of PipeHeatLoss_PipeDelay(Mod) as you said. Indeed, the unmodified models seems to function better; the Mod version sometimes seems to get stuck on a certain tau value, greatly amplifying the heat losses which is incorrect. I am in favor of moving on with this version and possibly moving the Mod version to the archive.

Furthermore, I would suggest to drop the PipeDelay in the model name, since there is no distinction anymore.

[bramvdh91]

Just committed 7e406d0 with a basic example to test only the delay tracker, without distractions from hydraulic stuff :) In the example, I have tried adding the noEvent around u >= 0 and it seems to suppress event generation, at the expense of not having the changes in time delay at the exact moment of the flow reversal, but at the start of the time step in which this occurs. I do not think this is a huge problem, as the delay calculation is less accurate for (close to) zero flow anyway due to mixing/axial heat transfer.

The variable time step solvers still differ slightly, but only when the flow actually reverses with respect to the flow direction before standstill. I guess the integrator anticipates this and this could explain the strange result. If it is true that the issues arise in this specific case only, it is also not directly a problem, since the tau in which the error occurs is not needed at that time for the heat loss calculation.

Finally, I was afraid that there were a lot of events, until I found out that most of them originated from the ramps, so I replaced those with a combiTimeTable. Now it seems there are only events at the initialization itself.

[bramvdh91]

I would propose to close this issue and move the discussion about the new implementation/event suppression to a new issue.

[bramvdh91]

Following a discussion with @mathadon this morning, we could calculate the actual heat losses in parallel with the temperature calculations as function of the average temperature in the pipe (done by integrating the difference in inlet and outlet temperature, weighed by the in/outflowing mass). This should usually give the same results as those for the instantaneous temperature change calculations, except for a more accurate result at periods of zero flow.

[bramvdh91]

This is more relevant again as we want to check the energy balance.

[bramvdh91]

@marcusfuchs I looked into this again, branch issue_zeroFlowLoss implements a workaround to have more continuous heat losses. For now, the outputs TemAv and Qlos from the model pipeCore contain the results, but we could think of restructuring this model a bit such that this "average" heat loss is connected to the heatPort instead of the more instantaneous losses.