On 11/14/14 09:33, Jørgen Kvalsvik wrote:
I have an update and a few questions regarding my project. For
introduciton and details, please see
http://www.opm-project.org/pipermail/opm/2014-October/000664.html
Impressive work!
Alright, next question:
The problem with unifying several solvers is that they all take
different parameters, name options and methods differently etc. Now,
there are plenty of ways to work with this, including:
#1: Lowest common denominator. We provide a specific feature set that we
support and say that our implementation only allows specific
computations. This has the benefit of providing a simple interface that
allows substitution of solvers with easy. The drawback is obviously that
some configuration opportunities are discarded.
#2: Use a dynamic configuration method (such as ParameterGroup) that
basically forwards options to the solver. The main drawback here is that
the solvers really aren't unified at all, as every call to it usually
must be special-cased for every single solver. Of course it then exposes
the full power of the underlying solver.
#3: A hybrid. A well-defined supported interface and operations with an
"unsafe & unportable" feature that allows for direct configuration. This
sort-of breaks encapsulation, but if it is documented as unsafe and is
only used for "emergencies" then I think it could be fine.
With option #1 or #3 some standardized mechanism for translating between
our option "language" and the target solver option setting is needed.
LinearSolverInterface currently doesn't support it directly - it does
allow options to be passed through ParameterGroup, but is not very well
defined in exactly what options should look like. I personally don't
like it because it is impossible to verify statically.
The real question is: what solution do the community think it is worth
going for? If LinearSolver* is to be used then it does require a little
bit more work. Personally I prefer solution #3, but I'd love some
community feedback on that.
Sincerely,
Jørgen Kvalsvik
How about both (1 & 2), eventually. Completing option (1) first will
allow many to "get on board" with this Multi-solver approach. It will
also allow for folks new to OPM to run test data sets and get quicker
results as they set up and customize the use of OPM family of codes. I
predict that many more codes will become "module compatible" with OPM in
the future. Option (1) will facilitate ease of new module integration
and testing with the existing OPM family of codes. I think there are
(many) more areas of OPM that need to be opened up to competing codes,
IFF OPM is to become the open source code base many hope it will become.
ymmv.
Option (2) is really not optional at all, imho. It is the gold standard
that is definitely (critically) needed. Sure option (2) is more work
and will require significant software maintenance, but the ability to
dynamically update parameters without restarting a simulation run
is a keen idea; if I am understating your intentions here? Switching
linear solvers will require a restart of a simulation, but tweaking
(changing existing or employing additional) parameters dynamically
is a very interesting capability to add to any simulator/model. If fact
it could become a "game changer" particularly in areas of history
matching. Also parameter experimentation on how model parameters
(particularly parameters whose values change across the models's cells)
would be an attractive tool for simulation/model studies.
So really the question is do you support option (1) & (2) both, or just
option (2)? (imho). So, also what I have stated above may indeed what
you have in mind in your option (3)?
question: I do not fully understand what you mean in this sentence:
"it is impossible to verify statically" so some elaboration to clarify
what you are pointing out, would be keen.
hth,
James
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
