GEOS-GCM on Discover with GNU - segfault in yafyaml #985
Comments
|
@climbfuji Hmm. I interesting. This might be a "too old GNU". We of course use GCC 12.1 as our "operational" GCC on the SLES12 machines and we do not test with anything else. But you might want to try a newer GCC 10 if you want to use that. Maybe GCC 10.3? In the back of my mind I want to say some user had issues with GFE and it was fixed in later 10 variants. I'll also mention @tclune so he can weigh in. |
|
|
Actually, I wanted the ldd of the other one (the AWS). As for this, again, you might need to update the GCC version to say 10.3 if you want to stay with GNU 10. |
|
@mathomp4 Which of those many MPI options do you use with gcc@12.1.0, and which module do you use for the compiler? I have: Thanks! |
|
Question was answered elsewhere reposting here:
The SI Team maintains these modules. On SLES12: On SLES15: |
|
Interesting. I never got a notifcation for either of these. That is...annoying. Time to delve into GitHub settings... |
|
I missed this too because its a ticket in a repository that I generally ignore. Reading now. |
|
Ok - looks like a trivial fix - I'm missing yet another RECURSIVE declaration somewhere in the stack. The real question is why we don't see this with GEOS. It's only used by either UFS or GEOS in the ExtData2G package. Note for the curious: RECURSIVE is default as of Fortran 2018, so technically the software is correct. Not that it helps the end users, but these things help me to sleep a bit better at night. :-) |
|
@climbfuji Can you point us to the build for that so we can see the post-processed code. (also, probably need permissions) |
|
Thanks for helping @tclune and @mathomp4 . The build is in and the script I source to set the environment/load the modules before building is I think the permissions allow you to access these. |
|
Memory starting to come back to me. The procedure that is lacking the RECURSIVE attribute appears to be the intrinsic assignment on the type And, of course, one cannot add RECURSIVE to an intrinsic procedure. (One can argue the language should effectively do that for you, but gfortran 10 was either before F2018, or not long after, so ...) If memory serves, the last time I got here, I tried to create a user-defined overload for If important, I could try again, but would rather say "gfortran-10" is broken in terms of required feature sets for GFE/MAPL/GEOS. |
|
Thanks @tclune . I think that's a fair point. We should add a conflict with |
|
Confirmed that I can run GEOSgcm main of today using GCC 10.3.0: /discover/nobackup/mathomp4/Experiments/gcc10.3-2024Feb08-1day-c24-SLES12 Modules were: though I suppose only the first two matter. |
|
Note: only on SLES12. NCCS hasn't install GCC 10 on SLES15 probably because there has been no call for it. |
|
Thanks @mathomp4. I'll close this issue and we will make a move to a newer gcc (probably go straight to 12) on SLES12=SCU15/16=cascadelake . |
|
This is already closed, but for the record updating to gcc@12.1.0 on SLES12 allowed me to build and run GEOS-GCM. |
Describe the bug
I can build and run GEOS-GCM with Intel 2021.5.0 on Discover, but with GNU 10.1.0 for the exact same set of libraries, I get the following error:
To Reproduce
Build spack-stack develop on Discover for GNU, compile GEOS-GCM, follow instructions to set up GEOS-GCM (
gcm_setupandmakeoneday.bash), submit job.Expected behavior
No error - GNU runs to completion like Intel does.
System:
Discover with GNU
Additional context
n/a
The text was updated successfully, but these errors were encountered: