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.nx*mesh.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.