Enrico Remigi WEST Product Owner

Very difficult to say ...
I would first make sure that the experiment is actually using the correct input file - not sure how you manipulated the influent file, it may be tricky.
Also: are there other models or data inputs that may interfere and cause the fluctuations you observe?
What kind of model or system are you using?

[i]If these very generic hints don't help, please send your project to[/i] [b]mikebydhi@dhigroup.com[/b]

Now I don't understand what do you have in mind exactly.
The reason why I suggested that way to compute SRT is that I would generally [i]indirectly[/i] control SRT through the rate of sludge wastage. Therefore the chain Calculator block -> Control block -> Pump (e.g. a flow splitter).

Assuming you could directly feed an SRT value to the AS tank (see below), what would be the effect? [b]Can you elaborate?[/b]

From a modeling standpoint, all you can "control" (i.e. feed data to) in a model are its input variables, specifically what is called in WEST the [b]manipulated variables[/b]. If you take a look at the MSL code, these are interface variable that are flagged with: [tt]manip = "1"[/tt] .
So, yes: for the standard AS tanks, there are only 2 manipulated variables, i.e. temperature and KLa.
Now, from a purely technical point of view, if you would like to feed the SRT to an AS tank, all you need to do is:
[list]
[li]define a manipulated variable called e.g. "SRT"[/li]
[li]add (at least) one equation that makes use of the new variable[/li]
[/list]

You need to 1) compute the SRT and 2) feed the signal to a controller.

To compute the SRT:
[list]
[li]use the "Process Calculator" block (only one model associated, namely: "OperationalParameters")[/li]
[li]feed the relevant inputs: volumes and MLSS of the AS tanks; flow rates and TSS concentrations of the effluent and waste sludge flows. There are some limitations in the number of such tanks and flows, you may need to do some clever manipulation ...[/li]
[li]the sludge age is presented as SRT (state variable) or y_SRT (interface variable). However, this is the [b]instantaneous[/b] SRT which may be fluctuating too much to be given as input to a controller.[/li]
[/list]

You may want to use the "Data Treatment" block (model: "MovingAverage") to compute a more stable (and realistic) SRT:
[list]
[li]feed the y_SRT of the Process Calculator as input[/li]
[li]set an appropriate time window, e.g. 7 days[/li]
[li]the [b]averaged[/b] sludge age is presented as y_M[/li]
[/list]

Now, feed the y_M of the Data Treatment to a suitable control model.

[i]Watch out for algebraic loops[/i]!

The standard control blocks in WEST are generic and can therefore be used both for feed-forward and feedback control loops.
What exactly would you like to achieve?

[quote]
to control the concentration of ammonia .. based on the recycle flow rate
[/quote]
I would use a [b]control block[/b] (different models are available, e.g. "PI") that receives the flow rate ("Q_Out2_Actual") as input signal and controls the "kLa" of the ASU tank.

[quote]There is no control valve ..[/quote]
Control valves are called "[b]fraction[/b] flow splitters" in the Block Library.

I don't understand what you mean by:
[quote]I tried using flow sensor, but it is not worked out[/quote]
Can you elaborate?

The error you got in the first instance was due to a calculator variable of an original set that was [b]deleted[/b].
In 2014, there's a flaw whereby deleting a calculator variable from a set does not re-arrange the IDs: for instance, if variable #4 was removed, variable #5 would not shift to #4. This would generate the error you indicate.
[u]Solution[/u]:
[list type=decimal]
[li]go to the Calculator Variables dialog (right-click in the layout and access the context menu)[/li]
[li]manually reset the relevant ID's using the respective [i]counters[/i] (or directly typing in the numbers)[/li]
[/list]

Another way is indeed the one you indicate, i.e. manually delete (or re-sorting) the calculator variables, [b]in the experiment file(s)[/b] (*Dynamic or *Steady State.ObjEval.Exp.xml).
However, you should not delete the file altogether, but only the relevant lines in the file - by opening it in a text editor.
[i]I would however not recommend this 2nd route: too risky![/i]

We need to make a distinction here.
With a [b]WfDESIGN[/b] license the [b]Model Editor[/b] is not accessible. One could however modify (or even add) models, using a text editor. I would evidently not encourage this, because chances of making all kind of mistakes this way are endless ...
The Model Editor (accessible with [b]WfOPTIMIZATION[/b]) is a dedicated environment with all kind of support for editing models.

The other part of your question is also very relevant.
Indeed I would always recommend to [u]create variants of standard models[/u], rather than altering them with the risk of affecting other projects/models.
In your case, I would proceed as follows:
[list type=decimal]
[li]make a copy of the base class "SBRPointSettler" and call it e.g. "SBRPointSettler_ContinuousFeed"[/li]
[li]modify the relevant equation(s) in the new class[/li]
[li]now, make a copy of the base class "SBRPointsettler1PhaseReact" and call it e.g. "SBRPointsettler1PhaseReact_ContinuousFeed"[/li]
[li]I assume you can leave the original implementation, except for the class that it inherits from:[/li]
[/list]
Instead of:
[code]EXTENDS SBRPointsettler WITH[/code]

you will have:
[code]EXTENDS SBRPointSettler_ContinuousFeed WITH[/code]

One last remark: also take a look at the [b]CFCD[/b] (continuous flow & continuous decanting) and [b]CFID[/b] (continuous flow & intermittent decanting) models. I don't think they are ideal for your situation, but worth exploring.

The only option you have is to create your own variant of the base SBR model of WEST.
The [b]key-equation[/b] you will need to modify is the one that implements the by-pass flow.
And thank to the hierarchical structure of the WEST library, you are to do this only in one place: a base class called [b]SBRPointsettler[/b] that all the individual SBR models inherit from.

At around line 190 of the wwtp.base.SBR.msl, you find the implementation of [b]state.Q_Bypass[/b].
For the standard SBR models, the by-pass is active (and equals Q_In) in all phases, but the fill phase (T1).
All you need to do, to allow feed in other phases, is to [b]turn off (= 0) Q_Bypass in those phases[/b].
For instance:
[code]
state.Q_Bypass = IF (independent.t < interface.T_Launch) THEN 0.0
  ELSE IF (independent.t - state.t_Begin < interface.T1) THEN 0.0
    ELSE  IF (independent.t - state.t_Begin < (interface.T1 + state.T2)) THEN 0.0
      ELSE IF (independent.t - state.t_Begin < (interface.T1 + state.T2 + interface.T3)) THEN state.Q_In
        ELSE IF (independent.t - state.t_Begin < (interface.T1 + state.T2 + interface.T3 + interface.T4)) THEN state.Q_In
          ELSE state.Q_In ;
[/code]
will allow feed during both fill- and reaction (T2) phase.

Please send your case to mikebydhi@dhigroup.com: I will take a look.
And post an answer here, should it be relevant for other users.

There may be two ways to achieve what you're asking:
[list]
[li]you could probably make use of the parameter "[b]T_Launch[/b]" and set to 0 for the first tank and 3h for the second tank; or[/li]
[li]use a [b]timer to control the feed[/b] to the tanks, e.g. connected to a fraction splitter that directs the flow to either tank every 3h[/li]
[/list]