Enrico Remigi WEST Product Owner

Hi,
yes, I understand the confusion generated by the symbol "TSSc".
All you should consider is TSS both in the tank and in the sensor, i.e. "C(X_TSS)" (algebraic state variable) and TSS (sensor) for the tank, and "y_TSS" (sensor) for the multi-probe sensor.
According to your screenshots, those consistently show 4,588 g/m3 - which is the correct value.

"TSSc" is some other calculation, that, in retrospect, should not even be exposed through the GUI.
Thank you for pointing it out - will fix it asap.

Hello and apologies for the slow reaction.
No: it's not possible.

A [b]calculator variable[/b] is effectively a (algebraic) state variable of the overall model - as such, it cannot be linked to an [b]interface variable[/b].
If that is your goal, you should rather implement the same expression inside a model (e.g. a calculator) and expose it through an output variable (sensor). In WEST, you will then be able to link it to the manipulated variable of another model.

Hi,
no, not in the definitions file - that contains a list of include statements for the different instances ...
In the definitions file for your new Instance.
Right before the definitions of the OBJ IndexOf ... you should see the #define StandardCategoryModels.
At least if you're using the latest version, 2017.

In any case, you should be able to perform a string search throughout the library and identify the #define statement to delete.

If you should not succeed, please contact our tech support.

Hi,
the error indicates that, in the scope of your new instance, S_NO is unknown to the compiler.
I assume you have:
1) deleted the S_NO component from the Components vector
2) taken care of all state and interface variables that may use S_NO
And this is all correct, of course.

Now, the only way it would complain about a missing definition (of the OBJ S_NO) for your new instance is that some models are available for the new instance too, without being properly 'protected'.
I can foresee 3 situations:

1) A model is valid only for certain instances, i.e. wrapped within #ifdef explicitly enumerating the instances
Such model can perfectly use S_NO, but will not be available for your instance.
So, no problem here!

2) A model is valid for all 'standard' instances, i.e. wrapped within #ifdef StandardCategoryModels; and contains individual sections for each Instance, e.g. #if (defined ASM1Temp), #if (defined ASM2ModTemp), etc.
Your instance check will fail, because that particular model will be missing the section to be used for your instance.
But the error message will be different ...

3) A model is valid for all 'standard' instances, i.e. wrapped within #ifdef StandardCategoryModels (as for 2); but does not contain individual sections for each Instance.
It may very well be that it uses S_NO that is not defined for your instance.
I believe this will yield the error message you report.

That error message should definitely not occur if you are using ASM1Temp.
Are you perhaps modifying a sample / tutorial / template ?

Try and delete the output block; and place a new one. Then reconnect the clarifier and the pipe.

Setting up the On-Off should be straight-forward:
[list]
[li]it takes the NH concentration in the effluent as input signal (y_M) - you may need a probe block[/li]
[li]it returns 'some kind' of Q_Air as output signal (u)[/li]
[li]u_Min, y_Min: 0, 3[/li]
[li]u_Max, y_Max: 1250, 5[/li]
[/list]
The reason why I say 'some kind' of Q_Air, is that it all really depends on what the on-off controller controls: it may be connected to an aeration model (Irvine), in which case yes, it connects to Q_Air; or it may be connected to a PI controller (simpler solution), in which case it should probably connects to u_Max, i.e. max kLa ...
In any case, what you cannot realise by using the standard, base control models in the library is the 2 min delay by which a second (identical?) on-off model would be triggered. For this, you need to write your own code.

Hi,
I don't see the OnOff controller in your image - only the PI, unless the name / model don't match.
Most importantly, I don't see the ammonia controller - which I assume is on the effluent (or directly on the tank, which may however cause an algebraic loop ...).
How would you implement the 1st and 2nd pump? Two separate aerators? I don't quite understand ...
In any case, I would suggest you consider implementing your control algorithm as a new model, as I am not sure you will be able to realise it by just assembling existing, base control models (that are essentially limited by only 1 input and 1 output).

Hi,
difficult to give you a clear answer ...
The error message is clear: the cardinality (i.e. nr of elements in a vector) of the two terminals you are trying to connect does not match.
Which makes me think there's an incompatibility between the underlying models. This should not be the case for 'regular' ASM models.
Which instance are you using?
And which models are you connecting?

Ops, sorry!
I did suggest to place the tank after the settler. This is clearly nonsense: it should go BEFORE, as you initially suggested.

Hey Hector,
in short: all YES :)
My only remark is that I would place the tank AFTER the primary settler; and not necessarily with a negligible volume - which may result in numerical instability. In that position, there should be negligible oxygen, nitrates and biomass in the stream, thus no significant bioprocess should take place anyway.