problem with reality check compare and step

[LAUJJL]

Hi everybody

I join a small model that illustrates the problem.

The model has just one constant and I want to force that constant to be multiplied by 2 during only one time step or many time steps. In the model joined the duration is one month. There are three runs joined. The first is the base case, rhe second forces the variable 'result' with a compare check and the second forces 'result' with a step. The problem is that whatever the duration, the constant does not come back to its original value, showing that the duration has no utility. To observe the value taken by result it is necessary to add a second variable called result_var equal to result to be able to observe how the constant behaves, as explained in a preceding post.
Where is the problem? Maybe I have not understood something?
Best regards.

[tomfid]

I haven't had a chance to look at the model, but as a workaround could you replace the constant expression with

effectiveConstant = constant + PULSE(...) ?

It sounds like a bug from your description - I'll have a look later.

Tom

[LAUJJL]

Hi Tom

Of course your workaroud works, but I am obliged to add for each test input that I force on the constant a new variable that corresponds exactly to the behavior that I want the constant to conform to. This is exactly what RC is avoiding. It will clutter the model with a lot of variables.
I join a new model with the modification that you propose, but it does not correct the apparent bug or the rc compare and rc step function.
Look at the model and you will see.
Best regards.
JJ

[LAUJJL]

Hi Tom

The reality check that I want to express is very simple.

It is about the value of a business expressed only by how much it was bought (buying price) and the profits made in between the time it was sold (selling price) sold. One of the numerous RC is that the closer to the selling time the more influential is a result. For instance, suppose that at the time 10, the result is 100 and at time 15 the result is too 100, if you double both results one after the other, the doubling of the time 15 result will increase more the selling value than the doubling of time 10.
To express this with a RC is not evident because RC generally say that this behavior generates that other behavior. I push the assertion a bit further and say that a certain change in a behavior generates a certain change in another behavior. I must then compare two different changes.

To do that I must build a basic behavior for instance increasing the result at time 10 and build a RC that compares increasing the time 15 behavior to the base behavior at time 10 and verify that the selling value at time 15 is greater than the base one at time 10.
To do that I need an increase of time one time step for instance at time 10 from a base case that compares the selling price some times later to that same base case where there is no increase at all.

I must keep the run generated and give it a name say ‘base_case_increase’.

I must then change the name of the run in the RC to ‘base_case_increase’ and with a time that is more than 10. In fact the test input will be : result = rc compare(‘base_case’,result,2,rc start time + time added) to generate the ‘base_case_increase’ run and it will be necessary to change the ‘base_case’ to ‘base_case_increase’ and use a time added > 0. This is a bit cumbersome but I have not yet found something simpler.
But to do that I need a compare check that works for a certain duration, which it apparently does not do.

Best regards.
JJ

[tomfid]

Your model is convincing. I'll add this to the list for the next bugfix release if possible.

Unfortunately, I don't have any easier workarounds to suggest.

Tom

[LAUJJL]

Hi Tom

The problem occurs only with constants. The work around is to build a variable called for instance constant_var = constant and to change the behavior of the variable. This is a bit cumbersome and should be corrected. It is the same problem reported earlier with a constant not showing the values taken by a change in behavior.
I join a model that explains both cases.
Regards.
JJ

[LAUJJL]

There is too a problem with the grace element in the rc step check. I join a model with four runs.
When one puts the grace to 0 with the 'check step variable grace' RC it is ok. But if one makes the same check with the grace equal to 1, there is an error reported. The same error occurs with other RC functions, I do not remember which one. But if one uses a different check the 'check step variable grace corrected' RC, one can change the grace value, it still works, and it should normally not work, because the check is started sooner.
Logically if one increases the grace, there is no reason that the check would not work anymore. It is the contratry that should happen, the higher the grace the more chance the model has to conform to the check.
The reason may be that the grace time is added to the rc start time, so if I substract the grace to the rc start time, the check works again.

I think that the RC functions should be all verified, checking them with different values of the parameters.

I checked the decay RC, the duration works correctly as the variable whose behavior is changed, takes at the end of the duration the value it had at the beginning of the behavior modification.

Regards.
JJ

[LAUJJL]

A possible workaround for the grace problem may be to replace the formulation: var = rc step(grace,var,mult,rc start time,duration) by
var = rc step(0,var,mult,rc start time,duration) :OR: time < rc start time + grace. It works in this case see attache model, but will have to be tested with other functions and circumstances.
Regards.
JJ