Enrico Remigi WEST Product Owner

I believe there are 2 aspects here: 1) you get Q_ByPass when you don't expect it; and 2) the volume never reaches its maximum.
It's hard to say without a quantitative example. However, I could guess the following:
[list type=decimal]
[li]in order for Q_ByPass to permanently be zero, the reactor is to be fed by a flow rate that doesn't exceed its capacity (and given 2, this is not the case) and [b]exclusively[/b] during the "fill phase" - whatever flux would reach the tank during one of the other phases, results in a by-pass. My suggestion is therefore to make sure that the SBR is precisely synchronized with any timer regulating its feed[/li]
[li]once you do not have any by-pass, then provided the integral of the feed flow over the fill phase is smaller than the delta-Volume (max-min), the volume will not reach its maximum and no by-pass will occur[/li]
[/list]

I would imagine everything depends on what kind of control model are you using "between" the PO sensor and the chemical dosing blocks.
For instance, if you take an OnOff, where the output signal "u" is linked to the flow rate of the dosing unit, you could set it up as follows:
[list]
[li]if PO < lower bound, e.g. 0.2-3 then lower or stop dosage (e.g. uOn = 0)[/li]
[li]if PO > upper bound, e.g. 0.6 then increase dosage (e.g. uOff = 50)[/li]
[/list]

The "non-existent key in manager" error usually refers to a block (icon) in the layout for which the underlying model is not present in the current block library.
This may happen because:
[list]
[li]"a" library is found at the expected location (with the expected name) but does not contain that particular model; or[/li]
[li]the original block library (or instance) was changed, e.g. via the Project / Block Library Setup menu - and the new one does not contain that particular model[/li]
[/list]
This may explain why the original project - that used to work fine, does no longer work.

On the other hand, if a block that is used in the scope of e.g. objectives, calculator variables, etc. is deleted from the layout, this same error message will be displayed.

You should be able to retrieve the specific model guide, by using the F1 key (=help) when the (PI) control block is selected on the canvas.
Anyway:
[list]
[li]Y_S = set-point[/li]
[li]K_P = gain[/li]
[li]T_I = time constant [d][/li]
[li]u_0, u_Min, u_Max = no error, minimum and maximum action[/li]
[/list]
Remark: units for Y_S, u_0, u_Min, u_Max, K_P depend on the controlled variable

The easiest way is probably that you use one of the sample input files (in the InputOutput folder) as template - and just replace the figures with your own.
Anyway, the correct format for a data file to be read by WEST is described in the User Guide, chapter 2.9.2 page 57

Correct. And that's because there are 3 anaerobic digestion models in WEST: Siegrist, Lessard-Desjardins (both explicitly written with reference to ASM1 components) and ADM1 (for which only the interface to ASM1 and ASMG1 is available).
Bottom line is: with the standard model library, one can only use an anaerobic digester within ASM1 (or -G1); or, conversely, cannot use an anaerobic digester in combination with P-precipitation.
There may be two ways around.
1) write a dedicated interface, e.g. ADM1/ASM2d (I might have something - I can contact you via email)
2) turn to the plant-wide model (PWM_SA) which incorporates all

Yes: the same icon (chemical dosing) is attached to FeCl3 and other dosing models for P-precipitation - if the right instance is selected, i.e. either ASM2d or 3P_EAWAG. If you are using an instance, e.g. ASM1, that does not model P, those icons are not enabled in the Block Library.

You are right: when a new instance is created, PaletteLib setting is not filled in.
You need to indicate the appropriate PaletteLib.xml file, in order for the new instance to be usable for a WEST project.
However, the browse button - that appears as you click inside the PaletteLib field, is not working correctly (we'll take care of this issue in one of the future updates of WEST).

[b]Work-around[/b]: manually copy/paste the pathname of the relevant PaletteLib.xml file, relative to the BlockLib.xml file, e.g. Icons\WEST.WWTP.CN.PaletteLib.xml

The easiest may be to create a new control model that takes 4 input signals and computes their average - that is then sent out as control action.
Here's a template:
[code]
CLASS Average04
(* icon = "ICONNAME" *)
SPECIALISES PhysicalDAEModelType :=
  {:
    comments <- "A model for a proportional-integral controller with saturation";
    interface <-
    {
      OBJ y_M1 (* terminal = "in_1" *) "Input No.1" : Concentration := {: causality <- "CIN" ; group <- "Measurement data" :};
      // SAME FOR THE OTHER 3 SIGNALS
      OBJ u (* terminal = "out_1" *) "Controlled variable" : Concentration := {: causality <- "COUT" ; group <- "Control action" :};
    };

    independent <-
    {
    OBJ t "Time" : Time := {: group <- "Time" :};
    };

    equations <-
    {
    interface.u = (interface.y_M1 + interface.y_M2 + interface.y_M3 + interface.y_M4) / 4 ;
    };
  :};
[/code]

The signal out ("u") can then be used as input for another control model - that will provide the actual control action you need (i.e. based on the average of 4 DO measurements).
If the latter controller is one of the default WEST control models (P, PI, ..), you could even create a [b]coupled model[/b] which is much more "elegant" and reusable solution - but may also be tricky.

You are right - the values of time are not outputted to the table and, as a consequence, the average and standard deviation of the other series cannot be computed.
It's an unfortunate incident that is going to be solved in SP2 - mid Sept 2014.