On 14. nov. 2014 17:33, wireless wrote:
> 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.
>
#3 is a combination of #1 and #2. I think it's clearer with an example:
LinearSolverIstl solver; // Note that we specify Dune-istl
solver.set_some_option( param1 );
solver.set_some_other_opt( param2 ); // compatible with all solvers
solver.unsafe.set_istl_specific_opt( param3 );
solver.solve();
Alternative #2 is basically no modularity as all, as every solver would
have to be configured specifically, avoiding the point of unifying them
in the first place. #1 wouldn't allow solver.unsafe access. Unsafe
really means unportable, as it basically drops down to whatever
underlying type we're using, for example setting options petsc style.
>
> 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.
>
Ah, yeah. Ok, so today we create a ParameterGroup which basically is a
set of string pairs. Strings are nice and all, but the conversion is
run-time and for all intents and purposes "type-less".
Setting statically would be, say, this:
class LinearSolver {
enum method { CG, AMG /* etc */ };
method m_;
};
LinearSolver::setMethod( LinearSolver::method );
setMethod would translate the -actual- setting to whatever is
approperiate for the underlying solver. Externally only setMethod is
visible, and -this- is statically verifiable - we cannot set an invalid
solver. Strings can be invalid, for example through an unfortunate
misspelling.
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
