Enrico Remigi WEST Product Owner

You can certainly define a new group, but you will have to handle the corresponding indices yourself - they're not automatically generated.
Or you could add them to the Solubles, if this doesn't have other unwanted implications (I cannot think of any, but watch out).

I guess you should consider incorporating the ionic species into the main component set to get rid of the 'special' ADM1IonComponents vector.
I regret having overlooked this while re-arranging ADM1 into a new Category: it would have made a lot more sense - and would have avoided this hassle now.
We're about going into alpha for rel.2017, so I cannot do much right now; but I could look into this after release.
A Mantis item has been created.

Hi Youri,
I guess you spotted a very key issue here ...
Istinctively I would say that the safest solution be incorporating the ion vector into the component vector (as it's now the case for the gas species, compared to previous versions).
But we'll have to test this out, cannot guarantee it will not result in other problems.

May I ask: in which context do you need an ADM1-only instance? if not too specific, it may be worth offering this for a future version of WEST?

Hi Youri,
no I had not tried it myself ... until now  :)
Indeed it can be tricky but this is entirely due to the 'unconventional' way in which ADM1 is implemented.

I will try and summarise the main steps that you need to undertake:
[list]
[li]duplicate the ADM1 Category and rename (e.g. ADM1Only)[/li]
[li]create a new instance called ADM1Only (leave the checkbox 'create default quantities' checked): it will give you a warning regarding the (already) existing ADM1Only Category but it will reference it corretly[/li]
[li]generate code for the ADM1Only Category (make sure 1) the Namespace for the Components and the Conversion Model is empty and 2) you use a sub-folder, e.g. "ADM1Only")[/li]
[li]include 3 files (definitions.msl, reactions.msl, conversionmodel.body.msl) respectively in wwtp.definitions.msl, wwtp.reactions.msl and wwtp.VolumeASM.ConversionModel.body.msl, wrapped within #ifdef for the new Instance[/li]
[/list]

This is normally enough for a generic new Instance and Category.
However, this is a slightly more complex case because the (original) ADM1 conversion model is included in the scope of the digester class only - precisely because ADM1 is a sub-category of ASM1 (same e.g. for Siegrist).
As a consequence, some quantities, used in the Conversion Model, have been defined outside - in a similar way as for C, Vol, Temp, .. for nearly all other Conversion Models.
So you will have to patiently:
[list]
[li]add " || defined ADM1_Main " in a few places, in order to include a particular class. For instance, in the wwtp.extra.definitions.ADM1.msl file, in order to include ADM1 specific ion related objects[/li]
[li]either modify the new Category ADM1Only (now completely decoupled from the original, so no problem here) or modify some classes, in order to accommodate for the new Conversion Model[/li]
[/list]

As long as the [b]data type of the terminals[/b] are compatible, i.e. carry the same vector of state components.
I could envisage two alternatives:
[list type=decimal]
[li]you will be working in ASM1 (i.e. ADM1 is a sub-category)[/li]
[li]you will create a new instance that uses ADM1 as primary category[/li]
[/list]

[u]Alternative #1[/u]: you could combine a number of digesters (in series or in other configurations) and use the transformers (from/to ASM1) to connect this 'sludge treatment section' to the rest of the plant.
Evidently, if you should need combiners and splitters, you will need to implement suitable classes in the model library - that use ADM1 type terminals instead of the standard In- and OutWWTPTerminal types which carry the main state vector (remember: ADM1 is a sub-category here!)

[u]Alternative #2[/u]: we've been discussing this in the other thread: "Anaerobic reactor with multiple compartments with ADM1".
As soon as the ADM1 Category is the main category of the new Instance, all standard models (or the large majority of) will be usable.

Hi,
it's actually much simpler than what you may think :)
The standard ADM1 digester model, called FixVolumeADU, is what, in the scope of WEST, is termed a [b]coupled model[/b] which means a 'super' model consisting of two or more sub-models.

The FixVolumeADU is associated to the digester icon:
[code](* icon = "anaerobic_digester" *)[/code]

and is made of 3 sub-models:
[code]  sub_models <-
  {
    OBJ Trans_In : ASM1toADM1 ;
    OBJ Tank : ADM1_Digester ;
    OBJ Trans_Out : ADM1toASM1 ;
  };
[/code]

The [b]ADM1_Digester[/b] is the model you are looking for, i.e. the ADM1 digester model stripped of the incoming and outgoing interfaces. But it's presently [b]not 'exposed' in the WEST GUI[/b] for the digester icon.

All you need to do is to hook it to the digester icon, as follows.

[u]Now[/u]:
[code]CLASS ADM1_Digester EXTENDS ADM1_DigesterConversionModel WITH
[/code]

[u]Change to[/u]:
[code]CLASS ADM1_Digester (* icon = "anaerobic_digester" *) EXTENDS ADM1_DigesterConversionModel WITH
[/code]

Hi Youri,
1) earlier today I kind of overlooked one detail: there are 2 occurrences for the Namaspace property. One for the Component vector (this is a Category's property) and one for every Conversion Model. make sure you remove both
2) the error in the base.msl is totally fine ... well  :)
It simply means that you haven't specified a conversion model for your instance. In fact, the error does not occur at that very line but inside the file that is referenced to at that line (or 1 above), i.e. the body.msl
3) regarding the Palette Lib: this is actually an small inconvenient, I mean that it lets you save your Block Library with a non-existent PaletteLib.xml. I guess it will be fixed soon.
Anyway, the reason is that when you create (auto-create, I assume) a new Instance, the Model Editor inputs some string to the PaletteLib.xml that is actually not a genuine palette. So you need to manually copy-paste (yes, there's no browse button yet) a valid one. I suppose the one you find for ASM2dModTemp will work?

/Enrico

Hi Youri,
very easy, I would say.
Please have a look at the 'official' W2016 block library: the [b]ADM1[/b] has been implemented as a Category (i.e. with its own Components and Conversion Model) and used in the scope of the ASM1Temp Instance (as [b]secondary CategoryRef[/b]).

So it's very easy to just create a new Instance which uses the ADM1 Category as main CategoryRef.

The only technical problem I could foresee is that, in order to use a Category (like ADM1) as secondary CategoryRef in the scope of an Instance, that Category needs to use a '[b]Namespace[/b]' - which effectively prepends the two main vectors, Components and Reactions, with the Namespace thus avoiding conflicts with the main component- and reaction vectors.
So I would expect that you will get an error by simply using the ADM1 as main Category in the scope of the new Instance - but I have never tested this myself !

If that should be the case, then I suggest you do the following:
[list]
[li]duplicate the ADM1 Category[/li]
[li]make sure the copy does not use any Namespace[/li]
[li]create a new Instance and point to the copied ADM1[/li]
[/list]

Hope this helps.

Hi Youri,
good question - the "most efficient" ... who knows?  :)

Actually, I have thought about this myself a while ago.
First of all, I would consider [b]decoupling the digestion model from its interfaces[/b] (to/from ASM1) and work with a series of anaerobic digesters (ADM1 state vector flowing through) wrapped between 2 outer transformers. This, at least, avoids unnecessary conversions at every "compartment" which may also result is continuity problems ...
Decoupling the ADM1 from its two interfaces should be quite straight-forward.

Another option I have considered is to [b]split the liquid and the gas phases[/b]: you may want to model the liquid part of the digester in several layers while having one single gas phase on top.
This is slightly more complex because in the standard ADM1 implementation in WEST the gas phase is tightly bound to the liquid phase.

The sum of the N 'virtual' tanks must equal the actual volume of the tank