• RE: When error message has no error in it

    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;
  • RE: Aerator block

    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.

  • RE: When error message has no error in it

    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.
     
  • Re: How to smooth results

    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.
  • Re: How to smooth results

    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)
  • Re: Height of the clarifier

    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.
  • Re: Lack of correct initialization in some blocks. (As example PI).

    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
  • Re: “Grit chamber” block in Modelica

    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).
  • Re: “Grit chamber” block in Modelica

    Hello Hector,
    yes it does (should): by reducing the X_ components that contribute to the X_COD.
    I made a calculation table (see image) to show what I mean: do you agree?
  • Re: “Grit chamber” block in Modelica

    Hello Hector,
    in the grit chamber model, the e_inorg fraction of inorganic portion (xi) of the particulate components is removed along with the e_org fraction of the organic portion (1 - xi).
    The calculation of xi is ASM-specific - see image.
    Hope this helps.