Den 4. mars 2013 kl. 15:45 skrev Andreas Lauser: > Hi. > > Am Montag, 4. März 2013, 13:36:10 schrieb Atgeirr Rasmussen: > ... >> Such an abstraction cannot be the only one exposed to a client >> code, > > obviously. The client code should use the structures which express the files > in > terms of semantically meaningful data structures. All I wanted to say was > that > the code which generates these data structures is probably much easier to > write and to understand if the syntax of the file format has been taken out > of > the equation.
OK. > >> if one wants to support the kind of manipulation that is often found >> in such files (i.e. multiply PORV on layer 53 by 1e6 to make a fake aquifer >> etc). > > that's the semantic part. If this part also has to deal with all the weird > syntax of the file format, that's asking for trouble, IMHO… Agree completely. > >> The EclipseGridParser class grew up from a simple keyword + data >> abstraction. I would say that for not-too-complex needs, it remains a valid >> choice. Reading .grdecl files is one such case. > > Of what Bard wrote so far, this basic design should also be applicable to all > eclipse datasets if the syntactic part of the parser deals with the INPUT > directive and the basic representation is a list of (keyword, string*) tuples. > > In my limited dives into the EclipseGridParser code, I got the impression > that its main problem is that it is trying to lump together the syntactic and > semantic parts of parsing. This is true to some degree. Still, we are only discussing an implementation detail. I would rather discuss what a useful interface would look like… And unless Joakim is in a hurry, I would like to resume that discussion after the OPM release… Atgeirr _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
