Commit ec261701 authored by Lukas Riedel's avatar Lukas Riedel 📝

Add new config key 'output.vertexData' for plotting vertex data

parent 8006ff60
......@@ -50,6 +50,17 @@ adding an empty line, make text **bold** or ``monospaced``.
<values> string </values>
<parameter name="vertexData">
<definition> Plot vertex based (``true``) or cell-centered (``false``)
data into VTK files. Vertex based data might render sharp
parameterization boundaries inappropriately.
System tests and plotting functions (``dorie plot``) require
cell-centered data.
<values> true, false </values>
<suggestion> false </suggestion>
<parameter name="asciiVtk">
<definition> Defines whether VTK files should be written as ASCII (``true``)
or binary (``false``). ASCII is easier to parse in case you want to write
......@@ -77,11 +77,20 @@ public:
auto waterdgf_vtk = std::make_shared<Dune::PDELab::VTKGridFunctionAdapter<WaterDGF>>(waterdgf,"theta_w");
auto satdgf_vtk = std::make_shared<Dune::PDELab::VTKGridFunctionAdapter<SatDGF>>(satdgf,"Theta");
if (_inifile.get<bool>("output.vertexData")) {
  • In order to do not affect projects already created with past versions of DORiE, this option must be optional:

  • Can you elaborate what you mean by 'project'? Of course, a new key generally means that older config files will not work anymore and need to be updated.

    We introduced the policy that there are no optional config keys quite some time ago. I'm open for debate on that, but I don't like using default values that are hidden from the user.

  • By a project, I mean a set of simulations run several times with the aim to have more understanding of something (e.g. benchmarks, infiltration with different events, etc.). Take for instance, all projects run in PoTS, in my case I have a set of at least 15 cases of simulations.

    This approach means that every single project created must be attached a very specific version of DORiE. I certainly believe that, at some point, this can become a limitation for the final user. And even more limited if for some reason there is another software built on top of DORiE (e.g. a GUI or as a Richards solver for a bigger problem, like WRF).

    As minor an example, all config files (about 20) I have on my computer are now obsolete. If my merge request of dune-modelling is accepted this week, it means a change in the user interface twice within one month!

    I see your point about no optional config keys, however, as I said before, I do believe that continuous changes in the user interface are not suitable. Therefore, my approach would be implementing new config keys as optional, and release them periodically (e.g. two or three times per year, maybe tied with DORiE releases) plus a CHANGELOG with the new requirements.

    Edited by Santiago Ospina De Los Ríos
  • First of all, sorry for the inconvenience. You are absolutely right about how releases and changes of the interface should be handled, once Dorie is stable. But it is not.

    In fact, I'm currently preparing the first stable version (see %"Dorie v1.0 Release") from which on I want to adhere exactly to such a scheme. Changes to input and output in general should be announced, declared in version numbers, and logged in a CHANGELOG. But for now, I'm bringing in features that Ole and I deem vital for a version 1.0.

    Your config files, however, are not obsolete. You can always check out the releases/pots-1718 branch and run the simulations from the lecture again. Updating your files to the current version of master just requires you to add a single line.

    The recent changes to the config files become relevant for you once we merge your work. But I see this mainly as 'merge conflict', where we both need to work on bringing deviated version histories back together.

Please register or sign in to reply
else {
/// Write the VTK files for the current solution unew
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment