> 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.
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
- ....?
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++)
- ....?
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.
Best,
Rob
"This e-mail with attached documents is only for the addressee indicated above. The e-mail and documents may contain confidential information. If you are not the correct addressee or are responsible for transfer of this e-mail with attached documents to the correct addressee, any copying or further transfer of information contained herein is expressly forbidden. If you have received this e-mail by mistake, you are kindly requested to immediately inform me thereof by e-mail and delete the e-mail and the received documents."
http://www.iris.no
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
