You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to debug another problem with the SCM and the develop branch of MAPL I hit another problem, that's not a MAPL issue at all, MAPL just caught it. I suspect it has been there all along as no one every probably runs a debug build of the model when running the SCM.
Here is what I'm seeing when running:
forrtl: severe (408): fort: (33): Shape mismatch: The extent of dimension 3 of array PTR3 is 72 and the corresponding extent of array PTR30 is 73
Image PC Routine Line Source
GEOSgcm.x 00000000106EA47F Unknown Unknown Unknown
libMAPL.generic.s 000014C37C539C41 mapl_genericcplco 1125 GenericCplComp.F90
libMAPL.generic.s 000014C37C4F9480 mapl_genericcplco 649 GenericCplComp.F90
I put a few prints in and this a coupler in AGCM, it's trying to couple a variable named OMEGA, seems to be coming from DYN over to Physics.
The issue is that in the initialize method, the coupler variable where the accumulation is stored is made with a pointer obtained from OMEGA that is clearly "edge" in that is goes from 0 to 72, but later in the run, the actual variable pulled from the state that is going to be averaged is 1 to 72 and center so you get the shape mismatch.
The problem is everywhere in the model in FV3, Physics OMEGA is MAPL_VLocationCenter, but in GEOS_DatmoDynGridComp.F90, it is MAPL_VLocationEdge. That's it, so I guess DatmoDyn is wrong.
Another question could be why is omega and only omega being coupled with the generic coupler...
To run the case:
Build GEOSgcm (use the DEBUG build!) and then go to install/bin and run scm_setup like:
When trying to debug another problem with the SCM and the develop branch of MAPL I hit another problem, that's not a MAPL issue at all, MAPL just caught it. I suspect it has been there all along as no one every probably runs a debug build of the model when running the SCM.
Here is what I'm seeing when running:
I put a few prints in and this a coupler in AGCM, it's trying to couple a variable named OMEGA, seems to be coming from DYN over to Physics.
The issue is that in the initialize method, the coupler variable where the accumulation is stored is made with a pointer obtained from OMEGA that is clearly "edge" in that is goes from 0 to 72, but later in the run, the actual variable pulled from the state that is going to be averaged is 1 to 72 and center so you get the shape mismatch.
The problem is everywhere in the model in FV3, Physics OMEGA is MAPL_VLocationCenter, but in GEOS_DatmoDynGridComp.F90, it is MAPL_VLocationEdge. That's it, so I guess DatmoDyn is wrong.
Another question could be why is omega and only omega being coupled with the generic coupler...
To run the case:
Build GEOSgcm (use the DEBUG build!) and then go to
install/bin
and runscm_setup
like:Obviously, change the account to whatever you like. Then go to
/path/to/directory/arm_97jul
and in there you can just run:By default arm_97jul runs for 30 days, but you can change
CAP.rc
to be 1 week or whatever. Even 30 days runs quick.The text was updated successfully, but these errors were encountered: