Add basic parameter file validation mode.

[jperryhouts]

This idea could definitely be improved upon, but is of useful as is. This PR adds a --validate flag that exits after parsing the parameter file. I typically do the same thing by just starting a model and ctrl-c'ing it after the parameter file is parsed. This is very slightly more straightforward, and possible to automate in a script later on if needed.

[tjhei]

Does this really work as is? I don't see the logic to check whether parsing works or not. Would you mind setting the return value in main to tell if validation works?

[jperryhouts]

Does this really work as is?

Yeah, but it does it the lazy way. It either hits the QuietException in parse_parameters (made more explicit just now with a fixup to this commit), which gets caught in main and returns 1; or it skips constructing the Simulator, and exits with 0 the usual way at the end of main. It short circuits run_simulator, similar to the way --output-xml and --output-plugin-graph work.

I'm not sure I understood your suggestion. I see two other options to make the code more explicit, and they both involve more changes and possible code duplication than I think this feature really deserves:

1. Pass along a pointer to a boolean to run_simulator, and then to parse_parameters, which eventually comes back to notify main about the result.
2. Make a separate function that only validates parameters, and call it from main.

[tjhei]

Yeah, but it does it the lazy way.

I see! This is difficult to see by looking at the source. So you are saying that your approach does already return failure in main() because of the quiet exception?

Another option (maybe):

if (validate)
{
ParameterHandler prm;
aspect::Simulator<dim>::declare_parameters(prm);
try
{
  parse_parameters (input_as_string, prm);
}
catch (...)
{
throw QuietException();
}
}

instead of introducing additional args to run_simulator and parse_parameters?

[jperryhouts]

That'd work, and be more clear/explicit, but to do it from main I think means duplicating those lines for case dim==2 and dim==3. I think I recall that just passing <dim> isn't enough because the compiler needs to make a finite number of object copies of the Simulator class. That's why I was thinking it seems like too much duplication (especially since those first two lines would already then be duplicated from run_simulator).

Alternatively, that could be its own function, called something like validate_prm.

I'm fine with any of these options; let me know which you prefer.

[tjhei]

then be duplicated from run_simulator

well, you could put what I wrote into run_simulator instead? Oh, and could you change the name of the argument of run_simulator to validate_only?

I'm fine with any of these options; let me know which you prefer.

I don't feel strongly about it either. :)

[jperryhouts]

👍 -- I put your code in run_simulator. This should make the logic clear.

[tjhei]

I like it! Thanks. /run-tests

[bangerth]

I like this as well!

[bangerth]

maybe make the purpose clear by saying "...and either exit or report parsing failures"?

[bangerth]

In isolation (without knowing the code that surrounds it), this text is hard to understand. Is the user asked to provide a valid parameter file? Maybe just say "The provided output file is valid."

[jperryhouts]

I changed those interface messages to make them more clear. Should be pretty much good to go now.
Question: Should the 'your parameter file is valid...' message be printed to stdout or stderr?

One thing that's sort of unfortunate about this feature is that it's totally possible to write a valid parameter file that will not run. For example, if you choose 3 compositional fields, but only list two field names, this validation will pass, but your model will crash before starting. From the user's perspective, that's an invalid parameter file. The distinction between that and the more superficial validations addressed in this patch isn't at all obvious.

I added a disclaimer after the successful validation message to that effect, but it might be worth thinking of ways to more thoroughly validate prm's in the future (run the simulator for a time step, but turn off all the solvers or something?). The idea here is to make sure your model won't immediately crash on a cluster, where you might not notice the failure right away.

[tjhei]

run the simulator for a time step, but turn off all the solvers or something?

The problem with that is that you might not be able to create/setup the initial mesh on your workstation, resume from a snapshot, etc.. or that it will take a very long time. I think "validation" should be something that runs very quickly.

[jperryhouts]

I think "validation" should be something that runs very quickly.

Agreed. I don't really have a solution at the moment, but something to think about in the future.

[bangerth]

All of the checks we currently perform are either in the parse_parameters() function or the constructor of class Simulator. The latter can indeed take quite a long time, and may also run in parallel, so just creating such an object may not be trivial.

[bangerth]

std::cerr is not the correct place: that's where errors go, but you print a success message. Can you still change this?

[gassmoeller]

Looks ready. continuous-integration/jenkins/pr-merge actually succeeded and just did not report the results, and continuous-integration/jenkins/pr-head stumbled over an unrelated issue that was fixed on master already. Thanks!