LaplaceHypre3d statistics output

[johnomotani]

Writes an average iteration count from LaplaceHypre3d to the dump files, if Laplacian::create() is called with Solver and Datafile arguments. The average iteration count for each output step will also be printed if the command line flag --verbose (or -v) is passed.

@ZedThree @bendudson I've added extra arguments to the Laplacian constructor to implement this. What do you think of the design?

[ZedThree]

Just a note that when we get the output refactoring in, this will be a bit nicer as we'd be able to drop the Datafile

[ZedThree]

I'm always a little cautious about adding more arguments to constructors, but I think this is probably the best way of doing things.

Another option might be to just make the monitor available and then up to the user to add it. That would end up looking something like:

auto laplacian = Laplacian::create(options);
laplacian.monitor.outputVars(dump);       // This would need to be added
solver->addMonitor(&laplacian.monitor);

which is not a terrible amount of boilerplate for user code, but still, maybe not quite as nice as just

auto laplacian = Laplacian::create(options, CELL_CENTRE, mesh, solver, dump);

With the warning in the constructor, this feature is actually discoverable, where it wouldn't be with the user-side monitor registration.

[johnomotani]

A slightly different approach (while we can still break interfaces for v5) might be to pass a PhysicsModel to the Laplacian constructor and let the Laplacian get Mesh*, Solver* and Datafile* from there (maybe add getter methods if necessary). Then we wouldn't need to increase the number of arguments to the constructor, just replace the Mesh* with a PhysicsModel*. I guess in practice nobody is using the mesh argument, so it shouldn't be a big deal to change.

[ZedThree]

Definitely something to consider! I'm happy with this approach though

[dschwoerer]

I would prefer to not require a full physics model to use the Laplacian. I have used the Laplacian in the past without actually having a physics model, although I used only one mesh, so maybe that would be fine for that use case.
But I think it is a bit overkill to create a physics model just to be able to bundle three pointers.

At least for the python interface, I think three separate pointers are much nicer 👍

[johnomotani]

Good points @ZedThree @dschwoerer. Lets stick with the interface in this PR 👍

[dschwoerer]

auto laplacian = Laplacian::create(options);
laplacian.monitor.outputVars(dump);       // This would need to be added
solver->addMonitor(&laplacian.monitor);

could be simplified to:

auto laplacian = Laplacian::create(options);
laplacian.monitor.outputVars(dump, solver);       // This would need to be added

and in the case that solver==nullptr (default) the monitor is not added. Might even be a bit easier to read, and would allow to be called later - e.g. if I notice that the simulation is starting to cause issues - but I have no strong feelings about this ...

[johnomotani]

@bendudson - I'm not sure if the branch in this PR ever got merged in to anything - if not I think it would be useful to merge into whatever the current GPU branch is...