Simulink configuration option "Treat each discrete rate as a separate task" auto-generates a rate transition at ZOH block when going from lower to higher frequency

Hello all,

Im preparing a simuling discrete model for an aplication that requires autocoding. For that I need to tick the option in configuration parameter 'Treat each discrete rate as a separate task'. However, when I try to run it it doesn't compile due to the different sample times the signals in the model have. Prior selecting that option the model was running fine.

I have created a simple model just to ilustrate the issue (attached). It runs at fixed step of 2Hz, ode4. Two signals are generated at 2Hz and 0.5Hz and are later resampled to 1Hz by ZOH blocks. So, one signal is going from a higher rate to a lowe one (2Hz->1Hz), while the other goes from a slower rate to a higher one (0.5Hz to 1Hz).

With the 'Treat each discrete rate as a separate task' unseleted the model and results are the following:

The results are the ones I would expect, the values before and after the ZOH match at the new sampling rate.

However, when I togle the 'Treat each discrete rate as a separate task' and try to compile the model it throw me an error regarding the difference in rate of the bottom ZOH input and output signal:

The sample time 1 of 'ZOHissues/Zero-Order Hold1' at input port 1 is different from the sample time 2 of 'ZOHissues/Random Number1' at output port 1.

and suggest me different options, all of them seems to generate a similar effect. I have selected the following suggestion just to show the problem:

Compiling the model and seeing the results I get the following:

As you can see the model is introducing a rate transition before the bottom ZOH (with initial condition 0 and sample time of 1Hz) which delays the signal by 2 seconds (1/0.5Hz). I was not expecting that.

I don't see any reason why this new rate transition is necesary when toggling this option since at t=0 the "RandomNumber1" block is generating a value for the "ZOH1" to resample it (similar to what the top line does or what was been done when the option was not toggled). Could someone explain it to me?

I've been trying to delete this behaviour but the only thing that i have achived is to reduce the delay to 1s (changing the configuration parameter from 'whenever posible' to 'never'). Is there any way to remove it?

It seems to me that the model is taking as initial condition the value in the rate transition since -I deduce- it is "compiling first" the blocks that work at higher frequency and then the slower ones (I may be wrong, I have no idea). But for the particular model that im showing I see no reason to do it that way.

Can someone explain me why that rate transition/delay is necesary? or preferably, how to prevent that signal delay while enabling 'Treat each discrete rate as a separate task' ?

Im attaching the model as it is when it fails. Note that I'm working in 2018a... I've not checked if this still happens in the 2025 version.

Thank you in advance.