Suggestions for Temporal Superposition

[geo_curious]

Hi Tom, I think the approach with subscripts could be simplified. Do I need to retain all of the data in each subscript after the sumproduct calculation is made? As an example, could I remove the X data (time) 0, 1, 2, 3, at current time 4? That way all the X data (either qi-qi-1, or gfunct) is retained for the current timestep but the dataset does not explode in size. Is that possible? After "sumproduct" is calculated, the X data (columns in the vector) can be dumped, I think. That is where all this computational time is coming from. At each new timestep the increasingly large vectors are being recalculated for every time step, but I think (maybe) the sumproduct is all I need to retain from previous timesteps, which is a single number from each timestep. The vector for each current timestep would still remain larger than the operation in the previous, but the data in the vector operation from the previous timestep need not be retained.

Also, each timestep starts with 0 values for all future inputs which is another waste of computing power. If you could, please open up that example I sent previously, maybe run for 1 - 5 timesteps, so you can see below the relevant values are a bunch of 0's all the way to FINAL TIME. If I simply assign :NA: instead of 0 to the SAMPLE IF TRUE, then the current timesteps can also result in a blank. Either way the empty rows of future values are still retained, which is again wasteful.

[geo_curious]

I took a look at the savelist functionality in the documentation and the example models. I think the example I was looking at was under the VensimDemo/Finance folder. It does not appear to have any functionality applicable for this problem. I do not have apriori knowledge of the quantities of energy exposed to the heat exchangers "qi-qi-1" so I do not see the benefit of a savelist at the first model run. I will admit, the savelist functionality documentation is pretty sparse from what I can tell. It looks like it is useful for large sensitivity analysis, but I am not even sure how based on the written information.

I will return to the points that I see as viable -
1. Is there a method of "dynamic" subscripting, where the model can add and remove data from subscripts at different points?
2. Is there a method by which it is possible to not accrue all the expected subscripts at INITIAL TIME, since future values of the subscript data are irrelevant beyond current time? Also, can I get rid of the saved data for vectors from those calculations before current time?
3. Shouldn't this be much easier to solve with a simple external function, since subscripting for each timestep of simulation is too computationally intensive?

[tomfid]

Note that there are two places you can apply a savelist in the Sim Control dialog. The one on the Sensitivity pane only applies to sensitivity runs, so you want the one on the Run Information tab. For starters, you can just check everything, then uncheck the (hopefully few) variables with hourly subscripting.

[tomfid]

The savelist just limits storage and memory overhead. It has no effect on simulation.

There isn't dynamic subscripting, but the rolling update approach I prototyped above is equivalent. The oldest points (8761 hr) are replaced by the newest.

[tomfid]

Looking at this, https://publications.ibpsa.org/proceedi ... -3-A-4.pdf , what you need is an array with log-spaced storage of historical dQ.

[tomfid]

Like this maybe:

log memory 2.mdl

(13.04 KiB) Downloaded 715 times

[tomfid]

Slight improvement to the last term of the dQ diffs and resolution of the smooth version.

log memory 3.mdl

(13.9 KiB) Downloaded 726 times

Resolution does seem to matter. I suspect the smooth version would be good with a somewhat longer vector (but still quite reasonable compared to 000s of hours).

[geo_curious]

Hi Tom,
Thanks for sending this over. That certainly looks interesting. I will have another cleared eyed look at it when I get off the road. This is something that may be worth validating on its own, which would only take about 4 hours. I still have to wrap my head around it more, but the whole thing looks promising.

[geo_curious]

Hi Tom,
I ran a valid-ish comparison with new g-functions. It is not quite identical, in that I am comparing the fluid temperature (from valid simulation) to the borehole wall temperature, but the trend should be similar. I would need to spend some more time with manual data entry and calculations of the fluid temperature in the Vensim model for greater accuracy. Overall, it appears that there are some problems with the borehole wall temperatures from the log memory model. I am not really sure why there is a sudden spike in temperature for the Bore Temp Tb at 6000 hours, for example. Overall, with ongoing cooling operations up to 6000 hours, it is promising but this method needs a bit more analysis before it could be considered reliable.

quick-validate.png (124.03 KiB) Viewed 45103 times

[geo_curious]

Here I have roughed in the fluid temperatures from the log memory 3 model and compared it to a valid simulation run. It is odd, the valid simulation tracks sometimes with the assumptions before the relationship collapses. There is something a bit convoluted about this comparison, however, in that the heat of rejection and absorption from equipment are included in the valid simulation. That does not necessarily relieve the log memory 3 model outputs of their mismatch, however.

quick-validate.png (95.96 KiB) Viewed 44411 times

[geo_curious]

I am uploading a modified copy of the valid data and the modified log memory 3 model. Looking at the original subscript method created, it is hard to match anything in Vensim to the existing industry software output. The quest continues, I guess.

VALIDATION_log memory 3.mdl

(14.76 KiB) Downloaded 584 times

Validation_W_m.xlsx

(409.16 KiB) Downloaded 587 times

HourlyOutputs.xlsx

(229.89 KiB) Downloaded 661 times

[tomfid]

