Accessing the dynamics

[timspainNERSC]

My current understanding of what we need to do/answer to be able to use the dynamics in neXtSIM_DG.

• Merge the dynamics branch with develop and/or main
• A Module for accessing the dynamics (or is the dynamics fixed apart from the choice of rheology?)
• Configuration to read/assign dynamics constants
• Module accessed from within the dynamics to allow run time configuration of the rheology
  • What is the interface from the advection to the rheology?
• Should the dynamics Module be a ModelComponent to directly(ish) access the model data?
  • Probably!
• Refinement of ModelArray to include DG components where necessary
• Are the U/V ModelArray::Types absolutely never needed with DG? (no B/C/D/E grids or equivalent structures)

[pminak]

Dynamics work with 2 types of Arrays: DG vector of size (mesh.nxmesh.ny) x degrees of freedom in cell CG vector of size: CGdegree mesh.nx + 1) (CGdegree mesh.ny + 1) x 1

[timspainNERSC]

• ModelArray::Types should become:

  • DG ((nx * ny), DoF)
  • CG ((nx+1 * ny+1), 1)
  • scalar ((nx * ny), 1) (currently named H)

• DG degree will vary fastest in the netCDF file

• New IStructure implementation for regular DG grids (and IO class)

• Check how ModelArrayRef works with EigenMatrix in the dynamics. Can ModelArrayRef point to an EigenMatrix?

• Velocity (u,v), stress components & damage (also concentration and thickness)

• v_x += temp

[timspainNERSC]

• Configuration for mesh shape
  • flat
  • curved
  • global
• Boundary conditions configuration (compile time? run time?)

[einola]

Some comments after the meeting in Grenoble:

• @winzerle (that's Thomas, right?) and @pminak will extract a call for a single (long) time step from their current implementation for @timspainNERSC to call from his code
• @timspainNERSC will investigate the use of Eigen arrays and matrixes further
• There will only be one DG implementation - but we should allow for implementations of different dynamics (e.g. Lagrangian).
• Dynamics should be a ModelComponent with direct access to velocities.
• @athelaf will continue to be responsible for MPI parallelisation

Key use cases:

• Simple tests
• Stand-alone regional setups. Size from 100k to 1M elements
• Global coupled model at relatively low resolution (probably 1/2 degree): Number of elements to come
• Extremely high-resolution regional setup (stand-alone). Max 500 m resolution: Number of elements to come

[timspainNERSC]

* Dynamics should be a ModelComponent with direct access to velocities.

Dynamics should be a ModelComponent which holds the ModelArrays for velocities, concentration, thickness, stress and damage. The ModelComponent data sharing should provide access to all these arrays (add them to ProtectedArray).

[timspainNERSC]

My current thoughts on how to connect the dynamics to the rest of the model.

• The intention is for a single binary to be able to handle any size grid. There should be a way of setting any grid parameters for the dynamics early in the model run.
  • But not any DG/CG degree. That is probably going to be a compile time setting.
• A way of getting the model data from the restart file to the dynamics and back out. Either ModelState needs to be able to cope with fields with DG components, or another more specialized method created.
• A decision on what data is held where and what the sharing mechanism is.
  • My present thinking is that the dynamics hold the full DG/CG versions of the dynamics fields, and any tracer field that needs to be advected. The physics hold a copy of the mean component only. This data is copied back and forth every physics timestep.

Feedback on the last point would be appreciated.

[winzerle]

• Data handling seems reasonable. dynamics stores all that it really needs with higher oder and we provide access to the mean.
• Within dynamics the templates could be encapsulated as done in the application/benchmark_mehlmann_sasip_mevp.cpp then all template arguments are in one place, which would be the interface between dynamics and physics.

[einola]

Yes, this seems reasonable. The only question is if the copying (in point 3) will be expensive. I suggest that we implement it like this and then profile the code. If copying is expensive, then we'll have to re-think.

[winzerle]

I guess that everything that's done at the physics steps only does not play a role. At least stuff that just involves running through vectors. In between we have the full subcycling, which means many (hundreds) of matrix-vector products (in terms of effort). Copying some vectors will not play any role.

To get an idea: the high order advection of one tracer is about 1% (more or less) of the momentum iteration. And copying such a vector is even far less.

[einola]

To get an idea: the high order advection of one tracer is about 1% (more or less) of the momentum iteration. And copying such a vector is even far less.

That's very useful information! And an interesting result too. So now I'm not worried about the copying :)

[timspainNERSC]

During the meeting on 12th September, @draenog pointed out that another possible solution is to have the data structure in the physics part of the model reference/slice the full DG arrays in the dynamics such that they only ever see the finite element DG component. This would be an alternative to the method of copying data back and forth between physics and dynamics.

[timspainNERSC]

Solving this issue will require a substantial amount of code from the jun23_demo branch. In this case, all the code exists.

@einola @dorchard @draenog @a-smith-github: Do we move all the necessary commits and issues into 1. Dynamics merge, or do we push this issue back to 2. Stand-alone model?

[einola]

I think this one should remain in milestone 1, as almost everything mentioned here is needed for a minimum viable model that can run the dynamics within the complete framework and not as a separate application.

[timspainNERSC]

I think this one should remain in milestone 1, as almost everything mentioned here is needed for a minimum viable model that can run the dynamics within the complete framework and not as a separate application.

Are you still sure about this? It will require pulling a lot of what is currently flagged as milestone 2 into milestone 1. At a minimum merging PRs #250 #389

But possibly that is all.

[einola]

It's two!

[timspainNERSC]

I think this one should remain in milestone 1, as almost everything mentioned here is needed for a minimum viable model that can run the dynamics within the complete framework and not as a separate application.

Are you still sure about this? It will require pulling a lot of what is currently flagged as milestone 2 into milestone 1. At a minimum merging PRs #250 #389

But possibly that is all.

PRs #250 and #389 have been merged.