Closed timspainNERSC closed 12 months ago
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
ModelArray::Types should become:
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
Some comments after the meeting in Grenoble:
Key use cases:
* 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).
My current thoughts on how to connect the dynamics to the rest of the model.
Feedback on the last point would be appreciated.
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.
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.
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 :)
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.
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?
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.
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.
It's two!
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.
My current understanding of what we need to do/answer to be able to use the dynamics in neXtSIM_DG.