• Re: Working with ...\data\tutorials\TwoASU

    Not sure I understand ... have you deleted the Aeration sheet, or not?

    If you have, then the parameter (manipulated variable) "y_S" of the control block should become enabled in the Block Details pane, which then allows you to edit its value manually.

    If not, then "y_S" can only be changed through the slider on the Aeration sheet - and being a manipulated variable, this can be done also while the simulation is running.
  • Re: Units of temperature

    Yes: they're the same
  • Re: Not able to set the temperature in aerobic tank

    Hi,
    it is actually impossible: in the tutorial, the OBJ Temp is not associated with an [b]input widget[/b] (1) and is not raised to a [b]top-level interface variable[/b] (2), so it must be perfectly possible to edit it through the Block Details pane (or even the Block Summary pane), both prior to launching and during the simulation (it is a manipulated variable !).

    In case you modified the original tutorial by either using an input widget or a top-level interface, then the OBJ Temp field in the Block Summary pane will be [b]disabled[/b] (which is intentional of course) and it can only be modified through the input widget, in the former case; or through an input file (if the top-level interface is associated to a file) or through the Block Summary pane for the plant level (not the ASU block level!), in the latter case.
  • Re: Plug flow reactor Simulation

    The video should answer your questions, I guess.
    Basically you need to use a soluble, non-reactive substance (e.g. S_I) to model your tracer.
  • Re: Plug flow reactor Simulation

    Hi Iacopo,
    no: there's no specific block / model for plug-flow.
    One would normally mimic the plug-flow behaviour by using [b]tanks in series[/b].
    Please take a look at the "Non-ideal Mixing: Tracer Test" video here: https://dhiwestweb.wordpress.com/videos/
  • Re: Anaerobic digestion modelling using ADM1

    [quote]1) how to define ADM1 into the digester?[/quote]
    The ADM1 model is the default conversion model for the FixVolumeADU class

    [quote]ASM1 in the input and there are transformer which converts ASM1 to ADM1, how?[/quote]
    Correct. Please refer to the Model Guide.

    [quote]where/how to define transformers? Or they are defined by default?[/quote]
    The standard ASM1-to-ADM1 and ADM1-to-ASM1 interface models (transformers) are integrated in the FixVolumeADU class (which is thus a "coupled" model)

    [quote]2) Three output categories are there[/quote]
    Now, you are referring to an influent model right?
    If you use the standard WEST implementation (that is: with transformers included) the output category for the influent specs needs to be ASM1Temp
  • Re: ASM1 or other advanced model

    Dear Joao,
    if you are not going to model P, ASM1 may be the right choice. Especially, if you will be including the anaerobic digestion and biogas generation at a later stage - ADM1 can be smoothly coupled with ASM1.
  • Re: Adapting a model from the default WEST2016 model base to a new category

    Hi Sovanna,
    I have just replied to your email: the [b]same identifier "C" is used[/b] both for the concentration vector (in a base class) and for a Real data type in the scope of your new Conversion Model - which derives from that base class.
  • Re: Adapting a model from the default WEST2016 model base to a new category

    Hi Sovanna,
    the other thing I can recommend you double-check is that you used the [b]Namespace[/b] property for your new category, both for the Category itself (i.e. for the Components vector) and for Conversion Model.

    If this is should not fix the problem, then please send your library through to mike - I will take a look.
  • Re: Adapting a model from the default WEST2016 model base to a new category

    Hi Sovanna,
    actually the error message is very clear in stating that [b]duplicate names are not allowed[/b].
    This may be slightly cryptic but it basically means that you either have declared the [b]same quantity twice[/b] (in two different classes that now, in your new hierarchy are dependent, i.e. one inherits from the other one); or you have used the [b]same name for two different objects[/b] (interface variable, parameter or state variable).
    If this should not ring a bell (you may have an idea of which quantity may be involved?) then the only was is to patiently debug your library, by including one class at a time, commenting out chunks of code, etc.

    I am not entirely sure what you are trying to achieve though ... you say "a new Category, called PSVDM" but: is that truly a Conversion Model (a secondary CategoryRef in the scope on an existing Instance), or rather a new Instance? Why are you duplicating the "sewer.base.msl" file - is this really necessary?