Hi, sorry for not contributing to this earlier and sorry for answering to several mails at the same time.
Let me start with CPGrid vs. UnstructuredGrid.
Some when in time Robert and Atgeirr wrote:
>
> A) use UnstructuredGrid and drop CpGrid
This is definitely a non-option. Using UnstructuredGrid as it is as
the only option is not viable. We need to have parallelism and ideally
adaptivity. Both in combination will give us a real edge over
competitors.
But we have to bear in mind that CpGrid as it is will hardly every be
adaptive. The data structures just were not meant for accommodating it. I
am not sure whether this also holds for UnstructuredGrid,
SintefLegacygrid and others.
> B) use the DUNE grid interface and CpGrid as a representation for corner
> Pros:
> - stand-alone grid implementation, no dependency to other
> packages
> - closely related to the MRST framework (that could also be a con)
> - ...?
>
> Cons:
> - no parallelization
> - 2d and 3d grids, no embedded grids (fractures?)
> - grid interface describes data structures not functionality
> - to closely related to MRST data structures?, full feature set of C++
> language is thus not really exploited
> - harder to collaborate with users of Dune, Dumux or eWoms.
> - ...?
> ***** B) use the DUNE grid interface and CpGrid as a representation
> for corner
> [2014-10-21 Di 11:25]
> Pros:
> - well developed (>10 years) and documented, very general
> interface for discretization grids of all kinds
> - support for parallelization
> - support for adaptivity
I quess these three arguments are the main once and very valid. Both
the interfaces for the parallelization and adaptivity are very well
thought through (I am probably biased here, though). Anyway even if we
decide not to use the whole DUNE grid interface (which seems natural
and was the case for Cpgrid, too), we should use this part of the interface for
parallelization and adaptivity. There seems to be a consensus both in
the oil industry (judging from a recent SPE conference), on this list,
and among OPM people that parallelization and adaptivity will give us
an edge here and are key for future research, and competitiveness.
> - meta grids ( ParallelGrid< CpGrid >, FractureGrid< CpGrid > )
> - embedded grids are possible, i.e. surface grids
> - allows for easy exchange of grid implementations
> (Cartesian, unstructured, corner point) which is a plus for
> future research activities
I beg to differ here. One should not forget that CpGrid is not a DUNE
grid in the strictest sense and even for a new development this might
not be feasible given the target discretization methods. (I will show
this later). Here DUNE's opinion of one interface to rule them all
should be challenged. (This is currently not only done by OPM but also
by the Exa-DUNE project. Therefore there is hope that this might
change sometime, read in 5 years ;))
My understanding of a cornerpoint is still very limited. But judging from my
little insight several vertices along the columns are allowed to
collapse to one vertex. Which might allow for elements that are not
directly representable by DUNE reference elements, but only by a
combination of them.
Therefore using metagrids on top of CpGrid or using general
discretization schemes provided by dune-fem and dune-pdelab will most
probably not work.
> - grid interface describes functionality and not data
> structures, thus easy adaptation to future hardware
> - ....?
> Cons:
> - dependency to more dune modules
> - different usage to what people know from coding matlab
> (but then people can still use matlab if they don't like C++)
> - need to re-write a lot of code that is now written using this
> interface, also one
> would need to change approach in many cases (iterating over faces
> for example).
> - it becomes very hard to use OPM for accelerating MRST (although that
> is done only very limited today).
> A + B) build an interface that allows for both grids (GridHelpers)
> pros: - everybody is happy? (fair to Norwegian standards ;-))
> - ....?
> cons: - maintenance for two grid implementations instead of one
> plus
> the maintenance for the interface implementation
> - it is unlikely to come up with a better solution than the
> DUNE interface in a short period of time (say a year)
Some when Andreas answered:
> - the GridHelpers approach always needs to implement a smallest
> denominator
> API of CpGrid and UnstructuredGrid, so it would be
> 'worst-of-both-worlds'.
Let me explain what the GridHelpers really are:
We have UnstructuredGrid that is merely a C-Struct. All the algorithms
in opm-core operate on its member type (mostly C-arrays) directly. The
grid helper are just a set of free functions taking a grid and
returning the members. As CpGrid provides access to most of the members needed
by the functions in opm-core through member functions. In case of
CpGrid the free functions simply call the functions on CpGrid and for
UnstructuredGrid they directly return the members.
Is this the optimal long term solution? No. But it is necessary
intermediate step to not have to rewrite all OPM. IMHO one could even
see this problem originating from an early design decision of DUNE,
namely "all the world is using C++, therefore a DUNE grid is an object
inheriting from a base grid with members inheriting from other DUNE
objects...". This rules out using C-grids without intrusively wrapping
them in C++. Holds also if someone wants to use a third party C++-grid
under DUNE but cannot change the code base.
Therefore the smallest denominator is not originating from the
GridHelpers. It has been there since CpGrid was implemented as it is
(probably for very good reasons, read: targeting just finite
volumes).
BTW it is not a new fact, that DUNE was implemented with
continuous and discontinuous finite element methods in mind. One can
see this e.g. in the implementation of finite volumes in dune-pdelab, which
interprets them similar to finite elements methods as a bilinear and a
linear form containing jump conditions and the space of piecewise
constant function as the test and trial function space. While this is
equivalent to more traditional finite volume formulations, it is
far from intuitive and might be less performing.
Robert and Atgeirr wrote:
> > From my point of view we should first discuss what the current and
> > future requirements for a discretization grid in OPM are.
> > Depending on this we could more easily decide in which direction
> > to go.
>
> I think this is spot on. Our current focus is lowest-order finite
> volume methods,
> for which the current interfaces are acceptable. This is not so
> strange since
> they were written for just such methods (and methods with similar
> characteristics).
> What discretisations are we going to see more of in the future? I
> think DG methods
> and other higher-order variants are going to be more important, and we
> have a lot
> of knowledge on streamline methods we should bring into OPM
> eventually. Both
> of these strain the UnstructuredGrid interface a bit, but not to the
> breaking point.
Spot on indeed and it would be interesting how these strain the
UnstructuredGrid interface.
> If we gain something (in ease-of-programming) from using the Dune
> interface here
> is not clear to me (since we typically target fully unstructured grids
> in the sense that
> cells need not have any reference elements).
For DG: Unlike to your finite volume methods you not only iterate over
facets but also need to iterate over elements. Here using the DUNE
interface (iterating over elements and the facets of each element) is
not performance problem anymore.
But how are you using higher order integration, as needed for higher
order DG, if you do not have reference elements but just the volume of
the element and facets (as available in UnstructuredGrid)?
Some when in time Atgeirr wrote:
> I think one way we could deal with this is moving towards less
> explicit use of grid interfaces in
> the code. The FullyImplicitBlackoilSolver class is a good example in
> that respect, I think.
It is also an example that at some points you still need to access the
grid interface. When I dealt with it the last time, it was quite
interwoven with the algorithms in opm-core that do use the
UnstructuredGrid interface. If you do not want this, you basically
create a new grid interface and copy information from other
grids. (Not sure whether I like this.)
My (very own) conclusion to this discussion at the moment is:
0. Check out the current needs of the algorithms from a grid. I will
start this below. This has to be a guide line for further development.
1. Use and profit from DUNE where appropriate (e.g. parallelism and
adaptivity), but do not let us limit ourselves by adhering to an
interface just for the sake of it when it is actually not needed
(e.g. reference elements, no additional methods, etc.). DUNE as a
guideline is OK, as a holy grail it is not. Nevertheless we should
stay open towards a full DUNE compatibility as it might be needed or
be a low hanging fruit at some time.
2. There is no way around supporting UnstructuredGrid in at least
opm-core and opm-autodiff for some time. I guess noboday wants or
can/has the time/ has the money to rewrite all the algorithms.
3. In the long term we should really try to adapt those algorithms to
work on interfaces rather than on pure data structures and arrays.
In the current state our algorithms do require quite a lot more than
the DUNE interface can provide. Let me give you a non-exclusive list:
- globalCell(). For people not familiar with it, this is the
lexicographic(?) index of the cell in the underlying cartesian
grid. As there might be non-active cells in the grid, this index is
not consecutive. It is used to identify elements (I might be wrong
here) or to attach data to elements. The closest thing in DUNE to
this is the id of a cell.
- random access to both the cell volumes, and cell controids. Not
directly possible in DUNE. But one could use mappers to attach
volumes and centroids via ids.
- random access to both the face normals, and face areas. Not possible
in DUNE. But if (thanks to Andreas and Robert) index and id sets for
faces will excepted then one could attach it.
- iteration over faces. Not possible in DUNE.
- iteration over elements (e.g. for estimateCellVelocity, why is this
needed anyway? Shouldn't velocity be naturally attached to the faces?)
- cell2Faces: Lookup the (oriented) id of the faces attached to a
cell. (Mostly used for calculating properties in
opm/autodiff/{ImpesTPFAAD.cpp|Geoprops.hpp}.
Except for the orientation this is possible in DUNE with
ibegin()/iend() on the elements.
- faceCells(ToEigen) (always 2 for each face!): lookup the ids of the cells
attached to a
all faces. One id is negative if we are at a boundary.
While researching and writing all this, I came up with an idea that I
would like to share:
Rereading my outline about what we need in addition to the DUNE grid
interface and seeing that most of these things can be precomputed, I
conclude that all of these things can be made available for most DUNE
grids. Instead of incorporating these methods into the grid interface
directly, it should be possible to make this available in a wrapper
grid, or meta-grid as Robert et al. usually call it.
This leaves us with the problem of the reference elements, that CpGrid
does not have. But how degenerated can a grid cell be? Vertices can
only collapse along one, two, three or all columns. Therefore each
cell should be representable by a combination of tetrahedrons, right?
Which means any cornerpoint grid should be representable as a
conforming 3D tetrahedron grid. Such a grid (parallel and adaptive) is
available with dune-alugrid.
What would be needed as an intermediate step is converting the Eclipse
representation in opm-parser to a 3D tetrahedron representation that
dune-alugrid can use and a way to write the solution on the unrefined
grid back to eclipse files. Maybe Andreas already has such a thing?
What we gain by this approach:
- We can finally use all DUNE discretizations (dune-pdelab, dune-fem)
with grids coming from Eclipse files.
- We have parallelism and adaptivity without writing another full grid
implementation.
- Due to the meta grid approach we can hopefully still use codes
implemented for CpGrid with the GridHelper classes.
To me this sounds like a rather good approach with fast results within
reach and without forcing us to rewrite all the code base. But as
usual I might be missing something. Hopefully it does make sense
to others, too.
Just my 2 cents, looking forward to your comments.
Cheers,
Markus
--
Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany, USt-Id: DE279960836
Tel.: +49 (0) 160 97590858
signature.asc
Description: Digital signature
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
