Timo,
Thank you. I managed to obtain what I wanted. Yes, I used the lambda in
Parameters::init. I decided not to use MPI at all at this point because
the library currently deals with only light-weight 1D problems.
Best regards,
Dmitry
On 16.04.2022 15:06, Timo Koch wrote:
On 15. Apr 2022, at 13:07, Dmitry Pavlov <[email protected]>
wrote:
Hello,
I am considering a possibility to use a DuMuX program not as an
executable, but as a shared library. In addition, this library is
going to pass the results to caller via memory, rather than storing
.vtu files on disk. Also, the library is to be called more than once,
each time accepting a different params.input, also via memory.
If anybody has done a similar thing, I will be grateful if you share
your experience.
Hi Dmitry,
this should be essentially what is done when Dumux is used through
Python bindings. See below for some pointers.
The issues I see now are:
- Not sure if MPI will remain possible. But multiprocessing is not a
priority in my particular case, since the library will be used mostly
for 1D problems.
What would be the problem exactly? I could imagine that Dumux used the
Dune::MPIHelper at some point to obtain the communicator via the
singleton inside some class.
That would be a problem that needs to be fixed. The communicator needs
to be passed from outside.
Other than that I don’t really see where MPI support would break.
- DuMuX expects params.input to be a file, not a stream. But a more
generic DUNE interface accepts a stream, so I think it will not be
hard to adjust DuMuX's behavior.
Parameters can also be passed via a lambda function to
Parameters::init (see the other function signatures at
https://dumux.org/docs/doxygen/master/a02848.html).
This means you can simply pass parameters stored in a ParameterTree
(which you can read from stream or construct otherwise) or any other
convertible format.
This is the interface I use if I want to e.g. wrap a Dumux simulator
as a single Python driver function (see e.g.
https://git.iws.uni-stuttgart.de/dumux-pub/Koch2019a/-/blob/master/appl/src/msbern.hh)
- Some of the parameters in DuMuX codebase are only initialized once
(grep for "getParam" and "static" on the same line). For example,
assembly/boxlocalassembler.hh:
static const int numDiffMethod =
getParamFromGroup<int>(this->problem().paramGroup(),
"Assembly.NumericDifferenceMethod");
This would be a problem if I wanted to pass different
Assembly.NumericDifferenceMethod with sequential calls of the
library. Fortunately, I do not. Aside from problem-specific
parameters, I want to vary parameters of grid and time stepping, and
it seems that they can be re-initialized, as least for porous medium
flow problems.
This is indeed a problem / bad design. It probably results either from
laziness or comes from some difficulties maintaining
backwards-compatibility when introducing the parameter.
These parameters should be settable from the “outside”, via the class
interface either with dedicated interface functions or by passing a
parameter tree explicitly. Any improvements are welcome.
Best,
Timo
Do I miss any other obstacles?
Is there a consistent pattern in which parameters are initialized
once and which can be re-initialized?
Best regards,
Dmitry
_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
