iMOAB redesign

Issue #145 new
Iulian Grindeanu created an issue

iMOAB apps need to exist on all tasks; right now, they exist only on component pes, or on coupler pes tasks

We could simplify design, on the coupler side, to contain a list of all component instances / corresponding file sets ;
So we would have only one pid on the coupler side, on the coupler PES

Right now, we have a different PID for each component that is instanced on the coupler side; also, we could have

different components instanced twice, on the coupler PEs

Also, the appData and pcomms vectors should not be separate; ParallelComm should be part of the AppData;
Design oversight

Issue with the “type” variable that defines the type of degrees of freedom in the mesh
we use 1 for spectral mesh used in atmosphere; degrees of freedom are stored in GLOBAL_DOFS special tag, defined on quad cells; the size of the tag is np x np, usually 16 for preferred default np = 4; degrees of freedom are in lexicographic order on each quad/cell. In the dual pentagon mesh sometimes associated to the cubed-sphere mesh, the GLOBAL_ID tag on those cells will correspond to the same degrees of freedom;

2 for point cloud meshes, used in land, or runoff models; degrees of freedom are defined on the GLOBAL_ID tag on vertices
3 for FV polygonal meshes; degres of freedom are defined on the GLOBAL_ID tag on polygonal cell itself (for example on MPAS meshes or on explicit land meshes).

We should probably store the type of the mesh on the appData itself, it is not changing, and it should be defined at initialization time. Or at least we should have a method to set it;

Another improvement would be to use an enum type for those values, instead of nameless “int”

Comments (3)

  1. Log in to comment