Enrico Remigi WEST Product Owner

<p>Hello Natalia,</p> <p>I understand your dilemma.</p> <p>There's no real plan to include more SST models in Modelica, I thought the set of models is already quite sufficient - only &quot;minor&quot; ones were left out.</p> <p>Is there any in particular that you would need, beside Plosz? If it is only Plosz, I can probably give it a try and make it available for you.</p>

Hello Natalia,<br> intuitively, I would say you are right regarding the piece of code that is to find the maximum: have you tested it? do you get sensible results when you &quot;swap&quot; Layer_Index and Layer_Index+1 ?<br> Regarding your second question: I checked an early implementation of the Plosz model (2017), both variables are declared and never assigned.<br> So I believe they are not present in Modelica, as the result of a code clean-up.<br> <br> /Enrico<br> &#160;

Hello Natalia,<br> in fact both implementations look untidy, if not incorrect.<br> It is possible that the MSL compiler had less rigorous checks and would go through this, while the Modelica compiler simply does not allow for multiple assignments to the same variable (it probably complains about &quot;replicate LHS ...&quot;, left hand side of an equation).<br> <br> Further to that, the 2nd loop may result in another error, related to the 'i+1',<br> I can't remember if the indices go up to 59 or to 60, but if it is 59, then 'i+1' will result in &quot;index out of range'.<br> <br> Either way, that code is doomed :)<br> <br> How about the following? <pre class="linenums prettyprint"><code>for i in 2:59 loop J_G[i-1] = if i &lt;=DynamicIndexOfFeedLayer then if (Help_J_G[i-1] &lt;= Help_J_G[i]) then Help_J_G[i-1] else Help_J_G[i] elseif (i &gt; DynamicIndexOfFeedLayer and i &lt; 59) then if (Help_J_G[i] &gt; Help_J_G[i+1]) then Help_J_G[i+1] else Help_J_G[i] else Help_J_G[i]; end for;</code></pre> Hope this helps<br> &#160;

Hello Hector,

both fine bubble models are based on the Irvine (carbon footprint) aeration model.<br> The difference lies in the way alpha factor is calculated: in model #1, alpha is function of SRT, while in model #2, alpha is function of the solids concentration in the tank.

So the key-difference at the project level is that model #1 exposes SRT, while model #2 MLSS, as a manipulated variable.

Hello Natalia,
first of: apologies for the huge delay in responding, the Forum has been under renovation for a while, and I was not aware it had been back online for so long.
Yes, this kind of situation does occur, and is of course particularly unfortunate.
You are right: generally, there is one specific error message that points to a particular line in the code. One can double-click on the MOF tab and get automatically directed to the line of code in the MO tab page.
In some situations though, the compiler cannot resolve the issue to be associated to one specific line of code, so it spits out the entire code - which is useless of course.
This often happens in connection with vectors - should this help you in any way.
Have you checked the Logging pane? often, if you scroll up, you might locate the actual error message: in these situation, the error message here may be more informative than the MOF/MO pages.
 

Hello Hector,
no it seems to me you did it correctly: I am surprised nothing changes.
Please send your project to our support and we'll investigate further.

Hello Hector,
does your model configuration include a controller, e.g. PI ?
If that's the case, then that may be the issue (I have had the same in multiple occasions).
When you re-initialise a simulation, it transfers the end states of the derived state variables, which is of course generally correct.
It is not correct for the Integ_e variable of a PI controller, that should always be initialised back to zero.

So, if you do have a PI controller, try the following:
- unhide the hidden variables (via the application menu/Options)
- manually reset the initial value for Integ_e to zero

Hope this helps
(btw this is going to be fixed in the next release)

Hello Hector,
sorry for the late reply - we had some issues with the system that was down for a couple of days.
The height in the model is defined as the "mean" height, so I would assume anything between the two figures you have in your drawing.
You know the layered model in WEST (Takacs) may be more detailed than a point, or ideal settler, but still ideal (or an approximation) in terms of the geometrical description of the tank.

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

Hello Hector,
I added the actual calculation made in WEST to your spreadsheet.
I understand your calculation of ISS.
But you should not multiply by that factor: the i_COD_VSS factor already accounts for the conversion of the X components (COD units).