Maybe the industry software is wrong. :O

[tomfid]

Kidding of course, but seems like part of the difference must be initialization. In the HourlyOutputs, column B2, fluid temp starts at 9.58 C, which seems to be the same as Tg=9.6C. But if Tf=Tb+qn*Rb, adding about 12C, the model starts at 21C, and cant match.

Also, I suspect that the resolution of my log-spaced time buckets may be too coarse, but that's an easy fix if the systematic part can be worked out.

[tomfid]

Also ... why does the "load on ground" column C2 in hourlyOutputs differ from the validation_W_m load?

[tomfid]

I think this is on the right track, but you'd have to replicate the more detailed scheme of Claesson : https://buildingphysics.com/download/local_163661.pdf

[geo_curious]

Also ... why does the "load on ground" column C2 in hourlyOutputs differ from the validation_W_m load?

Without looking at this in detail, it is likely the performance curve for the vapor compression cycle. These can differ quite a bit from one piece of equipment to another. Adding complexity to the validation process, the iteration between the inlet and outlet temperature will have to be matched to the same curves (for heating or cooling, respectively). At present I set a fixed dT, but this is likely inappropriate and may take on a square root relationship for example, where the equipment becomes more efficient as the load size increases - therefore, improving the dT. I will look at Claesson, but it may not be the same implementation. There are several variants on the line source method now, which black box software is not necessarily transparent about.

[tomfid]

I tested your model above with a 1hr uniform time vector, and it still doesn't match the benchmark model, so the difference must be some other aspect of the computation.

[geo_curious]

Hi Tom,
I will be honest in that I have no idea what the significance of your 'time scale ts' variable is, but when it is moved to a value of 1 the pattern of temperature response matches perfectly. The amplitude of that response is way off, of course. I really have no idea what to do here as it seems matching efforts based on speculation of behavior cannot be consistent when a user simply parameterizes the problem differently. None of this is matching to Massimo's work, that is apparent.

[geo_curious]

Ok -

I think I see that the variable is simply meant to represent ts. ts is very important for validation in that this term is attached to the dimensions and diffusion of the borehole configuration. I am attaching a modification of the model with an assumed match to the validation run. There is cause to change rho_cp, the volumetric heat capacity, in that the lower values for pipe and grout will result in a better match on temperature. I do not have an exact value for the effective rho_cp, but I can work on it. Either way, the Vensim model is still not responding correctly. The trend, however, looks better with the change in ts. It is still a bit absurdist to me to see the starting fluid temperature of the Vensim runs above the ambient ground temp. I am not sure why that is happening.

quick-validate.png (97.9 KiB) Viewed 31344 times

VALIDATION_log memory 3.mdl

(15.14 KiB) Downloaded 582 times

[geo_curious]

I worked on a few things within this and found an error in an equation for ts, where a_s should be in Joules, not kJ. Otherwise, none of the models actually work. It is apparent that the temporal superposition is not being respected so there is effectively no trend up or down in the temperature over time. That is an impossibility for these systems. Returning to the 5 steps to success:

1. Take in two auxiliary variables as lists of outputs up to the present timestep, gives 2 lists
2. Reverse one of the 2 lists
3. Multiply the two lists by one another at the new index value of each list
4. Sum the new output (a third list)
5. Repeat for each timestep

There is a reason here - the accumulation of heat needs to be accounted for. Looking at the dQ historic Tb from the previous file, in addition to being wrong (probably for parameterization reasons I have not discovered yet), there is no trend - just repetition.

quick-validate.png (56.12 KiB) Viewed 27830 times

[geo_curious]

I tried tidying this up a bit with a dynamic differential temperature, but the parameterization is not simple to achieve a match. The upward or downward trend is still absent.

VALIDATION_log memory 3.mdl

(18.47 KiB) Downloaded 624 times

quick-validate.png (51.3 KiB) Viewed 25022 times

[tomfid]

Ts is the time scale constant for normalization of time in Log(T/Ts). I got the big value from your spreadsheet.

In the new model, Ts is about 4 billion, which seems impossible.

[tomfid]

New version doesn't work due to a change in the spreadsheet - is it the same as the previous edition?

[geo_curious]

Hi Tom,

Yes, ts should be a very big number. When you asked this question, it prompted a bucket of bolts to break loose in my brain. I do see that t, of ln(t/ts) is in hours, and it should be the equivalent seconds. So, it appears that it was not ts that was wrong, but t itself. I have added the variable seconds in hour to the model run. I have not run any RMSE or tuned the dT values, but there is a much better visual match now. The trend also clearly appears as a depletion of the heat source over time with a peak operating temperature of 23C in year 1 and a peak operating temperature of ~14.5C in year 30.

quick-validate.png (63.7 KiB) Viewed 23969 times

quick-validate2.png (43.58 KiB) Viewed 23969 times

[geo_curious]

Reattaching all updated model files and datasets.

VALIDATION_log memory 3.mdl

(18.81 KiB) Downloaded 595 times

Validation_W_m.xlsx

(409.16 KiB) Downloaded 587 times

HourlyOutputs1.xlsx

(1.04 MiB) Downloaded 581 times