Add pipe with heat loss

[nytschgeusen]

The majority of the case studies of Activuty 2.1 used a thermal pipe model, describing the thermal losses and pressure losses within thermal loops. Up to now the Annex 60 library owns only a adiabatic pipe (Annex60.Fluid.FixedResistances-LosslessPipe). E.g. the the pipe model from the Buildings library or a similar one would fill this gap.

[mwetter]

Created branch issue264_pipe for integration of pipe model.

[marcusfuchs]

I pushed a first implementation of an adiabatic pipe model using the spatialDistribution operator to this branch. In a next step, different options for heat transfer can be tested based on this model. I also included an example that demonstrates the different mass flow rates optained with 2 hydraulic resistances from pipes of 50 m length each compared to a single pipe of 100 m length. The files are in the Experimental package.

[marcusfuchs]

I just pushed the pipe with heat loss implementation presented at the Leuven meeting. This can serve as the foundation for the working group on pipe modeling.

[bramvdh91]

I have just added our previous implementation to my local version of the Annex 60 library. I would like to push it, but I get an error "Unable to access 'https://github.com/iea-annex60/modelica-annex60.git/': The requested URL returned error: 403". Could it be that I first need permission to push to the issue264_pipe branch?

[Mathadon]

You need to have write access before you can push to the annex60 repository directly. It's probably best to fork the library onto your own account and push your changes there and post a link here :)

[bramvdh91]

Thanks for the advice. I've pushed our files to https://github.com/bramvdh91/modelica-annex60/tree/issue264_pipe. I see that a few improvements are still needed to solve some inheritance issues, but the model structure is there already.

[marcusfuchs]

In preparation to the TelCo on the pipe models next week I started a few comparisons between the two implementations (The comparison models are in the pipe examples on the branch). It seems like the KUL implementation, as expected, is ahead on the heat loss implementation while the A60 model seems to behave better at flow reversal. For the simplest case of the lossless pipe, with the same mass flow rate, the flow reversal does not show in the inlet become outlet temperature of the KUL model:

Also, the start values and C and X values are more accessible in the A60 model, which could be an advantage for use of the model with air instead of water.

But I think the systematic approach of the KUL package with lossless pipe as a base for the plug flow pipe is superior to the A60 approach with a TDelay base class. (Also, the icons of KUL are better in my opinion). Therefore, one possible way to go would be to fill the KUL structure of lossless pipe and pipe without heat loss with the A60 implementation and work with the KUL heat loss options on top of that.

[marcusfuchs]

I started combining both implementations by moving a few first KUL models into the Experimental.Pipe package. The new PipeHeatLossKUL model uses the A60 implementation of an adiabatic pipe. Both the A60 adiabatic and lossless pipes have been renamed and use the KUL icons now. I also renamed a few parameters and changed the used fluid properties in PipeHeatLossKUL, so that it is now better comparabale with PipeHeatLossA60Ref. For the temperature delay, both models now seem to work fine for reverse flow.

For a first comparison of the heat loss implemenations in Experimental.Pipe.Example.Comparisons.CompHeatLossPipe I did not yet adjust the heat transmission properties of both pipes, but we can see the general behavior of both models. In the beginning, of the simulation, the KUL heat loss model shows a more dynamic behavior than the rather simple and static A60 model:

When changing to zero-mass-flow, both models fail to address the cooling effects on the fluid:

And for reverse flow, the KUL model shows a bit of a strange behavior as it calculates an outlet temperature slightly below the ambient temperature (5°C in this case)

I will look further into this probably at the beginning of next week, meanwhile I am happy for any input from others.

[carlesRT]

Hi, I have been testing the Annex60.Experimental.Pipe.PipeHeatLossKUL model and about what you noticed;

When changing to zero-mass-flow, both models fail to address the cooling effects on the fluid

The mass flow rate diminish and the outlet temperature does it too. It seems right, qualitatively speaking. Do you expect a higher cooling effect?

And for reverse flow, the KUL model shows a bit of a strange behavior as it calculates an outlet temperature slightly below the ambient temperature (5°C in this case)

I have seen that the value of the delay KULHeatLoss.pDETime.tau was negative (time < tout . Which cannot happen) . It yields a wrong value of the outlet tempertaure.

In this regard, in the model PDETime the delay is calculated as follows,

