Suggestions for Temporal Superposition

[geo_curious]

I do see that the error is quite large for the first 200 hours or so. I will focus on that.

[tomfid]

The "reverse the list" step is implicit in the testbed, I think, because the age dimension is time-reversed. Therefore as you move from i1 to iXX,
- age gets bigger. I'll ponder whether I got it backwards, though.

[tomfid]

Comments overlapped. Looks pretty good - hope that was the issue.

As I recall, the 'valid sim' seemed to have a nonzero starting point, so the first 200hr could just be some difference in initialization?

[tomfid]

This is cool. The dynamics now seem to match very closely. It does seem like there's a small bias in the slopes, but seems like that could arise from the Tb->Tf calculation? Also some unit issues to sort out.

[tomfid]

An interesting test would be to feed the benchmark simulator a simple test input, either a step function or a brief impulse. That would make it much easier to compare the responses.

[geo_curious]

This is cool. The dynamics now seem to match very closely. It does seem like there's a small bias in the slopes, but seems like that could arise from the Tb->Tf calculation? Also some unit issues to sort out.

Hi Tom,

This is what I am seeing too. These functions are not great for short time simulations. They were originally intended for long time simulations (decadal scale). The Tb-->Tf translation is definitely a challenge to benchmark here, since there is an equipment performance curve that is usually iterated at each timestep. I may have to switch benchmark simulation tools to hold some more constants for validation.

[geo_curious]

In working on a larger implementation of this method, I have encountered two situations prompting two different questions.
1. If there are elements nested inside of a subscript (e.g., i1, i2, i3, etc.) and I wish to nest (different) elements inside of a different subscript, do I have to change the naming convention of the nested elements? (e.g. x1, x2, x3, etc., instead of i1, i2, i3, etc.) I think I have answered my own question here, which is yes, but I want to record that lesson for others.
2. The terminal of "interval" for this log method of tracking time now seems slightly arbitrary (i262144) given the changes to t and ts in the LN(t/ts) calculation. Should the element value of Interval match FINAL TIME and am I right to think of this as directly tied to model time (hours)?

[tomfid]

1. If I understand your question, yes. Each element needs a unique name, so if you write
i : (i1-i10)
j : (i1-i3)
j will be a subrange of i.

2. The terminal is definitely a little arbitrary - I just picked it because 262144 hours is a lot. It's tied to model time in that the first element is one TIME STEP and each pair thereafter doubles in duration.

The continuous alternative that I included in some versions doesn't have that limitation, so you could use a different (larger - but still reasonable) number of elements and increase duration by something less, like 1.6x (golden ratio) per level.

[geo_curious]

Yes, that makes sense. I am not sure why I mentioned FINAL TIME. Thank you for the clarification.

[tomfid]

Might be because one of my versions had log-uniform spacing of the age elements, between 1hr and FINAL TIME.

[geo_curious]

Tom, In trying to integrate this application with a larger model, I am adding the function to select the array size, which will define the g-function from table data. Unfortunately, how I have it currently set up, the output of the function is not correct and is unchanging. I am not sure what is wrong, but the overall process should be similar to the LN(t/ts) input, albeit with the addition of a size selection that corresponds with the subscript to point at the table data. Would you please have a look when you have a moment and let me know how I can correct this to get the "funct selected" to change over time? I must not be implementing the subscript usage correctly.

[geo_curious]

Admin, if you want to take a crack at this, it may be useful. I am trying to figure out why the toy model here is a constant output instead of a changing output. When I introduced 3 subscripts, instead of 2, it became a constant. The only thing I tried to change was making a selection for array size as a subscript.
I would appreciate any assistance you might offer.

[geo_curious]

I stared at this long enough and found the answer. The question of propagation, which I thought I should avoid in this post - viewtopic.php?t=8438 - was actually the solution. As soon as the user implements a for loop using 'var = sum(something[subscript!])' then variables which equal 'var' will become static. The appropriate way to ensure that this function is changing with ln(t/ts) "dimensionless time" is to only use 'subscript!' at the final equation in which it must be used. Without that the subsequent variables will not see any changes over time from 'var'. I think this case is closed.