Enrico Remigi WEST Product Owner

Hello
1) you are looking at the default model associated with the icon "aerator". You need to switch to Surface Aerator, via the ClassName property of the block in the Properties pane
2) you most likely need to implement some custom little model then. First, the icon and model for ferric hydroxide are not available when you select ASM1 - but this could switch to ASM2, even if you were not interested in P removal. Second, what kind of impact on C and N removal do you expect? You (we) will have to check whether it is present or not in the model.

Hello,
[quote author=ArtemiiOs link=topic=21999.msg29085#msg29085 date=1592844633]
1) Aeration. Oxygen is supplied by bubble diffusers and surface aerators. I tried to use PI controller blocks to model oxygen supply in compartments, but when I use 2 or more PI a simulations takes ages to finish. I found that aerator Block can be used for diffusers. Is there alternative for surface aerators as well?
[/quote]
It cannot be related to the use of one or two PI controllers, it must be caused by some other setting. Have you checked the Logging? which integrator are you using?
On a side note, if you use an aerator block (either blower or surface aerator), you may need to use a controller (e.g. PI) upstream to the aerator for regulation.

[quote author=ArtemiiOs link=topic=21999.msg29085#msg29085 date=1592844633]
2) Chemical precipitation. Both calcium hydroxide and ferrous sulfate are used. What blocks should I use for them?
[/quote]
Precipitation of what?
In ASM1, the only chemical dosing blocks are for external carbon ..

[quote author=ArtemiiOs link=topic=21999.msg29085#msg29085 date=1592844633]
3) Can I calculate SRT in WEST? If so, how can I do it in my case?
[/quote]
Yes, you are to use a Calculator block and connect it to the relevant blocks (tanks, effluent and sludge sensors).

Hi Mirko,
there are a couple of things in your post ...
[list type=decimal]
[li][b]Loop-breaker[/b]: indeed, it may happen that an algebraic loop be detected due to a controller, i.e. the controlled variable is directly dependent on the measured variable.
Unfortunately, there is no such thing as a loop breaker block for signals (red lines); and the only way to solve the issue is to place a normal loop breaker on a blue connection (flux) in a position such that the data loop is also broken[/li]
[li][b]flow through the membrane[/b]: it's not entirely correct that Qout is constant. The outflow is regulated by the flux through the membrane (J12) which is a manipulated variable, i.e. can be controlled[/li]
[/list]
If you need / prefer to directly control Qout, the only way is to re-write the model somehow in reverse, so that it exposes directly Qout (as an input) and e.g. the flux as an output.

No, not really Hector, sorry. Haven't work on this specific topic.

Brilliant !
Thanks a lot for your persistence. I am sure this will be of great value for other WEST users.

Hi and thank you for this thorough comparison.
Overall, by just looking at the biomass concentration - that you indicate as the most worrying discrepancy between the results in ASM1 vs. ASM2Mod, I would say that it is not all that significant, as a different, given the substantially different model structure.
I acknowledge that you set all the relevant conditions (parameters et al.) to be the same for both implementations.
However, as I say, the model structure is different.
For instance if you consider hydrolysis, ASM1 vs. ASM2 have 2 vs. 3 processes which are conceptually different: you may have set n_h (ASM1) and n_NO_Hyd (ASM2) to 0.4, which will of course result in the same rate expression, but there's a third process in ASM2 (in anaerobic condition, n_fe = 0.4) and, most importantly, the stoichiometry is different in ASM1 vs. ASM2.
The same applies to other processes of course.
So I don't believe you can compare the two models, even by setting all the relevant quantities, and expect exactly the same output - because the structures are inherently different. And that is something you cannot change, by altering parameter values in the project.

As a follow up to this issue: we have revised the implementation in [b]ASM1[/b] and confirm there is an inconsistency in the way T(K)N is calculated in the influent fractionation model, in the tank, in the sensor and in the effluent (defractionation) model.
[u]Case 1[/u]
For the influent and effluent, the [b]default model[/b] does NOT account for the nitrogen fraction of inert soluble COD. Same for the tank model. The sensor however does account for the term, with a factor (i_N_S_I) that is set to 0.01.
One easy way to solve this is to set i_N_S_I = 0 in the sensor. Then the 4 models will be fully consistent.
[u]Case 2[/u]
However, if the inert organic nitrogen was not negligible, one should select the [b]alternative[/b] fractionation and defractionation models (WEST.ASM1-2.Input.Layout.xml and WEST.ASM1-2.Output.Layout.xml) which incorporate the term; and use the i_N_S_I term in the sensor. The only real issue though is that the tank model (Gujer Matrix) would not allow for the same term to be taken into account.

In the upcoming [b]Update 1, rel.2020/b], this will be sorted out:
[list]
[li]the Gujer matrix of ASM1 will incorporate the S_I term for T(K)N[/li]
[li]the default value of i_N_S_I will be set to 0.0 both in the matrix and in the sensor model[/li]
[/list]

If inert organic nitrogen is negligible -> use the default model
If inert organic nitrogen is NOT negligible -> 1) use the alternative fractionation and defractionation ("-2") and 2) set i_N_S_I to the desired value (e.g. 0.01) both in the matrix and in the sensor

I completely agree, of course.
What I actually meant was: I will first make sure that TSSc is meaningful and properly described both in the GUI and in the Models Guide (to avoid confusion); if it should prove to be unnecessary (because in ASM1, the variable TSS is effectively a COD-based, calculated TSS; and in ASM2, TSS could be made into the same COD-based calculation and not just a duplicate of X_TSS), I would prefer to remove TSSc altogether.

[quote author=arspr link=topic=21894.msg28848#msg28848 date=1582879109]
[b]ASM1Temp[/b]
... ASU tanks don't have an i_N_S_I value. Therefore their TKN and TN values are slightly underestimated
[/quote]
Correct. Will fix it with the next SP.

[quote author=arspr link=topic=21894.msg28848#msg28848 date=1582879109]
[b]ASM2dModTemp[/b]
i_N_X_I is 0.02 in ASU tanks but 0.3 in Multiprobe sensors.
[/quote]
True, but the actual value of the parameter may differ depending on the location of the sensor. And it can be changed at the level of the user interface.
The best way to ensure that the same parameter has the same value (if appropriate) across the layout is to create a [b]top-level parameter[/b].

Totally correct: the [b]mod[/b]ification is indeed in the rate expression of those biomass decay processes