Open mathomp4 opened 1 year ago
I think it is important that we are all cognizant that the long term plan is to use a "dictionary" for determining the values of physical constants. (Some are going further and using a dictionary for mathematical constants, but I don't think GMAO needs its own value of pi, e, sqrt2, etc.) In that era, each component will somehow be able to access a dictionary specified by the parent to retrieve its values. We will maintain a single dictionary for all of GEOS.
In the near term, though we should at least consolidate. My vote would be to rely entirely on the MAPL constants layer for now (extending as needed), but am happy to entertain reasons to leave these specified in some other layer. If something is truly unique to a single component, then it is probably ok to define it there.
Recently, as a test, I tried to build the
feature/sdrabenh/merge_v10.23.0_MSTRF
branch that @sdrabenh is using to track the new Physics with GNU instead of Intel and it threw out a number of issues.One is a simple Fortran standard violation here: https://github.com/GEOS-ESM/GEOSgcm_GridComp/blob/d4b64898ef763c52204960981c074f98a3391a74/GEOSagcm_GridComp/GEOSphysics_GridComp/GEOSmoist_GridComp/ConvPar_GF2020.F90#L11525 which should be:
But the more exciting issues come after that.
First, we have:
The issue here is that both
aer_actv_single_moment.F90
andProcess_Library.F90
provideR_AIR
. You can "solve" this by removingR_AIR
fromaer_actv_single_moment.F90
but there is still the fact thatR_AIR
is defined a few times in moist:The "good" news is that they are all the same value (well, the MGB2 one is
REAL64
) but they are all the same. Still, probably best to be defined in one place. NOTE: I'm not sure if this is a constant in MAPL or not (nothing in MAPL screams 0.00347).For now, let's move past
R_AIR
and see what GNU flags next...Again, something similar,
rgas
is defined too many places. But this one is worse. Moist has a few values ofrgas
:Some routines use
MAPL_RGAS
but some (GF) have their own of just287.
GF2020 uses both!This is also picking up use of
rgas
as the universal gas constant inaer_cloud.F90
andaer_actv_single_moment.F90
both of which are different thanMAPL_RUNIV
.I think this issue might be more wide spread. For example in GF code you often see:
and I have to think many of these are
MAPL_
constants. I mean, I knowg
is asMAPL_GRAV
and there are a few otherg
in Moist as well:I'm not sure what to do here. We eventually have to figure out how to get GNU to compile this. But I'm wondering what the "right" thing to do is. Change code to use
MAPL_
constants? Only do the bare minimum to let it compile?CC: @tclune @gmao-ckung