On 08/27/14 06:54, robert.kloefk...@iris.no wrote:
> I think I have seen one new grid interface per year for the last 7
> or so years. And they were all introduced for very good reasons.
> So I am a little reluctant to enter this discussion again...
>
> Atgeirr
Hi Atgeirr,
thanks for your thoughts.
To clarify, I think a grid interface with one realization of it I would
count as an implementation. A grid that can load
different type of geometric cells I would count as one grid
implementation (e.g. UG, the other UG from Heidelberg).
In that sense I think the DUNE interface is fairly unique by allowing
implementation for different legacy codes. Do you agree?
If you have time you could point me to the 7 examples. It would be very
interesting.
Thanks and regards,
Rob
The myriad of approaches to "grids" is a result also of the new
discoveries in accuracy of a given model based on the grid. Near
wellbore is more accurately modeled with cylindrical grids in
the traditional vertical (injection/production) wellbore. The
computational strain on the simulation is also effected by the grid.
Further out in the reservoir, cubes (perfect 3D squares) work best;
one reason is the nature of the calculation errors found in irregular
geometries, historically. As the geometry of the fractures, the
wellbores, (deviated angles to completely horizontal) and a myriad of
downhole physical/chemical systems are deployed, flexibility in the grid
is paramount for accurate modeling. This is one of the main reasons
grid geometric model representations have been evolving so rapidly.
With an increase in advanced technologies, such as seismic surveys,
fracturing, and an increased incidence of multi zone production, the
situation will continue to require extreme flexibility in the models and
the resulting simulation runs, if a software is to stay relevant, imho.
Like it or not, most simulation solutions are critically judged
by the speed and accuracy of the result; so if OPM makes hard,
inflexible choices in the grid(s), then surely as the technology choices
continue to morph what users what to model, the model becomes deprecated?
In an idealized world (object oriented paradigm) it would be wonderful
if the all grid semantics could be abstracted away form all the other
portions of the codes, including the mathematical engines. Maybe you
would need other modules to interface to the grid module of a given
mathematical engine, so as to translate between a (tightly coupled) grid
with a specific set of mathematical tools (routines).
If this flexibility is not the ultimate goal, how does one experiment
with the model/simulator accuracy, speed of computations and utility by
testing a variety of math components or different algorithmic
approaches? That is to say that maybe the cutting edge of OPM ought to
be centric to a very flexible design that accommodates grid-effected
choice; even hybrid grids. Surely experimentation that is strongly
influenced by the grid choices (or lack thereof) is keenly important?
Ease of (maintenance) coding is also of paramount concern. It's not
merely a "sympathetic" concern, but it also governs the ability to add
new features to the codes. A lack of foresight on maintainability and
portability are far to often valid reasons for project/code deprecation.
How to ultimately abstract the grid from the underlying mathematics
engine(s) is at the heart of future success in modeling and simulation,
imho. I cannot speak to an exact OPM recommendation on grid choices.
hth,
James
___________________
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
_______________________________________________
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
