Add VTKFieldWriter

[kpamnany]

Description

Allows writing of computed fields into VTK.

For example:

using ClimateMachine.VTK
# ...

    function pres_fun(atmos::AtmosModel, prognostic::Vars, auxiliary::Vars)
        ts = recover_thermo_state(atmos, prognostic, auxiliary)
        air_pressure(ts)
    end
    fwriter = VTKFieldWriter(solver_config.name, [("pressure", pres_fun)])
    cbfw = GenericCallbacks.EveryXSimulationTime(60) do
        fwriter(solver_config.dg, solver_config.Q)
    end

Then pass cbfw into invoke! (or solve!) as a callback. You can use a similar pattern to add other computed fields; just add tuples to the vector passed in to the VTKFieldWriter constructor.

• Code follows the style guidelines OR N/A.
• Unit tests are included OR N/A.
• Code is exercised in an integration test OR N/A.
• Documentation has been added/updated OR N/A.

[kpamnany]

@smarras79 and @OsKnoth: here's how you can get pressure (or other such computed fields) output to VTK. Please pick one of our experiments and I'll add code that uses this into it for you to use as a pattern.

[kpamnany]

@jkozdon: could you take a look at this please and see if it looks okay to you?

@smarras79: does this work for you?

[jkozdon]

Looks good. Can we add a test? There are some other vtk tests, mainly to make sure the interfaces continue to work.

We could possibly move to only using this and defaulting to a version that dumps all the data in aux and state? Or alternatively should this be merged with the other vtk data dump functionality so you dump state, aux, and computed fields.

I'm also fine with leaving as is though, as far as I can tell it's correct.

[smarras79]

This solution is not trivial. A user should not be worrying about writing code lines to simply have pressure (a fundamental quantity in fluid flow solver) written to VTK.

[simonbyrne]

@smarras79 Unfortunately the current design of the VTK output is really only intended for prognostic quantities; derived quantities are designed to go through the diagnostics system. Changing how this works will require significant changes to the codebase, which we don't have the resources to do at the moment.

[smarras79]

@smarras79 Unfortunately the current design of the VTK output is really only intended for prognostic quantities; derived quantities are designed to go through the diagnostics system. Changing how this works will require significant changes to the codebase, which we don't have the resources to do at the moment.

[smarras79]

[closed by mistake] reopened

[smarras79]

The VTK is there to help debug the code because, as of now, it is the only format in climatemachine that writes data on the native numerical (DG) grid. This file contains quantities that are totally unimportant from the physical point of view of what problems we are solving (total energy, density, momentum, reference density).
If we have useless quantities given to a developer who needs to debug the code, effective and efficient debugging is close to impossible (as demonstrated so far).

At the level of writing the VTK file, it is 1 call to the thermodynamic function that computes pressure from the equation of state that needs to be called, compute pressure, and write it to file. If this is not easy to do, then there is clearly something very wrong in the code structure and needs to be addressed as soon as possible.
cc.: @bischtob @tapios @fxgiraldo

[kpamnany]

All efforts on output thus far have been focused on the Diagnostics module which currently only writes NetCDF. Some discussion of output formats is in #114.

There are three tasks on the TODO list relating to diagnostics output:

1. Parallel NetCDF support #2007 to support parallel NetCDF.
2. Dump non-interpolated data #1441 to allow writing data on the native grid into NetCDF.
3. Add VTK Writer #2006 to allow the Diagnostics module to write to VTK.

These are listed in order of priority.

We do not currently have any plans to enhance the VTK module beyond the capability introduced in this PR.

[kpamnany]

Looks good. Can we add a test? There are some other vtk tests, mainly to make sure the interfaces continue to work.

@jkozdon: I added a test, but it feels a little silly; can you take a look please?

[smarras79]

All efforts on output thus far have been focused on the Diagnostics module which currently only writes NetCDF. Some discussion of output formats is in #114.

There are three tasks on the TODO list relating to diagnostics output:

1. Parallel NetCDF support #2007 to support parallel NetCDF.
2. Dump non-interpolated data #1441 to allow writing data on the native grid into NetCDF.
3. Add VTK Writer #2006 to allow the Diagnostics module to write to VTK.

These are listed in order of priority.

We do not currently have any plans to enhance the VTK module beyond the capability introduced in this PR.

@kpamnany #2006 may not be necessary if you are already doing #1441

[jkozdon]

@jkozdon: I added a test, but it feels a little silly; can you take a look please?

Yeah. Our VTK tests are a bit silly, but we did run into a problem with interface changes in the past, so just wasn't sure if we wanted something that exercises the interface.

I'm fine removing if you think it's not needed.

[kpamnany]

#2006 may not be necessary if you are already doing #1441

I think we don't yet know if any of the standard NetCDF visualization tools people are using (ParaView, etc.) understand the UGRID conventions. If they do, then you're right. If they don't, then #1441 will only be useful for people writing their own visualization scripts and #2006 might be higher priority.

[kpamnany]

I'm fine removing if you think it's not needed.

I don't think the test adds enough value to make up for the overheads.

[kpamnany]

bors r+

[bors]

Build succeeded:

• buildkite/climatemachine-ci
• buildkite/climatemachine-docs
• format
• test-os (macos-latest)
• test-os (ubuntu-latest)
• test-os (windows-latest)