> On 15. Apr 2022, at 13:07, Dmitry Pavlov <dmitry.pav...@outlook.com> 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 <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 <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 > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
_______________________________________________ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
