Issue422b borefield reverse and sha

[mwetter]

This example illustrates how to configure rectangular borefields, and it illustrates two bugs that need to be fixed.

Before merging it, set in Examples.RectangularBorefields

1. borFie(allowFlowReversal = false). Then, the temperature of the borefield goes down instead of up, and the simuation stops after about 4 seconds as the medium gets belong freezing.
2. xBorFie = 100. This will lead an error during compilation because the string used to compute the sha code is too long.

Could you please correct these bugs and configure the model for these settings before merging it.

[damienpicard]

@mwetter I could not reproduce the error with borFie(allowFlowReversal=false). It runs just fine.

I had a look at the error generated by xBorFie. Digging in the code shows that the error

Error: The following error was detected at time: 0
  Room to allocate string
  Failed condition: stringmark+len+1<Endsimplestring

happens only when calling the c-code crypographicsHash.c.
However, generating the string shaStr and then splitting it up to smaller strings before giving it to the sha function did not help!
I could only solve the problem by generating multiple short shaStr strings.

I'll push a working version of the code.

Notice that my bug fix only solves the problem related to the sha. We can now simulate the model with xBorFie = 50. When I increase the number to xBorFie = 100, I get a buffer overflow for the computation of the g-function.

Error: The following error was detected at time: 0
  Out of memory for reals
It could due to too large matrices, infinite recursion, or uninitialized variables.
You can change the memory size by setting the variable Advanced.RealBufferSize.
  Failed condition: currentMark.place.Realbuffer<EndRealbuffer

The stack of functions is:
Modelica.Math.Matrices.LAPACK.dgesv_vec
Modelica.Math.Matrices.solve
IBPSA.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.gFunction
IBPSA.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.LoadAggregation.temperatureResponseMatrix
IBPSA.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.LoadAggregation.temperatureResponseMatrix(147, borFie.groTemRes.borFieDat.conDat.cooBor, 100.0, 1.0, 0.2, 4.28527701254974E-06, 2.8, 12, 26, 50, 76, 148.4131591025766, borFie.groTemRes.SHAgfun, false)
Error: Integrator failed to start model.

@massimo: could you have a look at the latter. If you cannot solve it, it might just mean that we can only simulate a limited number of boreholes. It would be good to know how many :)

[mwetter]

borFie(allowFlowReversal = false) works now. I am not sure what the problem was. I updated the example accordingly.

[mwetter]

@damienpicard : I refactored the function that computes the sha code as it still lead to buffer overflow in one my examples that has 121 boreholes. I committed the change through dd83751
The trick is the compute the sha of each argument and keep adding this to the next argument.

[MassimoCimmino]

@mwetter We tested this out and it works for us.

If the number of boreholes becomes too large it runs into the following error:

Error: The following error was detected at time: 0
  Out of memory for integers
It could due to too large matrices, infinite recursion, or uninitialized variables.
You can increase the size of 'Integerbuffer' in dymola/source/matrixop.h.
  Failed condition: currentMark.place.Integerbuffer<EndIntegerbuffer

The stack of functions is:
IBPSA.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.gFunction
IBPSA.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.LoadAggregation.temperatureResponseMatrix
IBPSA.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.LoadAggregation.temperatureResponseMatrix(borFie.groTemRes.borFieDat.conDat.nBor, borFie.groTemRes.borFieDat.conDat.cooBor, 100.0, 1.0, 0.2, 4.28527701254974E-06, 2.8, borFie.groTemRes.nSeg, 26, 50, 76, 148.4131591025766, borFie.groTemRes.SHAgfun, borFie.groTemRes.forceGFunCalc)

FixInitials:Init: Intergrator failed to start model.

The Integer buffer size is specified in dymola/source/matrixop.h. I multiplied it by 100 and it allowed me to run your example for 800 boreholes.

[Mathadon]

matrixop.h seems to suggest that the buffer size is 50000?
That corresponds to about 50 kB of memory. You may be able to convince Dassault that this is crazy small and that up to 50 MB is more appropriate..
edit: actually, this buffer is always allocated as far as I can tell.. So that would mean that even the smallest example would require 3x50MB of memory. Still, it can't hurt to ask and see what they do with the suggestion..

[Mathadon]

You could maybe also implement the overflowing implementations using dedicated C-functions instead of using Modelica code.. But that's a bit overkill imo.