[TEST] adding keywords PINTDIMS and SKPRPOLY

[GitPaean]

Test purpose, please do not merge unless requesting so explicitly.

[GitPaean]

jenkins build this please

[OPMUSER]

SKPRWAT, SKPRPOLY and PINTDIMS are not E100 or E300 keywords.

[GitPaean]

SKPRWAT, SKPRPOLY and PINTDIMS are not E100 or E300 keywords.

They are not. As a research platform, OPM will also do things that E100 and E300 do not do.

[OPMUSER]

I understand the need to add additional functionality and keywords, but I think we need to have some way of indicating that this feature and the associated keywords that are non-standard with respect to E100/E300. I have some suggestions, but none of them are perfect:

• Add new section called OPMFLOW that contains all the none standard keywords. That way everything is in the one place and can be easily recognized, but it also has the disadvantage of the keywords not associated with an ECL100 section not being in the section.

• Add two new keywords FLOWSTR and FLOWEND (or something similar) and place all the alternative keywords in between the two aforementioned keywords. This allows the non-ECL100 keywords to be placed in the correct section and yet still be identified.

We have to bear in mind that as OPM Flow matures it is going to be used by more and more users in "production" mode, so we have take into account this user base as well as the research user base at the same time. In time the production users will be a source for funding further development, both for improvements and research topics as well.

I don't really have an answer to this but I wanted to start the discussion.

[atgeirr]

I think your suggested solutions (separate section or keyword delimiters) are too restrictive, but I realize that it can be important to know which keywords are "standard".

What about naming all such keywords "OPMsomething"? The biggest problem is then that we will be limited to 5 characters for the "something" part.

[GitPaean]

If we only add non-standard keywords for the functionalities not supported by the standard E100 simulator, I mean we do not change/expand the existing standard keywords, I do not see the big consequence can be resulted. In the manual, we should tell explicitly these are OPM keywords.

What about naming all such keywords "OPMsomething"? The biggest problem is then that we will be limited to 5 characters for the "something" part.

8-letter length limitation is already not very easy to use when describing keywords for some specific functionalities, 5 will make it much harder. I am not sure for how easy to remove the 8-letter limitation for non-standard keywords, then we can have some more intuitive keyword naming.

[alfbr]

I think we need to have some way of indicating that this feature and the associated keywords that are non-standard with respect to E100/E300

I agree that this is problematic. However, we are only following the example led by E100/E300. There is no way to see from a keyword whether it is supported by E100 or E300. You need to consult the manual to see which it is. We have simply followed the same design principle.

[OPMUSER]

There is some history here with E100 and E300 being developed by two separate teams without parental guidance ;-); hence, the WELXXXX (E100 keywords) and the WELLXXXX (E300) keywords as they were two separate programs unlike VIP and tNavigator that are based on the same code base.

Originally E100 and E300 were documented in two separate manuals because they were two separate programs, that is why there is all this confusion on which keywords belong to which simulator. The problem for Schlumberger at the time was that VIP, a major competitor was the one simulator for both black-oil and compositional formulations. I changing from black-oil to compositional was easy as just changing the PVT section. Thus Schlumberger started merging the manuals and keywords to give the impression that they were the same program, they are two separate programs.

So we should not dwell and the E100 and E300 difference, but how do wish to distinguish between the standard E100 keywords and the OPM Flow specific keywords. What about instead of OPM in front of the keywords what about a period or a $ sign and keep the eight characters for the keyword?

[joakim-hove]

This discussion is interesting - I have moved it here: https://github.com/OPM/opm-common/issues/362