(,tout) =    spatialDistribution(      time,     0,      x,      true,      {0.0, 1},      {0.0, 0});
tau = td;
td = time - tout ;

According to the (3.7.2.2 spatialDistribution) this is valid/correct if the velocity is always positive.

I am a bit confuse with the relative velocity you calculate and the x value you use ... so I would calculate the delay analog to the temperatureDelay model:

der(x) = velocity;
    (TimeOut_a,TimeOut_b) = spatialDistribution(tin,tin,x/L,velocity>=0,{0, 1},{0, 0});
    if velocity>=0 then
      delay = tin - TimeOut_b;
    else
      delay = tin- TimeOut_a;
    end if;

you can use the velocity calculated in pipeAdiabaticPlugFlow.temperatureDelay

greetings

[bramvdh91]

And for reverse flow, the KUL model shows a bit of a strange behavior as it calculates an outlet temperature slightly below the ambient temperature (5°C in this case)

I have seen that the value of the delay KULHeatLoss.pDETime.tau was negative (time < tout . Which cannot happen) . It yields a wrong value of the outlet tempertaure.

I would like to comment to this that the KUL model was not yet intended to handle reverse flow, since we were only treating networks without loops. As to the use of <x>, I think your implementation works as well, have to admit that the comment for this variable in the original code is vague and probably wrong.

[marcusfuchs]

@carlesRT:

When changing to zero-mass-flow, both models fail to address the cooling effects on the fluid

The mass flow rate diminish and the outlet temperature does it too. It seems right, qualitatively speaking. Do you expect a higher cooling effect?

You are right, I was not precise in my words. What I meant was after the mass flow rate has changed to be 0 for some time, there is no additional cooling of the non-moving fluid standing in the pipe. That is the thing I wanted to address.

And regarding the negative time delay, I think this is a nice thing about our collaborative work here, that we can each extend our models to the use cases of others and have better and more versatile models as a result. If that is ok with @bramvdh91, I will rewrite the delay as @carlesRT suggested.

[marcusfuchs]

I had some problems with the implementation proposed by @carlesRT and therefore used abs(u) instead:

  der(x) = abs(u);

  //Spatial distribution of the time
  (,
   time_out) = spatialDistribution(time,
                                    time,
                                    x,
                                    true,
                                    {0.0, 1.0},
                                    {0.0, 0.0});

  tau = time - time_out;

This seems to avoid the negative time delay, yet it does not yet fix the problem regarding reverse flow losses.

[carlesRT]

What I meant was after the mass flow rate has changed to be 0 for some time, there is no additional cooling of the non-moving fluid standing in the pipe. That is the thing I wanted to address.

