Compositional well

[GitPaean]

This PR is providing some necessary elements for the compositional simulation with wells. It mostly including the following elements,

1. parsing the schedule keywords WINJGAS and WELLSTRE
2. making PTFlash::solve() can handle arbitrary number of derivatives from the input AD variables.
3. adding WAMF in the summary keywords

The PR can be reviewed and merged by itself without the downstream PR OPM/opm-simulators#6042 .

[GitPaean]

jenkins build this please

[GitPaean]

jenkins build this please

[GitPaean]

jenkins build this opm-simulators=6042 please

[GitPaean]

jenkins build this opm-simulators=6042 please

[GitPaean]

jenkins build this opm-simulators=6042 please

[GitPaean]

jenkins build this opm-simulators=6042 please

[GitPaean]

jenkins build this opm-simulators=6042 please

[GitPaean]

jenkins build this please

[GitPaean]

jenkins build this please

[akva2]

Just a first pass cosmetics

[GitPaean]

The failure is due to the following message,

Error: Unrecoverable errors while loading input:
Problem with keyword WINJGAS
In /var/lib/jenkins/workspace/opm-common-PR-builder/deps/opm-tests/co2store/CO2STORE_GASWAT.DATA line 186
The well 'INJ1' is a producer, not an injector, can not be specified with WINJGAS.

[GitPaean]

The comments are addressed. and remove some requirement for WINJGAS keyword so the jenkins can pass.

[GitPaean]

jenkins build this please

[akva2]

uhm, are we sure it's not just a broken test case? it seems like a very good sanity check to me even if we have to reorder those files.

[bska]

When writing new keyword handlers, we generally prefer to use compiled item names instead of string literals. Other than that this looks good to me, with a couple of opportunities to use move() instead of copy.

[GitPaean]

uhm, are we sure it's not just a broken test case? it seems like a very good safety check to me even if we have to reorder those files.

Basically, the schedule parsing in OPM is in sequential order. We have multiple occasions that some DATA file is parsed by other simulator while rejected by OPM.

The direct issue for this incident is that all the wells are created by default as producers when creating the wells based on WELSPECS,

        Well well(wellName,
                  group,
                  timeStep,
                  0,
                  headI, headJ,
                  ref_depth,
                  WellType(preferredPhase),

WellType::WellType(const Phase phase)
    : WellType { true, phase }
{}

Then we later update whether it is a producer or injector based on WCONP* keywords or WCONJ* keywords.

For the specific DATA file,

the order of the keywords are

WELSPECS
COMPDAT
WINJGAS
WCONINJE

Then it is a decision about whether we want to let this DATA pass.
I am okay to let is pass. If it happens that the well is a producer, then WINJGAS setup is just not used.

I am open with other suggestions also.

[GitPaean]

When writing new keyword handlers, we generally prefer to use compiled item names instead of string literals. Other than that this looks good to me, with a couple of opportunities to use move() instead of copy.

Thanks for the reviewing comments, will come back to address them later to allow other more urgent issue.

[akva2]

yes i understood the problem/point. my question is if we should force sane sequential order. what is the semantics of the input file format? as far as i know, the semantics are sequential where order matters. if this is not actually the case then we indeed have to forgo the sanity check.

[GitPaean]

I think for the problematic DATA files, the way they specify the things, I mean specifying WINJGAS before making it a injector through WCONINJE.

WELSPECS
COMPDAT
WINJGAS
WCONINJE

we should make OPM can handle it. Otherwise, in the future we might face complaining from the user side and asking the users to modify the DATA file is not always easy.

What we can do (not in this PR), we can have a consistence checking for each report steps when all the relevant keywords are parsed.

For example if happens for one report step, the following situation specification happens,

WELSPECS
COMPDAT
WINJGAS
WCONINJE (with or without this one)
WCONPROD

During the consistence checking, it shows indeed WINJGAS is specified for a producer, we should throw and gives helpful instructions for the users.

[GitPaean]

When writing new keyword handlers, we generally prefer to use compiled item names instead of string literals. Other than that this looks good to me, with a couple of opportunities to use move() instead of copy.

Thanks for the reviewing comments, will come back to address them later to allow other more urgent issue.

I believe I addressed the reviewing comments.

[GitPaean]

jenkins build this please

[bska]

When writing new keyword handlers, we generally prefer to use compiled item names instead of string literals

I believe I addressed the reviewing comments.

You did for WELLSTRE, but handleWINJGAS() still uses string literals to identify items.

[GitPaean]

When writing new keyword handlers, we generally prefer to use compiled item names instead of string literals

I believe I addressed the reviewing comments.

You did for WELLSTRE, but handleWINJGAS() still uses string literals to identify items.

Oh, sorry for missing it. now it should be updated.

[GitPaean]

jenkins build this please

[bska]

Thanks a lot for the updates. This looks good to me now and I'll merge into master.