-
Notifications
You must be signed in to change notification settings - Fork 18
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
release/public-v2: add NCEPLIBS umbrella modulefile and shell scripts for SRW App release #148
release/public-v2: add NCEPLIBS umbrella modulefile and shell scripts for SRW App release #148
Conversation
…lways overwrite existing files
@climbfuji Perhaps this is related to the weird extra file sed is creating? It's a slightly different problem but it was solved by adding two single quotes after |
Bingo! Thanks. Yes, adding |
Actually this may be a problem....It looks like there are differences in how sed is implemented on macos vs linux. On macos the above solution works, but when I try to do it on Cheyenne it returns an error There is some more information here...it seems as if there is no clean way to do this that works both on macos and linux: https://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux It may be that deleting the rogue temporary file is the best way to go about it, unless we want to make gnu-sed via Homebrew another prerequisite ;) |
Argh, that's what I feared when I read about the solution. Let me try to look for a cleaner way. These |
…s to avoid writing the NCEPLIBS .lua-e file (macOS only)
66375c6
to
5cd71f9
Compare
@mkavulich try again please |
We also need to decide what to do with the dependencies built by NCEPLIBS-external (or loaded a priori as modules / set via environment variables). Most importantly, we need to avoid confusion what users have to set and what not. As far as I am concerned, everything that gets built or set as part of NCEPLIBS-external and NCEPLIBS should be automatically included in the umbrella modulefile and the shell script. Anything that the user sets/loads beforehand should remain separate. Thoughts? |
For NCEPLIBS and NCEPLIBS-external, what environment variables have to be set? Seems like only CMAKE_PREFIX_PATH should need to be set... |
@climbfuji is there an issue describing this work? If not, can you start one? |
Why the switch to version 2.0? What component library upgrades does this entail (if any)? |
UFS MRW Apps 1.0 and 1.1 where released with NCEPLIBS-v1.0.0 (internally ufs-v1.0.0) and NCEPLIBS-v1.1.0 (internally ufs-v1.1.0). The decision was made to ship the SRW App 1.0 with NCEPLIBS-v2.0.0 (internally ufs-v2.0.0). The numbering of these release versions does not coincide with the internal number in the develop branch. For each major release of the UFS (same or different App), the public release version of NCEPLIBS will be bumped up if sufficient changes are made. v1.0.0 was an early version of the umbrella build (basically just after we started working on it), and this version here is quite different (pretty close to the development version at the moment). |
The issue is summarized in the first paragraph of the PR description. |
Not all users will use NCEPLIBS-external to install the dependencies, although this is the only supported way for the public release. However, users can choose which dependencies to build (netCDF, libpng, jasper, esmf) and which to take from elsewhere (because they already have them preinstalled). The easiest way - for the purpose of the release, not the develop branch - would be to have the NCEPLIBS umbrella Another way would be to check which modules NCEPLIBS-external generated and add them to the umbrella module; for the shell scripts, you'd still need to export the |
Thanks Dom
I think that's fine
Not sure about that. Seems like it could be error prone by adding random modules that you have loaded.
You mean like |
@mkavulich do you have a list of thirdparty dependencies that need to be found to build UFS_UTILS and EMC_post, beyond what the ufs-weather-model needs? For the model, we only need to look for libpng, netcdf, esmf. |
…updates of umbrella module and shell scripts
To answer one of my own questions, here's the kind of environment vars that are being set:
Thankfully we can get rid of all of this after this issue is complete everywhere: NOAA-EMC/NCEPLIBS-ip#226 |
@mkavulich I think this is ready for another round of testing. I'll test the shell scripts on my mac now. You can try it on Cheyenne if you like. Basically, you still need to load all modules that you loaded before building NCEPLIBS-external and NCEPLIBS:
But you should no longer have to set
For your testing, replace the Note that I converted all modulefiles from lua to tcl, hence please pay close attention to module load errors. Some systems don't understand lua, but all understand tcl. Converting them means we don't need to maintain and run the workaround |
There should be no additional dependencies for EMC_post; we used to require Jasper but that is no longer needed. There don't appear to be any extra external dependencies for UFS_UTILS either, but that's just from reading the CMakeLists.txt; I'm not familiar enough with UFS_UTILS to say for sure. UFS_UTILS does require some NCEPLIBS which the weather model does not need (landsfcutil and I think a few others) but I guess the plan will be to load all nceplibs? |
Yes, all NCEPLIBS modules will be loaded. I am currently having an issue with the ufs-weather-model build expecting tthe NCEPLIBS environment variable to be set (even though it could find it without it, but that's a different story). I'll need to add some more logic to this PR. |
Just pushed an update. With this, I can build the ufs-weather-model standalone using |
It also builds with |
@climbfuji I'm still not able to run my own end-to-end tests (including NCEPLIBS-external) because I am not able to check out hdf5...I opened an issue there with more info: NOAA-EMC/NCEPLIBS-external#79 If you would like me to run tests on any specific platforms where NCEPLIBS has already been built let me know. |
Scratch that, whatever problems with the hdf5 repository have now been resolved. Would you like me to run tests on any specific platform? I have access to Cheyenne, Jet, Hera, and Orion. |
How about cheyenne for a start?
… On Oct 22, 2020, at 12:44 PM, Michael Kavulich ***@***.***> wrote:
Scratch that, whatever problems with the hdf5 repository have now been resolved. Would you like me to run tests on any specific platform? I have access to Cheyenne, Jet, Hera, and Orion.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#148 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RMJTA2YYZFRQTSSLITSMB4Q3ANCNFSM4SWRRIYA>.
|
Building on Cheyenne with intel and gnu, I'll let you know the results |
@climbfuji The Cheyenne tests were successful, once I made the above-mentioned capitalization change the NCEPLIBS build successfully for intel and gnu, and created the expected files. The ufs-srweather-app built successfully with the modulefile for intel; I did not test the use of the source files but they were created successfully and looked reasonable. I have started a branch that will update the READMEs and issue a PR when appropriate. The ufs-srweather-app did not build for gnu but this is a known issue that also affected the old build that I haven't had time to look into yet. I did notice that you now have to manually set the ESMFMKFILE path when running cmake for NCEPLIBS whereas before it was not necessary; I guess that can be handled in documentation? |
Thanks for this one, will push the change right away.
Yes, I will add that export statement in each of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@climbfuji I have also successfully run on Orion now, loading the NCEPLIBS modulefile sets the environment correctly. I don't have write privileges in this repository but consider this my approval 👍
That's great, thanks for lettting me know. Let's merge it and fix any issues later. Code freeze is around the corner. Associated PR for NCEPLIBS-external will require documentation updates and maybe an additional modulefile or two (jasper, jpeg) for gaea. |
@kgerheiser @mark-a-potts do you want to take a look or should I merge without your reviews? This is for release/public-v2. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for you work
The SRW App wants an easier way to set environment variables or load modules than loading individual NCEPLIBS modules etc. This was discussed at length in last week's SRW App build team meeting. It was decided to augment the NCEPLIBS with an umbrella modulefile (for systems that use modules) and shell scripts (bash and tcsh; for users on commodity systems without the module environment). This is similar to what was done for the MRW App release.
The approach taken here:
make deploy
will always overwrite existing filesCC
,CXX
,FC
to the umbrella modulefile and the shell scripts; if this is not to be included, we can revert addingCXX
to the cmake project languages - should it be removed?lua2tcl.py
so that the umbrella modulefile can also be convertedCMakeLists.txt
and export environment variablesNETCDF
andESMFMKFILE
(required to build the ufs-weather-model standalone usingbuild.sh
orcompile.sh
)