ok. I have seen that both pipes use the same equation/approach to calculate the outlet temperature and heat losses but different implementations. PipeHeatLossA60Ref and PipeHeatLossKUL applies energy balance equations to calculate the heat losses to the whole volume of the pipe. If m_flow = 0, then heat losses are zero too. However during this period in which m_flow = 0, the cooling effect is still being considered: delay increases & TOut decreases. If we calculate some heat loss during m_flow = 0 we would need to modify the temperatures in the pipe & maybe the delay time too, or? how to do that?, the information about the pipe temperature is "hidden" in the spatialDistribution operator isn`t ?.

I have seen that the energy balance equation (volume) in PipeHeatLossKUL does not take as inflow temperature the inflow temperature at the current time, but the one after the pipeAdiabaticPlugFlow (it has a delay).

I think the model calculates correctly the heat losses (when m_flow > 0) but with a time shift.

I had some problems with the implementation proposed by @carlesRT and therefore used abs(u) instead:

Did you use velocity = pipeAdiabaticPlugFlow.temperatureDelay.v ? That's how my results look like:

This seems to avoid the negative time delay, yet it does not yet fix the problem regarding reverse flow losses.

This change is not enough to solve the issue with reverse flow losses. In PipeHeatLossKUL during reverse flow you have senTem.T = tempDecay.Tin = tempDecay.TOut. It is necessary to give the correct Tin to the tempDecay block.

During the simulations I found some strange results related to the MixingVolume model. When the mass flow is 0. ExponentialDecay keep calculating TOut this value is used to set the temperature of the MixingVolume. The Temperature in the mixing Volume is changing (= TOut) but for some strange reason the heat flow rate at the idealHeater.heatPort is equal to 0 (m_flow is also = 0). Am I missing something?

[marcusfuchs]

@carlesRT : I was able to get the same results for the temperature delay as you show in the figure for tempDecay.td(new), but I was not happy with that singular bump at the exact moment of flow reversal (marked in green):

That's why I used a different implementation that gives the following result:

This version is now on the branch in file Experimental.Pipe.BaseClasses.PDETime. If you have no objections to that implementation I would continue with this, as it seems to give slightly better results and uses less code.

Regarding the heat losses, we are just starting working on this. We will have a skype conference on that next week, if you are interested we can send you the details via E-Mail. Meanwhile I will look into the behaviour you describe.

For the cooling during zero-mass flow, you are right, the temperature is "hidden" in the spatial distribution. The ideal implementation would nevertheless calculate the cooling effect and adjust the outlet temperature accordingly to get a cooler water flow when mass flow starts again. But so far, we have no perfect solution for that.

[carlesRT]

I was not happy with that singular bump at the exact moment of flow reversal (marked in green). [...] This version is now on the branch in file Experimental.Pipe.BaseClasses.PDETime. If you have no objections to that implementation I would continue with this, as it seems to give slightly better results and uses less code.

You are right the results do not look good... The delay should not drop till 0. However it should be a small step, since when the flow start to flow in the other direction the fluid that entered last into the pipe is the first leaving. (The value tempDecay.td untill aprox 1.4E5 correponds to the delay of the fluid at the outlet port_b).

I tried to use some smooth functions to face this problem without succes.

Regarding the heat losses, we are just starting working on this. We will have a skype conference on that next week, if you are interested we can send you the details via E-Mail.

that would be nice. ty

[bramvdh91]

I am currently thinking about how to solve the problem with the time delay for reverse flow. Just for the record (I presume this is already clear for you, but in case someone new wants to get into the discussion): the spatialDistribution function compares the inlet time (that is passed as if it were a characteristic of the moving fluid parcel) to the time when that fluid parcel is passed to the outlet port of the pipe. Whether the flow can be reversed or not, I think it is a good idea to initialize this distribution as is done with the spatial distribution of the temperatures in the first implementation of the annex60 pipe model. The lack of this initialization seems to be the cause of the initial "dynamic" behaviour of the KUL pipe (rise from 0W to final heat loss). The simplest way would be to assume a constant velocity before initialization, and the corresponding initialization would be a linear distribution from 0 at the inlet to -L/v at the outlet (to be seen which side depending on flow direction.

[bramvdh91]

I think I have found a solution for the time delay of reversing flow (see https://github.com/bramvdh91/modelica-annex60/tree/issue264_pipe). I had to remove the abs(u) to make it work though. Here's a screenshot of the current behaviour, for a simple instantaneous flow reversal: At the beginning, the initializing behaviour is seen again, to be dealt with later. When the flow reverses, the first parcel that exits at the "inlet" or left side of the pipe, it the one that in the previous time step only entered the pipe. This explains the drop to 0 for the time delay. After that, the pipe is a sort of first in first out system, and we see that the time delay rises until the last fluid parcel that has entered during the positive flow, exits the pipe at the "inlet" side. From then on, fluid parcels that have entered regularly at the right side of the pipe exit at the left, and the delay time is the same as before for the positive flow.

This is implemented as follows:

der(x) = u;
//Spatial distribution of the time
(time_out_a,
time_out_b) = spatialDistribution(time,
                                time,
                                x,
                                u>=0,
                                {0.0, 1.0},
                                {0.0, 0.0});

if u >= 0 then
    tau = time - time_out_b;
else
    tau = time - time_out_a;
end if;

So, quasi the same as before, but now both of the spatialDistribution outlets are kept. In order to cope with both negative and positive velocities, the absolute value is removed from the definition of x, and instead the positiveVelocity = true is replaced by u>=0. I think we can avoid the if-statement by defining the time delay as abs(time_out_a - time_out_b). This seems to work both for the simple step as for a case where the velocity is a sine wave: I've left both of the implementations for comparison: the regular tau is the result of the if-statement, tau2 is the absolute difference of inlet and outlet.

Edit: the if statement should have u>=0 as condition.

[marcusfuchs]

I was a bit mistaken about the implementation I proposed, I agree that the abs(u) is too much of a simplification, we really should have a slight bump in tau at flow reversal, as mentioned by @carlesRT.

@bramvdh91, your implementation looks correct in cases with zero-crossing as shown by your examples. Yet, for a period with zero mass flow between positive and negative mass flows your implementation bumps tau to 0. To my understanding, the minimum tau should decrease to is the time the fluid has been in the pipe at zero mass flow. Nevertheless, I suggest to keep the implementation as it is now and not worry too much about the bump to 0. Rather, we could look into how to correctly implement the heat losses. At least for the A60 option with a heat loss model on both sides of the time delay, it would not be necessary to spend efforts on a single correct tau value, as one time delay per flow direction could be used instead.

[carlesRT]

The lack of this initialization seems to be the cause of the initial "dynamic" behaviour of the KUL pipe (rise from 0W to final heat loss).

@bramvdh91 I think so too. The current initialitzation corresponds to the case of a constant temperature in the pipe. I think that for now is sufficient.

@bramvdh91 @marcusfuchs I adressed the tau-bump problematic adding the following code to determine the duration of the m_flow = 0 period.

  v_a =  u >0;
  v_b =  u <0;
  when change(v_a) then
    track1 = pre(time);
  end when;
  when change(v_b) then
    track2 = pre(time);
  end when;
  when time-TimeOut_a > (track2-track1) and v_b then
    reinit(track1,0);
    reinit(track2,0);
  end when;

and modified the limited the tau_a value with the above information as follows:

tau_a = Annex60.Utilities.Math.Functions.smoothMax(time - TimeOut_a,track2-track1,1);

It seems to solve the problem. (I did not find better way to deal with this problem)

@bramvdh91 I did not try to remove the if-statement as you proposed. Not sure if works or not.

I forked the branch into my repository. https://github.com/carlesRT/modelica-annex60.git

I added two pipe models (PipeHeatLossKUL_modified) and (PipeHeatLossKUL_Reverse) both includes a modified pDETime model(pDETime_modified ) as described above. Furthermore the second model has two volumes to adress the reverse flow.

[bramvdh91]

@bramvdh91, your implementation looks correct in cases with zero-crossing as shown by your examples. Yet, for a period with zero mass flow between positive and negative mass flows your implementation bumps tau to 0.

You're right, I did not think of that.

The lack of this initialization seems to be the cause of the initial "dynamic" behaviour of the KUL pipe (rise from 0W to final heat loss).

@bramvdh91 I think so too. The current initialitzation corresponds to the case of a constant temperature in the pipe. I think that for now is sufficient.

@carlesRT Not exactly. The temperature initialization is indeed good as it is now. But the time delay spatialDistribution is initiated with zeros, which would correspond to infinite velocity or a switched flow direction.

@bramvdh91 I did not try to remove the if-statement as you proposed. Not sure if works or not.

For the cases I tested (including the zero flow from the comparison example), this tau2 gives the same result. Does anyone know how both would compare in terms of events generated? I guess the abs function is also based on an if test, so it wouldn't really matter.

@carlesRT, I looked into your implementation and it looks very good, I also agree with the modified delay time. Is it possible to replace the switches in the reverse example by an inStream function in some way? I would also like to start thinking about how to implement a double pipe, that is with supply and return line.

By the way: how do you reference this issue from a commit, such that it appears in this issue tracker? I'm not the best with git yet ;)

[bramvdh91]

I have just added a new comparison, in which no reverse flow occurs. This example is aimed at identifying the influence of the length of the zero flow interval on temperatures at the outlet of the pipe. So far, I have seen that the outlet temperature during periods of zero flow is just kept constant, but I have not yet been able to pinpoint where it comes from. It does appear to me that this value can differ quite a lot depending on the time step chosen for the Annex 60 model, and that for the KUL models (taking the adaptations into account as well, all seem to yield the same result) it is always around the same temperature, but with some seemingly random variation. However, my last run with a very small time step resulted in a zero flow output that is hotter than the original incoming flow in the KUL model... Probably, this temperature does not matter that much, since with zero flow, there will also be no heat flow, but it would be nice to know where it is coming from. Another result that can be assessed is the influence of the cooling effect on the fluid for zero flow: with the KUL model, a longer period of zero flow results in a lower outlet temperature. Below is a screenshot of the outlet temperature comparison. The time step used here is 10 seconds, if you want to reproduce the results.

[marcusfuchs]

I pulled the latest changes from @bramvdh91 and @carlesRT into the repo. In addition, I added an implmentation of the KUL equations within the A60 pipe. This is to test the influence of the switching and processing of tau at reverse flow vs. a stream-based implementation. It seems like the A60Mod version gives the same results as the KUL_Reverse implementation for both comparison cases while it needs a little less calls to the event handler and is a bit faster overall.

I will try to look into the problem described by @bramvdh91 above and also whether we can also add a volume element with heat port into the A60Mod version while keeping the computational advantages.

[marcusfuchs]

Also pulled @k-sartor's additions to the ULg data documentation.

[bramvdh91]

@marcusfuchs I like your implementation of the KUL heat losses combined with the inStream, I have proposed (maybe it's a bit early, but I had an inspired moment) an implementation with both a return and supply pipe together. It extends from the FourPortInterface at this moment, I believe this might need some changes since now I get an error upon checking regarding the allowFlowReversal parameter, which is probably not part of this FourPort version. Also, I need to work on the correct implementation of the thermal resistance parameters. I have not yet worked on examples or tested the component, but wanted to share the idea.

[carlesRT]

Hi have been testing the models and there were two main problems:

1. Difficulty to caculate the delay time for PipeHeatLossKUL_Reverse to adress the bump-problematic.

 v_a =  u >0;
 v_b =  u <0;

The implementation fails sometimes... It was not possible for me to make it work. I think we can definetively discard this boolean option and go as @marcusfuchs sugested

the A60 option with a heat loss model on both sides of the time delay, [...]

1. Wrong calculations of time_out by the spatialDistribution operator

During some simulations I had the problem that the time_out variable used to calculate tau is higher than the real time.

The time at which it occurs does not necessarily correspond to the time at which m_flow swtiches from + to - values or vice versa.

As long as I do not find a better solution to solve this I limit the error with tau = max(0,time - time_out_b);

Besides these two problems. I have seen that the model HeatLossMod calculates fluid velocity with abs(). We need to remove it to calculate the tau in reverse flow. v = V_flow / A_cross;

[marcusfuchs]

It does indeed seem like the spatialDistribution operator introduces noise on time_out_b depending on the chosen interval length for simulation. I have neither found a way to avoid that. I hope to run a few more tests - if we can't find a solution, we may add that issue to the Modelica Tracker. Also, I think that at the Modelica Conference, for the pipe model described in https://modelica.org/events/modelica2015/proceedings/html/submissions/ecp1511879_GiraudBaviereValleePaulus.pdf , they used the spatialDistribution for the temperature delay, but the delay operator on the time delay. So this may also be an option worth testing.

And @carlesRT, please note that in HeatLossMod, tau does not have any effect during reverse flow. During reverse flow, only heatLossReverse uses tau, but within that model fluid is flowing in the design flow direction in that case. So from a functional perspective, there should be no need to remove the abs(). Maybe it can be omitted, though.

[carlesRT]

if we can't find a solution, we may add that issue to the Modelica Tracker.

I think it is good idea.

they used the spatialDistribution for the temperature delay, but the delay operator on the time delay. So this may also be an option worth testing.

I have not work very much with delay, but I remeber i found some limitations using it... Anyway if they used it. It might work for us too.

functional perspective, there should be no need to remove the abs()

if abs() is used, HeatLossMod and HeatLossReverse has the same value for tau.

it should be a small step, since when the flow start to flow in the other direction the fluid that entered last into the pipe is the first leaving.

After remove abs() I have seen that the tau values are sometimes wrong...

[k-sartor]

Here is my little contribution: A limitation of the delay operator is the maximum value of a delay is 20000s (about 5.5 hours). Therefore it should be usefull to limit the delay.

For example this kind of large delay for the temperature could be occured if the pumps are off during a part of the night (it occurs in the control of a little DHN in Belgium).

[bramvdh91]

Hey @carlesRT, if I look at your previous two comments, I see some other strange things going on: in the one where you describe the peak (this looks strange indeed), it looks like no delay is built up for the zero period between the positive and the negative flow. For the last comment, the delay builds up, then drops to zero while the flow is still zero, and starts building up again. Is this a result of the max function you used or am I missing something else here?

@k-sartor, we could also look at the cooling-down of the water in the pipe and take the time it takes to cool down to a temperature that is not useful anymore as an upper bound. After that, we'll have to wait for new hot water anyway. Also, for the zero flow case, the axial diffusion of heat kicks in again. Keeping track of that requires going into the memory of spatialDistribution, or are there easier ways to account for this? I could do some back-of the envelope calculations to see which characteristic times we're talking about for this, but it'll have to wait until next Monday.

[carlesRT]

Hi,

it looks like no delay is built up for the zero period between the positive and the negative flow.

I cannot explain where this strange behaviour comes from... I will try to figure it out.

Is this a result of the max function you used or am I missing something else here?

I think it has nothing to do with the max function but witht the spatialDistribution operator. You will find this strange behaviours already in the time_out_b values.

[marcusfuchs]

@carlesRT, could you please commit an example that demonstrates where the current implementation of HeatLossMod with abs() calculates a fundamentally wrong result in addition to the spatialDistribution noise? I cannot reproduce any such problematic behavior, see e.g.:

[carlesRT]

Yes, I will do that.

But i think you have this noise too:

and about the error using abs() you can see it in the results i posted. (Now highlighted)

[bramvdh91]

Hey all, I tried to implement the time delay with a delay operator, however this does not seem so straightforward as the spatialDistribution of the inlet time. You can see a part of my struggle in my fork, in case you want to give it a try. This version is not working though (partly because I don't know exactly how to work with when statements). The code is based on the following:

ut = delay(u, tau, maxDelay);
der(tau) = 1 - u/ut;

Here, ut is a delayed version of u by the current delay time tau. The delay operator needs a maximum delay to allocate sufficient memory, here we could implement Kévin's suggestion. The delay is then increased or decreased by a differential equation, depending on whether the current flow velocity is slower or faster than the delayed one. The fun starts after a zero flow period, namely when the denominator becomes 0. The delay should be reinitialized after this zero flow, since the differential equation does not keep track of the delay difference between inlet and outlet of the pipe. If we want to account for reverse flow, it becomes even more complex.

[carlesRT]

The fun starts after a zero flow period, namely when the denominator becomes 0. [...] If we want to account for reverse flow, it becomes even more complex.

I think so too.To work with the delay operator is going to be more difficult...I do not see an easy way to calculate a correct tau.

I modified the heatLossMod2 model. During the periods of zero mass flow, the tau was increasing sometimes for boh instances of the heatLoss (correct) others just for one of them (wrong)... The aim of the changes are to be sure the tau increases for both instances during the zero mass flow periods. To do that I used a more "permisive" boolean condition in the spatialDistribution operator.

  epsilon = 1000000*Modelica.Constants.eps;
  if v  >= -epsilon then
    vBoolean = true;
  else
    vBoolean = false;
  end if;
  der(x) = v;
  v = (V_flow / A_cross);
  (, time_out_b) = spatialDistribution(time,time,x/length,vBoolean,{0.0, 1.0},{0.0, 0.0});

In this case, epsilon = 1e-9. I think it will not cause a noticeable change in the results but make the model works. What do you think? The value 1e-9 worked for me in the example I tested, maybe it is good to the define epsilon in a different way as function of the nominal mass flow rate?.

[bramvdh91]

This looks good, but I don't quite understand why the delay of the opposite heatLoss drops to zero some time before the flow starts again. This also makes me think: I guess it is more efficient to keep track of the delay at the pipe level, not at the heat loss level. Whether you are working with one or two pipes (supply and return), the delay remains the same. This will require half of the memory since we halve the number of spatialOperators needed, and this reduction is even more important for double pipe systems.

[carlesRT]

This looks good, but I don't quite understand why the delay of the opposite heatLoss drops to zero some time before the flow starts again.

What I implemented is not a perfect solution and as u pointed out It will sometimes fail. Maybe the spatialDistribution operator has some kind of limit regarding size?

I guess it is more efficient to keep track of the delay at the pipe level, not at the heat loss level.

What u say is right there is no need to calculate tau twice. I tried so many things that I am now a bit confuse.. but If I rightly remember it, when calculating tau at the pipe level we had the problem after the periods with zero mass flow rate -> bump-problematic.

this reduction is even more important for double pipe systems.

If we do not manage to correctly calculate tauat pipe level as u proposed we could for twin pipes, calculate tau just in one pipe ?. As u said,

the delay remains the same.

[bramvdh91]

I tried so many things that I am now a bit confuse..

It certainly is difficult to keep track of all the developments, I am also confused. I think it is good to select the bits that we want to continue with as @marcusfuchs suggested during last TelCo.

[marcusfuchs]

Thanks @carlesRT, this is an interesting solution

This looks good, but I don't quite understand why the delay of the opposite heatLoss drops to zero some time before the flow starts again.

What I implemented is not a perfect solution and as u pointed out It will sometimes fail. Maybe the spatialDistribution operator has some kind of limit regarding size?

You define the switching condition as v >= -epsilon,which is v >= -1e-9 in the shown case. It worries me a bit that the result quality seems to depend on epsilon in a non-predictable way. From testing a few different values for epsilon, it seems like it also determines when the unused heatLoss model's tau drops to zero for no other apparent reason. As in this case we compare v = 0 to a small value, my guess for reasons would be on details of the spatialDistribution implementation in C (rounding?) rather than on a specific size limit.

Nevertheless, your implementation seems to give the best results so far. Therefore, I suggest to keep it as the current benchmark and try to find a robust way to match these results. To this aim, I would suggest looking into:

a) Get stable outputs from spatialDistribution with the current model. (Not sure how to do this, and the current model calls the event handler quite often) b) Revisit the idea of having only one calculation for tau at pipe level, and combine that with the current 2 heat loss models based on stream concept.

I'd rather not revisit the versions with switches and volume models, but that is just my opinion. What do you guys think?

[carlesRT]

It certainly is difficult to keep track of all the developments, I am also confused.

Maybe after the next TelCo we can clean the issue or better post a summary of what we have test & achieve up to date.

It worries me a bit that the result quality seems to depend on epsilon in a non-predictable way.[...]

It is true. Results will depend on epsilon. But I think that the original boolean condition v>=0 is not apropiate, specially when we switch flow directions. The condition is too "week" against any variation in v due too numerics, or any other reason. In this regard, once I get some strange results, where der(x) varied between 1e-14 and -1e-14 during a zero mass flow rate period. Unfortunetlly I could not reproduce this behaviour/results. Anyway I think it is reallistic and acceptable that such behaviors/noise might appear during a simulation, isn it?

Following the same logic, I isolate der(x) of a possible noise:

  if abs(v) >= epsilon then
    flat_v = v;
  else
    flat_v = 0;
  end if;
  der(x) = flat_v;

It gives better results. However results will still depend on epsilon...

a) Get stable outputs from spatialDistribution with the current model

good. We can test the pipe under different boundary conditions and try to see how the epsilon value effect the results, trying to keep its value as low as possible.

b) Revisit the idea of having only one calculation for tau at pipe level, and combine that with the current 2 heat loss models based on stream concept.

good

I would add/suggest a third point, regarding what you said,

model calls the event handler quite often

c) To use the flag "AllowFlowReversal" to switch between two approaches to calculate tau. We have seen how it is easier to model one-flow direction the spatialDistribution.

[bramvdh91]

Hey all, based on @carlesRT 's implementation with the epsilon condition for zero flow, I've built a model that could be included at the pipe level and that would output one time delay for both reverse and forward flow. It looks like I have found another way to fix the discontinuity in the time delays. In the commit referenced above, I've altered the input of the spatialDistribution such that at zero mass flow, not the current time but the tracked time is logged. This fixes the drop to 0 of the time delay when the flow starts again with a flow reversal. It does involve quite a few when- and if-clauses, and I think it is good to compare the different options in terms of number of events generated and CPU time. Here's a screenshot of the solution of Annex60.Experimental.Pipe.Examples.TimeDelay.PipeLevelDelay as you can find it in my fork.

[bramvdh91]

I've made a comparison between the case where the time delay is tracked in the HeatLoss operator and the case where the time delay is stored one level higher. The latter seems to generate more events as expected (//2 in the graph is the PipeLevelDelay), but the CPU time is slightly lower for this example. You can find both examples under Annex60.Experimental.Pipe.Examples.Comparisons.Events.

[carlesRT]

I ran the models DelayInPipe and DelayInHeatLoss. The EventCounter plot is the same however the CPUtime plot is slightly different. In my results the lower CPUtime corresponds to the model DelayInHeatLoss. we actually expected the opposite results (DelayInPipe more efficient than DelayInHeatLoss)... didnt we?

[bramvdh91]

Hey Carles, that seems strange. I considered that I might have mixed the plots up, but after testing again, I got the same results as in the plots above. I will try the difference for the two pipe model tomorrow.

[carlesRT]

Hi, I ran the models again and the CPUtime were really close to each other, almost the same. Ran it again but for a ten times longer simulation time and setting periodic boundary conditions. Resuls show DelayInPipe to be faster. The results might depend on many factors such as computer (hardware) or solver. I guess the simulation time of the example was two short for my computer to notice any difference.

[bramvdh91]

I was looking into the heat loss calculations just now and I noticed that the parameters A_surf and in the HeatLoss components are not used (anymore). When we clean up the components that we don't need anymore, we can remove these parameters in my opinion. We can of course discuss this in more detail during the TelCo today.

[bramvdh91]

To comment on the latest status of my fork: I have corrected the implementation of the double pipe model (the example showed that it was not completely working as it was supposed to). I have also compared the time delay calculation on pipe and HeatLoss level, and again I have found that on my computer the pipe level model calculates faster, with a slightly higher count of events. However, since the reduction of spatialDistribution is by a factor 4, the difference between the CPU times is larger than for the single pipe. As @marcusfuchs said, there are still some instabilities in the delay calculation (I thought we had solved those, unfortunately this seems not to be the case). After we have cleaned up the pipe package, I would like to investigate the difference between the double pipe simulation and just simulating two separate pipes, because I suspect there is not too much difference. Attached is a screenshot of CPU and events for pipe level (solid) and 4 separate time delays (dashed).

[carlesRT]

As @marcusfuchs said, there are still some instabilities in the delay calculation (I thought we had solved those, unfortunately this seems not to be the case).

I reviewed the history of the model and It seems that the strange behaviours in the model began when we started to "mess" with the spatialDistribution operator when trying to solve the bump-effect. I think the best we can do is to go back, using a simple definition of tau and solve the bump-effect separately.

In my fork you will find a model, /Comparisons/SpatialDistributionOperator used to test different blocks used to calculate the tau. commits (ae397484c3d8c70b3c99a809183cd805004649a6 and 922588af073878741927dc806c50963996ea58d7) About the example:

• The pipe models calculates values for tau completely different than the spatialDistributionOneDirection block altough the definition for tau is the same.
• The block spatialDistributionTwoDirectionsAndTrack seems to do what we need.

[bramvdh91]

I have fixed the DoublePipe model, see pull request #414 for a discussion on using only one of the two Medium and allowFlowReversal parameters in PartialFourPort.

[bramvdh91]

Currently, the pipe models take an ambient temperature input in Celsius only. Regarding integration with simulation info managers, it would be interesting to make this a real temperature value, since if Kelvin is supplied as an input, the heat losses are wrong (i.e. heat gains).

In my latest commit, I have implemented a method which I believe is a bit more robust than the current calculations, based on h = c*T. For the double pipes, this seems to work properly. However, for some of the single pipe examples, some strange peaks occur (where the outlet temperature rises far above the inlet).

[carlesRT]

During the last Skype conference we checked and discussed the validation examples. Regaring the example ValidationPipeULg, I got confused with the parametrization.... The original data PipeDataULg150801 yields good results. (Corrected in 996ba33 and 6b8f885).

About the spatialDistribution, I still try to figure out how to make it work properly...

The following simple code works,

(time_out_a,time_out_b) = spatialDistribution(time,time, x/length, v>=0, {0.0, 1.0}, {0.0, 0.0});

Correct values of time_out_a and time_out_b are obtained. However when the block is linked to the pipe model, it means the values of time_out_a and time_out_b are used to calculate a delay and heat losses the values of time_out_a and time_out_b are wrong.

I tried to use noEvent(), different implementations, but I cannot manage to make it work.

I also tried different solvers, Correct results are obtained with Euler, Rkfix2,Rkfix3 and Rkfix4. With the other solvers I got wrong results.

Suggestion are very welcome.