On 2013-03-04 16:06, Joakim Hove wrote:
> EclDeckKW * equil = deck.get_kw(“EQUIL”);
double owc_region2 = equil.get(“OWC” , 2);
As I see it the main challenge will be to embed suffient semantic
information runtime that the parser/deck can make sense out of a
statement like this.
> discussion can resume after the OPM release. Myself and my new
> colleague Kristian will think and fiddle a bit
I also concur that deeper discussion should be taken up again later, but
I just want to give some thoughts while passing by. On a previous
project, we got very far by having the following *lexer* types:
(0) A keyword
(1) An stream which returns a pre-determined count of {int,double}
(2) An stream with a user-determined count of {int,double}
(3) A "record", with fields either {string,int,double}
(4) An stream of either (1), (2) or (3)
and then having the parser choose the next lexer type based on the last
keyword seen. It allowed us to push a lot of accidental complexity away
from the parser.
I think this can even be usable as a low-level interface, with the
records indexable by enums. (The above example would be
deck["EQUIL"][2][OWC] in case anyone wonders) In particular, such a
setup would also be usable from dynamic languages such as Matlab and
Python. And then build a more abstract interface on top of that.
Now, in that project we mostly read the files to get the grids, which
means that there may be some cases where this doesn't apply. However, I
think the simplicity is appealing enough to spend a little time to try
to come up with a counter-case.
--
Roland.
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
