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. > 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... > 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. IMO, it would also be better if the semantic part was was split into a "structure the data" and a "convert to SI units" stage, i. e., doing the conversion to SI-units for the whole structured dataset instead of keyword by keyword. I'm not pretending to fully understand this code, though... cheers Andreas -- Andreas Lauser Department of Hydromechanics and Modelling of Hydrosystems University of Stuttgart Pfaffenwaldring 61 D-70569 Stuttgart Phone: (+49) 711 685-64719 Fax: (+49) 711 685-60430 www.hydrosys.uni-stuttgart.de _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
