Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OMEGA in Datmodyn not defined consistently with rest of model. Causes SCM failure in DEBUG build. #903

Closed
bena-nasa opened this issue Feb 15, 2024 · 1 comment · Fixed by #904
Labels
bug Something isn't working

Comments

@bena-nasa
Copy link
Collaborator

bena-nasa commented Feb 15, 2024

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:

./scm_setup --expdir /path/to/directory/arm_97jul --case arm_97jul --account s1873

Obviously, change the account to whatever you like. Then go to /path/to/directory/arm_97jul and in there you can just run:

./scm_run.j |& tee log.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.

@bena-nasa bena-nasa added the bug Something isn't working label Feb 15, 2024
bena-nasa added a commit that referenced this issue Feb 16, 2024
@bena-nasa bena-nasa mentioned this issue Feb 16, 2024
@bena-nasa
Copy link
Collaborator Author

After consulting with @atrayano this is a bug, you can't couple things that have different dimensions in the specs...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant