Anaerobic reactor with multiple compartments with ADM1

Hi,

What would be the most convenient way to build an AD reactor with multiple compartments using ADM1?

Thanks,

Youri

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.

Hi Enrico,

Thanks for the answer.

If I'm only interested in the anaerobic digester (i.e. not in the water line). How easy would it be to make a new instance based on the ADM1 category? In this way I can reuse all the other models (splitters, combiners, settlers...).


Youri

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.

Thanks Enrico!

So...
- In the block library explorer I duplicated the ADM1 category and renamed it to ADM1Only.
- I deleted ADM1 in the namespace field (now it is blank).
- I created a new instance and called it ADM1 and added ADM1Only to the category references

But when I check the instance I get an error message.
"System error: Parse error at C:\Users\Public\Documents\DHI\WEST\data\blocks\WESTforADM1\Models\WWTP/wwtp.base.msl:357" "wwtp.base.msl, Line number 357"

So, what did I do wrong?

PS: I tried the same procedure with another category (ASM2dM) and it gives the same error.
PPS: When creating a new experiment in WEST with this block library instance an error is produced because no palette library is found (although it looks like it is specified in the appropriate field in the block library).

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

I followed your new recommendations but I still get the parse error. Does it work for you? Could it be due to the fact that there are gases present?

By the way, I named my instance now ADM1Full (just to avoid conflicts with the existing category ADM1). But now I see a newly created category ADM1Full (next to the ADM1Only that I created).

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]

Hi,

I have been going through the code in order to include the necessary classes and to solve the conflicts (e.g. the DO sensor which cannot be defined as there is no element oxygen in ADM1).

But now, I'm stumbling on a problem with an unknown quantity S_nh3 (which is defined as an ion in the ADM1). I'm not sure why this gives a problem.

Even if we are able to solve it. This may give rise to a following question: how to deal with these ions in the combiners, splitters...

Suggestions,

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?

The idea that we are working on is to study the mixing in digesters in more detail.

What is the best way to move this forward?

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.

I guess I have to add the ions to the solubles, right? Or can I make a separate list from it?

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).