27. aug. 2014 kl. 10:03 skrev [email protected]:
> Hi all,
>
> > The first is what has been the main focus for the black-oil simulator,
> > the second was made to enable parallel MPI simulations with Dune
> > solvers. The two codes have been diverging lately (some code for
> > transmissibility multipliers was implemented only for the
> > unstructered grid), leading me to think that the current
> > solution with helper classes is not ideal.
>
> 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.
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).
I have some additional cons (no pros…) to add to your points below:
>
> Apart from that here it my point of view on the current situation.
> Please feel free to comment and add on to my list of pros and cons
> below. Please note that my view is not very objective since I know the
> DUNE interface much better then the UnstructuredGrid. So most likely
> there are some comments missing that I would like to ask to filled in by
> people knowing A) better.
>
>
> Among other possibilities that I might not have though about yet I
> currently see the following options:
>
> A) use UnstructuredGrid and drop CpGrid
> 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
> - ….?
Another con:
- harder to collaborate with users of Dune, Dumux or eWoms.
>
> B) use the DUNE grid interface and CpGrid as a representation for corner
> point grids (and by doing so drop support for UnstructuredGrid)
> pros: - well developed (>10 years) and documented, very general
> interface for discretization grids of all kinds
> - support for parallelization
> - support for adaptivity
> - 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
> - 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++)
> - ….?
Another two cons:
- 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)
>
> Please feel free to comments or correct me in case I'm wrong.
>
> As me being a DUNE developer from the first hour I strongly recommend B
> even though it might take a while for everybody to get up to speed with
> the DUNE interface.
In our current situation, we would immediately lose something by going with
either A or B.
The question is if we should work towards making it possible to do it at some
point in the future.
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.
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
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
