GitLab

Currently, using runtime parameters requires to parse them somewhere, leading to code like

void GeometricBallLimiting::readParameters(const mexa::mexafile& para) {
	radius = para["radius"].as_double();
	
	std::string where = para["where"].as_string();
	toLower(where);
	if(where == "inside") limit_inside = true;
	else if(where == "outside") limit_inside = false;
	else {
		logError("readParameters()", "Valid values for where are 'inside' and 'outside'. Keeping default.");
	}
	
	logInfo("readParameters()", "Limiting " << (limit_inside ? "within" : "outside of") << " a ball with radius=" << radius);
}

associated to a structure where the parameters are stored,

struct GeometricBallLimiting : public LimitingCriterionCode {
	double radius; ///< Radius of the ball (default -1 = no limiting)
	bool limit_inside; ///< Whether to limit inside or outside (default inside)
	
	GeometricBallLimiting() : radius(-1), limit_inside(true) {}
	
	bool isPhysicallyAdmissible(IS_PHYSICALLY_ADMISSIBLE_SIGNATURE) const override;
	void readParameters(const mexa::mexafile& parameters) override;
};

This is lot's of overhead and really redundant.

In Cactus, the user can declare parameters including their description/meaning and valid values in a nice language, they are then made available as a structure by the glue code, all the parsing is abstracted away. Example of a Cactus parameter file (CCL file):

real eta "Damping coefficient for the Gamma Driver" STEERABLE=always
{
 0:*   :: "should be 1-2/M"
}0.2

KEYWORD evol_type "Which set of equations to evolve"
{
 "BSSN"  :: "traditional BSSN"
 "Z4c"  ::  "Z4c"
 "CCZ4"  :: "(Covariant) and conformal Z4"
 "FOCCZ4" :: "First order formulation of the CCZ4"
}"Z4c"

boolean include_theta_source "Only FO-CCZ4:  set to false to remove the algebraic source terms of the type -2*Theta" STEERABLE=always
{
} yes

In the code, one then just has something like

struct parameters {
  double eta;
  std::string evol_type;
  boolean include_theta_source;
}

which is already filled nicely with values.

While at least I certainly don't want to code such a glue code for ExaHyPE, in contrast with minimal effort we can get much better then the current MEXA system. In fact, it would be nice to use OOP reflection to automatically register class attributes for common data types (int/double/bool/string). That means I would be fine with writing

struct GeometricBallLimiting {
    double radius;
    enum class limit_at { inside, outside };

    REGISTER_PARAM(radius, DEFAULT(-1), "Radius of the ball");
    REGISTER_PARAM(limit_at, DEFAULT(limit_at::inside), "Where to limit");
}

In fact, something like this is possible some macro magic.