Lack of correct initialization in some blocks. (As example PI).

Hi, I think I've discovered an issue in your implementation of initial data.

The best way to describe it is with an example:
[list]
[li]Model whichever plant you want. Be sure it contains: a) constant influent (so Dynamic simulation is just as steady as the Steady State one. b) at least one PI controler (as example: one to get a constant DO measure in an ASU tank with link between DO and Kla). I say [i]"at least one PI controler"[/i] because I know this is one of the conflictive blocks, I don't know if other blocks are affected.[/li]
[li]Run the Steady simulation till it's currently steady. I mean till all the graphs of whichever variable you want are flat lines forever.[/li]
[li]Switch to Dynamic and run the simulation. As the influent is fully constant and Dynamic start point is the ending of Steady State simulation, those very same flat lines are expected in every single variable of the plant.[/li]
[li]But look what you are getting. [b][u]There's some kind of unexpected transient at the beginning of the Dynamic run[/u][/b]. (It is much more prominent in some variables than in other ones).[/li]
[li]The culprit, ([u]or one of the culprits[/u]), is that PI block. If you graph Kla in the ASU tank, you'll see how it ALWAYS start at 0, because that PI block always wrongly starts at 0. There's no way to insert an initial value in its output [b]u[/b] variable (in fact, a value which should have been copied from the Steady State run...) Therefore the ASU aeration is wrongly switched off at the beginning of the Dynamic run.[/li]
[/list]

I really think you should revise this way of modelling blocks. C(X_S) in ASU Tanks, or actually M(X_S), is as needed as initial condition as the previous stored integral part in a PI controler is. If you do not properly initialize ALL the needed variables thorough the model, (not only direct ASMxx concentration/masses), you are going to generate unexpected wrong transients at the beginning of each subsequent run.

A small but important update over the former post.

I hadn't noticed that PI block (and similar in other blocks?) does have a [b]u0 value[/b] as a Manipulated Variable which allow the user to initialize it. Therefore, if you [u][i][b]manually[/b][/i][/u] copy the ending of the Steady State value in that Manipulated Variable, you get a fully smooth transition between simulations.

But I think that's not the way to work. u0 (and any other similar ones in other blocks?) shouldn't be itself an input parameter but the initial value of the state of that block in the very same way M(whatever) variables work in ASU Tanks.

(Just my two cents. At least, I've found a workaround in this case).

Thank you for your detailed explanation.

From a technical point of view, what is copied from steady-state to dynamic, is the end state of the former into the initial state of the latter. But this only applies to "derived state variables", i.e. variables defined through a derivative - this is what requires an initial condition.
Algebraic variables cannot be initialised.
And parameters of course do not change.

We will look into another way to implement those controllers and see if what you report can be avoided.

Hello,
I have a similar issue and didn't find a solution yet. I want [u]steady-state [b]u[/b][/u] value to be the [u]initial [b]u[/b] for dynamic simulation[/u].
I had a look at PI controller MSL file I couldn't find a line where initial conditions are defined - but what was obvious from my simulations is that initial [b]u[/b] was [b]u[sub]max[/sub][/b]. Why is that? And how I could copy steady-state [b]u[/b] to dynamic simulation?
My dynaminc simulation period is quite short so when [b]initial u[/b] is [b]u[sub]max[/sub][/b] it introduces quite a big interferences.

Natalia

Hello Natalia,
I understand.
However, in the current implementation of the PI controller, the variable 'u' is not a derived state. For this reason, it cannot be initialised.
I believe what you could do is to modify the code like:

[code]state.u = if (independent.t <= 0.0) then parameters.u_ini
  else [HERE THE CURRENT IMPLEMENTATION][/code]

It is not exactly what you would like to achieve, i.e. copy the end state of the steady-state to the initial state of the dynamic simulation, but it may be close enough.
You will have to:
1) define a new parameter, 'u_ini'
2) manually set 'u_ini' to the value of 'u' [u]before[/u] you launch the dynamic simulation

Hi, arspr and Natalia,

The fix to your issue is relatively straightforward.

In MSL, within wwtp.main.msl > wwtp.base.controllers.msl > wwtp.base.controllers.pi_saturation.msl and wwtp.base.controllers.pid_saturation.msl

under 'initial', you will find the term 'state.Integ_e = 0.0 ;'

If you comment out or delete this line, there will no longer be an unexpected transient at the beginning of the Dynamic run.