Parent section for RUNTIME VTK OUTPUT

[ischeider]

Recently I searched for runtime output for a thermal problem, which I expected in the IO section. It turned out that for thermal problems it belongs to THERMAL DYNAMIC. After checking the documentation, I found the following sections for the vtk output:

BEAM CONTACT/RUNTIME VTK OUTPUT
BEAM INTERACTION/BEAM TO SOLID SURFACE/RUNTIME VTK OUTPUT
BEAM INTERACTION/BEAM TO SOLID VOLUME MEYHTYING/RUNTIME VTK OUTPUT
BEAM POTENTIAL/RUNTIME VTK OUTPUT
FLUID BEAM INTERACTION/BEAM TO FLUID MEYHTYING/RUNTIME VTK OUTPUT
IO/RUNTIME VTK OUTPUT
IO/RUNTIME VTK OUTPUT/BEAMS
IO/RUNTIME VTK OUTPUT/FLUID
IO/RUNTIME VTK OUTPUT/STRUCTURE
THERMAL DYNAMIC/RUNTIME VTK OUTPUT

Am I the only one who finds that strange/unintuitive?
Maybe there is a reason for the splitting the output between the IO section and the other ones, but form a users point of view it does not make sense.

Should we unify the RUNTIME VTK OUTPUT sections? I assume in most other software products, the output is collected in an "output" section, which means that I am fond of having everything under IO.

BTW, our IO section contains only O, so IMHO it should be renamed to OUTPUT anyway, but this is probably a different discussion, and in this I can understand that there maybe various opinions.

[c-p-schmidt]

I totally agree that they should be unified. So let's try to find a common understanding on where to put those parameters.

I am fine with putting them in a dedicated output section, and I'm also fine with naming it OUTPUT. Additionally, I would remove the RUNTIME from RUNTIME VTK OUTPUT because it does not contain relevant information.

[sebproell]

From a modularity perspective, I wouldn't see output as a top-level section. I would rather move output settings into the respective physics or driver section. Think about wanting to run a TSI simulation. From the input side, you would want to enter a TSI section and specify all details in there. If we have a common output section, it is unclear that the parts related e.g. to fluids in there are not relevant for TSI. This is analogous to how we are restructuring the code for more modularity: output may be a recurring building block, so all physics modules may reuse it. However, there should not be an output module, that needs to know all physics to do its work. Note that the same logic applies to the MATERIALS, FUNCT<n>, boundary conditions, etc.

[davidrudlstorfer]

+1 for that, that's how I changed it in #1028

[ischeider]

I expected the modularisation argument, and I cannot rebut that (particularly when I count the thumbs up), but from the user's side I don't see the output belongs to the internals of the simulation itself. For beams it is particularly painful: you might have IO/RUNTIME VTK OUTPUT/BEAMS and BEAM POTENTIAL/RUNTIME VTK OUTPUT and BEAM CONTACT/RUNTIME VTK OUTPUT.

For example: I see an analogy for the boundary conditions: in most of the input files, we have the internal settings for the physics, and then we have the boundary conditions for all physics, (mostly) starting with DESIGN ...

To me it is much more important to have the output in one place. Then I can switch on and off whatever I like. But anyway, if the majority likes it more in the DYNAMICS part I can live with it as well, but it must be consistent.

[mayrmt]

I am with @sebproell here.

The different beam subslists only have the word beam in common. Otherwise, they refer to different parts a features of the code. If I do beam contact, I am not interested in beam potential (in general), so this separation is just fine and plays along with the physical use cases.

Yes, it needs to be consistent across the entire code base, which is not the case, yet.