Inconsitencies with the solver constructors (ParserView, cmd line passing)
Note: This is a minor long term issue.
I noticed (once again) that we have inconsistencies in the handling of the user solver constructor, the abstract solver constructor and the user init
function, all this for FV, ADERDG and LimitingADERDG solvers. While the Command line options passing (std::vector<std::string>& cmdlineargs
) is mandatory in all solvers, they only get the exahype::Parser::ParserView& constants
when there are constants in the specfile. This creates a lot of trouble for the users, for instance when they decide to introduce constants on an existing application because they need to introduce the new signature then on their own.
Even worse: Currently, the ParserView&
works for FV solvers, but not for ADERDG solvers (at some point, a ParserView
instead of a ParserView&
is needed) and therefore also not for coupled LimitingADERDG solvers.
I know that Tobias wants to keep the first code the user see's in his solver as small as possible. So what about always passing the cmdlineargs
and a constants
reference and either storing everything in some class
struct SpecfileOptions { // or so
std::vector<std::string>& cmdlineargs;
exahype::Parser::ParserView& constants;
// could store even more, for instance general access to the parser,
// static build information, paths, etc.
};
and just pass a SpecfileOptions& options
to the constructors and the init
function.
As an alternative or additionally, we can make the init
function virtual and put an empty implementation into the Abstract*Solver.{cpp,h}
. Then the user could introduce it into his solver only when he needs it.
We are talking about startup code which is only called once, so this should really be as comfortable as possible, performance does not matter at all.