ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2019-03-21T10:45:51+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/236Make mexa more friendly in ExaHyPE2019-03-21T10:45:51+01:00Ghost UserMake mexa more friendly in ExaHyPECurrently the applications which use the [meta-specfile parameter system](https://bitbucket.org/svek/mexa) (i.e. CCZ4 and GRMHD) have small childhood diseases:
* They are very verbose in output at startup. `mexafile::toString()` is kind...Currently the applications which use the [meta-specfile parameter system](https://bitbucket.org/svek/mexa) (i.e. CCZ4 and GRMHD) have small childhood diseases:
* They are very verbose in output at startup. `mexafile::toString()` is kind of too noisy and should instead print something more human-readable (such as `foo = bar [ref]` instead `eq(foo, bar, ref)`), probably one `tarch:::logInfo` per line.
* In the current usage, `foo = mf[key].as_double()` where `mf` is a mexafile, if the key is in the wrong data type (in this example: not castable as double), it spills out an error message *without* any reference where the error occured, only way to find it is to start with `gdb` and to go up the stack trace. This is exactly against the philosophy of mexa where the parameter source should *always* be dragged along, also with the `mexa::value` type. This needs to be implemented and tested.