Open oakleybrunt opened 11 months ago
For now, I would say that that's the right place for such information - it's inevitable that part of PSyclone be tightly coupled to the implementation of the library it is targeting. We could allow these modules to be overridden in the Config file but I'm not sure of the value of that. Longer term, we could extend PSyclone to discover this (perhaps using the module-handling functionality that @hiker is developing) but I'd be a bit worried about cost (runtime) and robustness.
I agree with @arporter. If there is any replication of names and/or you are concerned about the module information being scattered then you could create an lfric_modules
(or similar) dictionary at the start of the file and use that throughout the code.
@TeranIvy and I were looking at the LFRicConstants file and noticed that there are LOTS of hard-coded references to LFRic specific modules. Specifically in these dicts:
DATA_TYPE_MAP
,FIELD_VECTOR_TO_FIELD_MAP
,STENCIL_TYPE_MAP
,QUADRATURE_TYPE_MAP
,MESH_TYPE_MAP
,REFELEMENT_TYPE_MAP
,FUNCTION_SPACE_TYPE_MAP
, andUTILITIES_MOD_MAP
.If these were ever to change/be renamed in LFRic, this would break the LFRicConstants' references.
What would the best course of action be to rectify this?