Vectorized port

[GersHub]

Add vectorized port to avoid non-linear systems

[bramvdh91]

Renamed branch to pipe_issue20_vectorizedPort.

[bramvdh91]

Looking back into this suggestion. Is Annex60.Experimental.Pipe.PipeAdiabaticPlugFlowForVector a copy of the regular PipeAdiabaticPlugFlow model? I didn't see any changes, at least not in the ports.

Regarding the branched pipe model, I didn't have access to DHNLibrary.DistrictHeating.ComponentsMSL.Pipes.SpatialPipe.parts.ClosedVolume. Is it possible to replace this by an Annex60/MSL component? Also, Annex60.Fluid.Interfaces.PartialTwoPortVector is not present in this branch.

[bramvdh91]

@GersHub I've switched back to vectorGerald because there were still some issues with changing diameter to dh. The pipe model references some start values for P and T, but there is no component volume to get these from.

[bramvdh91]

I added a few simple examples to compare the non-linear system sizes. However, there seems to be no difference except in the linear system size when the vector-port of the mixing volumes is used instead of mixing nodes. @GersHub , what am I missing? See commit 6c48fbf

[bramvdh91]

@mwetter, we would also like your opinion on this potential improvement.

The goal here is to make the fluid ports of pipes into vectorized ports. The array of connections is then passed to a mixing volume in the pipe, such that between two pipes there will be no branched fluid connectors. Each connector operates between two mixing volumes, and this should avoid large non-linear systems and increase scalability. A comparison can be found in Annex60.Experimental.Pipe.Examples.Vector.TestVectorNodes_gs3 (vectorized, all connections are handled at a pressure state) and Annex60.Experimental.Pipe.Examples.Vector.TestVectorNodes_gs4 (as usual, multiple connections to one FluidPort) in branch vectorGerald on my fork.

[mwetter]

@bramvdh91 : I am not sure I understand your question. Do you propose to add two instances of MixingVolume inside each pipe? I would keep the pipe simple and if users want to add volumes at the junction of pipes, then they could do so manually. While this breaks nonlinear equations, it adds fast dynamics, which may sometimes be worse as it can reduce the integrator time step.

A model to optionally add a volume at fluid junction will be added to the Annex60 library, see https://github.com/iea-annex60/modelica-annex60/issues/451

[bramvdh91]

@mwetter Thank you for your feedback! When we are considering branching pipe networks, having only one mixing volume at the outlet and vectorizing only the outlet would be sufficient, but when meshed networks are modelled, two mixing volumes would indeed be necessary, as well as vectorizing both ports. I agree that this would probably make the pipe model more complicated than necessary, but on the other hand manually adding mixing volumes or splitters at the junctions could become quite involved as well in the case of larger networks.

[mwetter]

@bramvdh91 : I would think that for meshed networks, one mixing volume at each junction would suffice. If pipes are connected and each had a volume connected to its port_a and port_b, then a high index DAE is generated and we will rely on the tool to reduce the index of the DAE, which will require a global analysis of all equations of the model.

Unless we understand the performance penalty (or gain) of these volumes, I think we should explicitly model them such as using the model to be added in iea-annex60#451 as it generally is easier to add features if needed rather than removing them later if they turn out to be not needed or too complex to use.

[bramvdh91]

@mwetter @GersHub I have just made a new implementation of the vectorized pipe, please check in pipe_issue20_vectorizedPort. The mixing volume that we add to the pipe now has a physical meaning and validated results, namely to represent the thermal inertia of the pipe wall. Gerald noticed however that we still got two numeric jacobians due to connection of outputs of spatialDistributions of the time delay tracker with no volume in between. These could be avoided by either changing the direction of some pipes to avoid this, or as in the commit referenced here, by implementing one of the fluid ports of the pipe model as an array of ports, all connected to the mixing volume.

I think this really justifies the "vectorized" approach as opposed to adding arbitrary mixing volumes at pipe junctions, since now the actual size of the volume can be determined from the pipe dimensions and parameters.

[mwetter]

@bramvdh91 Is there a specific test model that you like me to look at and that reproduces the numerical Jacobian? Setting in Dymola Hidden.PrintFailureToDifferentiate = true; helps diagnosing what causes the numerical Jacobians.

[bramvdh91]

@mwetter The current version of Annex60.Experimental.Pipe.Validation.ValidationPipeAIT on https://github.com/bramvdh91/modelica-annex60/tree/issue264_pipe still shows the numerical Jacobians, both in the initialization problem and in the translated model.

With the option you mention the warning Can only compute non-scalar gradients of functions specifying derivatives and not for: spatialDistribution is generated.

[mwetter]

@bramvdh91 : Dymola writes for

Hidden.PrintFailureToDifferentiate = true;
translateModel("Annex60.Experimental.Pipe.Validation.ValidationPipeAIT");

the diagnostics

Can only compute non-scalar gradients of functions specifying derivatives and not for: spatialDistribution

The only work-around I see is to check whether you can manually differentiate the section

(port_a.h_outflow,
   port_b.h_outflow) = spatialDistribution(inStream(port_a.h_outflow),
                                           inStream(port_b.h_outflow),
                                           x/L,
                                           v>=0,
                                           initialPoints,
                                           initialValuesH);

and if so, put this call in a function and provide the derivative of the function with the derivative annotation.

[bramvdh91]

@mwetter Hey Michael, just to make sure we're on the same line: the new implementation in pipe_issue20_vectorizedPort does not show any numerical Jacobians anymore, in that sense I think it is already a workaround? I referred to the implementation in issue264_pipe in response to your question to show an example where the numerical jacobians do still appear. I'm afraid providing a derivative manually requires diving into the spatialDistribution code, something I'm not at all familiar with...

[marcusfuchs]

@bramvdh91 @GersHub In one of our previous Skype calls we discussed that it may be good to have a model of the resistance part of the pipe model that can be used in your vectorized approach as well as with separate volume models in the pipe path. On branch pipe_issue20_vectorizedRes I implemented such a solution. The resistance part of the pipe is put into the model Annex60.Experimental.Pipe.PipeCore (may need better naming). This core model can be used in your vectorized version of Annex60.Experimental.Pipe.PipeHeatLossMod. This seems to perform well in the Annex60.Experimental.Pipe.Examples.UseCaseAachen.AachenGeneric example. In addition, I added an auto-generated model at Annex60.Experimental.Pipe.Examples.UseCaseAachen.AachenGenericVol that makes use of the core model and Mixing Volumes at each pipe junction. This also seems to perform not too bad numerically.

Could you have a look at this implementation and reply whether this is a design approach that would work for you to continue our joint development on?

[GersHub]

@marcusfuchs : I tested both implementations; I guess we could get rid of the remaining non-lin systems for the implementation in Annex60.Experimental.Pipe.Examples.UseCaseAachen.AachenGenericVo. I like this design approach, but we should discuss how define an appropriate volume size at the junctions. Let's discuss this in the next skype?!

[bramvdh91]

@marcusfuchs @GersHub Looks good! I've simulated now and for both versions I think I get more or less the same translation statistics. Which non-lin systems do you mean, @GersHub ?

[bramvdh91]

This is closed by #73 .