Suppressing events in time delay tracking

[bramvdh91]

Opening new issue. Current developments are in issue37_newDelay_mod.

[bramvdh91]

Moved from #37 @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]

Moved from #37 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]

Moved to new branch: issue50_newDelayMod

[bramvdh91]

Small example to show that the delay tracker with two outputs does speed up the model (This is for the AIT validation): The red line is the original tracker, blue the one with two outputs.

[bramvdh91]

In commit a72608f212fdcbc84ff5df68fcf370926995a97f, the direction of some pipes has been changed in order to avoid numerical jacobians. These appeared as a consequence of connecting the output of two or more spatialDistributions without including a volume between them to avoid nasty non-linear systems.

Regarding this, I think we should think thoroughly about where we put the mixing volumes in the model, e.g.:

• Only at one end of the pipe (as is the case in issue264_pipe now)
• At two sides of the pipe (split up the wall capacity, will slightly improve accuracy at flow reversal)
• Only include "dummy" volumes at intersections of more than one pipe
• Vectorized ports?

Furthermore, comparison with the currently implemented delaytracker (the unmodded one) shows that the new suggestion avoids the initialization problem, including its 6 numeric jacobians in the AIT validation (one for each pipe).

@GersHub @marcusfuchs @carlesRT , do you have any remarks on this?

[bramvdh91]

As issue50_newDelayMod was merged, I suggest to close this issue.