In my models I have been extensibly using the qss_switch atomic model. Just now I found a behaviour which I think it is a bug in the code. I made up a very simple model to easily reproduce the problem (below the code and screenshots explanation).
I have an idea on how to fix it which does solve the problem in this small made up model, but I wanted to make sure with you if is the correct fix as it will impact all my other models (which are harder to verify they keep working as expected).
The trapezoidal goes from -1 to 1 is 1sec and crosses 0 at t=0.5 (plotted below in green). Is the input to the switch both in port 0 and 1 (this is to simplify the example. In my models the input may come from different models, but the problem arises when they are synchronised). The switch level=0, so in this example the output (plotted in red) should work similar to a saturation: it should output 0 when the trapezoidal<0 and should output the trapezoidal when it is positive. But as the plot shows it is not:
Problems:
1. The first bug (marked with 1 in the plot) seems to shift the input: at t=0.5 the trapezoid is 0, but the output of the switch is 1.
2. The second bug (marked with 2 in the plot) seems to skip the updates of the input. From t=0.5 to t=2.5 the trapezoid changes 2 times (at t=1 and at t=2). But the output of the switch stays with the first value of the trapezoid (increasing).
Possible fixes:
1. For bug 1, I think it caused by line 113 in the lambda function: if (sigma>0)advance_time(y,sigma,-1);
That line advances the time of the output if necessary, but this was already done in lines 95-98. Thus, it advances the output 2 times, shifting the input.
Commenting line 113 seems to fix the bug, at least in this example
2. For bug 2, I think it is caused by the synchronicity of events arriving at port 0 and 1 in the qss_switch: at t=1 first the event arrives at port 0, and thus sigma is set to 0 programming and immediate output. But then the event also arrives to port 1, it calculates the next level crossing (never), and sets sigma=inf (which overrides the previous sigma=0 so the programmed output is never done).
Changing line 71 as follows seems to fix the bug:
} else if(sigma != 0) {
Adding these 2 changes produce the expected output as shown in the plot.
Nevertheless, it will impact all the qss_switch blocks in all my models, so I wanted to shared this with you to check if the fixes are correct and will not break other parts.
Do you think it is safe to apply these changes in all qss_switch blocks?
Thank you very much,
Matias
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
In my models I have been extensibly using the qss_switch atomic model. Just now I found a behaviour which I think it is a bug in the code. I made up a very simple model to easily reproduce the problem (below the code and screenshots explanation).
I have an idea on how to fix it which does solve the problem in this small made up model, but I wanted to make sure with you if is the correct fix as it will impact all my other models (which are harder to verify they keep working as expected).
The made up model can be found online here: reproduceQssSwitchBug.zip
And looks like this: (online here)
The trapezoidal goes from -1 to 1 is 1sec and crosses 0 at t=0.5 (plotted below in green). Is the input to the switch both in port 0 and 1 (this is to simplify the example. In my models the input may come from different models, but the problem arises when they are synchronised). The switch level=0, so in this example the output (plotted in red) should work similar to a saturation: it should output 0 when the trapezoidal<0 and should output the trapezoidal when it is positive. But as the plot shows it is not:
online here
Problems:
1. The first bug (marked with 1 in the plot) seems to shift the input: at t=0.5 the trapezoid is 0, but the output of the switch is 1.
2. The second bug (marked with 2 in the plot) seems to skip the updates of the input. From t=0.5 to t=2.5 the trapezoid changes 2 times (at t=1 and at t=2). But the output of the switch stays with the first value of the trapezoid (increasing).
Possible fixes:
1. For bug 1, I think it caused by line 113 in the lambda function:
if (sigma>0)advance_time(y,sigma,-1);That line advances the time of the output if necessary, but this was already done in lines 95-98. Thus, it advances the output 2 times, shifting the input.
Commenting line 113 seems to fix the bug, at least in this example
2. For bug 2, I think it is caused by the synchronicity of events arriving at port 0 and 1 in the qss_switch: at t=1 first the event arrives at port 0, and thus sigma is set to 0 programming and immediate output. But then the event also arrives to port 1, it calculates the next level crossing (never), and sets sigma=inf (which overrides the previous sigma=0 so the programmed output is never done).
Changing line 71 as follows seems to fix the bug:
} else if(sigma != 0) {
Adding these 2 changes produce the expected output as shown in the plot.
Nevertheless, it will impact all the qss_switch blocks in all my models, so I wanted to shared this with you to check if the fixes are correct and will not break other parts.
Do you think it is safe to apply these changes in all qss_switch blocks?
Thank you very much,
Matias