-
Notifications
You must be signed in to change notification settings - Fork 100
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
Updated support on Odin & Stampede to use NCEPLIBS public-v2 release #194
Updated support on Odin & Stampede to use NCEPLIBS public-v2 release #194
Conversation
@WenMeng-NOAA Given our recent discussion about UPP version, how do you want to handle the versions listed in the modulefiles in each release branch? In release/public-v2 we decided on v9.0.0. Do we want to make that change in the modulefiles as well? |
@fossell, I see Yunheng submitted the changes to both develop and release/public-v2. The modulefiles is used in GNC build. If cmake build is not used them, you may keep them (it would be easily merging the changes from release/public-v2 to develop). |
@ywangwof I assume that these changes are required because you are building UPP using the sorc/build_ncep_post.sh script on those platforms that uses the modulefiles, instead of building UPP using cmake. So you are not building within the SRW app, but you just want to make sure that your modulefiles point to the same NCEPLIBS that is used by SRW app and cmake build. Is that correct? |
@WenMeng-NOAA Ok, it seems like @ywangwof is wanting to use the GNU build (build_ncep_post.sh) in this public-v2 branch. The modulefiles won't impact cmake build, so I have no problem with the mods. I just wonder if I should rename the odin and stampede files to v9 just to reflect that they are hard coded to point to specific SRW versions of NCEPLIBS. Agree that in future we could consider removing the version from the filenames to avoid confusion. |
@fossell That is NOT right. I am building from the SRW app. My current version of the SRW app is dated on 2020-09-25 with hash #d8e9e31 and it is the latest one just checked out today. It is built using "src/build_all.sh" -> "src/build_post.sh" -> "EMC_post/compile" -> "EMC_post/sorc/build_ncep_post.sh". The "EMC_post" is dated on 2020-09-22 with hash #abb393e and it is checked out with "manage_externals/checkout_externals". It seems that I do not have the CMake configuration built in yet. Did I miss anything? |
@ywangwof Ok, thanks for clarifying and I understand. I'm going to have to touch base with the SRW team about this. It seems that the version of the app you're using still leverages the compile build, and I was under the impression the app had moved to cmake for UPP already. But perhaps that's not the case. I'll get back to you with more info, but in the meantime I can merge these changes in this branch. And I will move content of this discussion to an issue I have open regarding updates to SRW for UPP if needed. |
@ywangwof I confirmed that the SRW app has not yet merged the PR to make the transition to cmake. That will be forthcoming. But with that change there shouldn't be any impact for you, since you're already pointing SRW NCEPLIBS for your build. As long as those libraries/modules in that path in modulefiles are kept up to date with any changes from NCEPLIBS/release/public-v2, you shouldn't see any changes in UPP behavior when they make the build change If there are problems though, please us know! |
…ed for a hybrid GSI analysis (NOAA-EMC#194) add a variable HYBENSMEM_NMIN GSI will do hybrid analysis if $HYBENSMEM_NMIN or more ensembles are available This allow GSI to do hybrid analysis even we miss a few members of 80 GDAS ensembles.
I just updated the module files on Odin and Stampede to use the newly built NCEPLIBS from NCEPLIBS repository from branch "public-v2".