Add CMake build to UFS_UTILS #91
Comments
Add submodule to NOAA-EMC/CMakeModules repository.
Add required cmake files to build chgres_cube. Update "build_chgres_cube.sh", "modulefiles/chgres_cube.wcoss_dell_p3" and "machine-setup.sh" to invoke cmake on Dell.
|
Added the required cmake files from the public release branch to the 'feature/cmake' branch at cb887b6. The "build_chgres_cube.sh" was updated to invoke cmake from Dell. To get the config step to work, I had to updated the Modules/FindWGRIB2.cmake (under the [email protected]:NOAA-EMC/CMakeModules.git repo) as follows: When I invoke the build script, the configure step works, but the build step fails: The path to the esmf module directory is not being set. Not sure why that is. |
|
CMake finds ESMF through the environment variable |
Add back 'find_package' calls to "CMakeLists.txt". Change fortran instrinsic 'ALOG' to 'LOG' in "surface.F90". Point to official version of esmf v8 on Dell.
|
Update the branch following Kyle's suggestion (725dd1c). The compilation moved past the previous error but now fails at the link step. The path to the netcdf library is not being defined (but it is able to find the netcdf include directory): |
|
Is that because of this? NOAA-EMC/CMakeModules#30 |
I am almost certain that is the problem. But I can't figure out what to do. |
|
If you run |
|
Have you tried adding this block to the top-level CMakeLists.txt in UFS_UTILS before |
I thought the above logic was to replace the find_package. I added that back and it now compiles. Thanks. |
|
Hooray! Sorry, me instructions should have been clearer.
… On Mar 17, 2020, at 12:11 PM, GeorgeGayno-NOAA ***@***.***> wrote:
Have you tried adding this block to the top-level CMakeLists.txt in UFS_UTILS before find_package(NetCDF MODULE REQUIRED) is called?
Add environment variable NETCDF to CMAKE_PREFIX_PATH
for PkgConfig, and set cmake variable accordingly
if(NOT NETCDF)
if(NOT DEFINED ENV{NETCDF})
message(FATAL_ERROR "Environment variable NETCDF not set")
else()
list(APPEND CMAKE_PREFIX_PATH $ENV{NETCDF})
set(NETCDF $ENV{NETCDF})
endif()
if(DEFINED ENV{NETCDF_FORTRAN})
list(APPEND CMAKE_PREFIX_PATH $ENV{NETCDF_FORTRAN})
endif()
endif()
I thought the above logic was to replace the find_package. I added that back and it now compiles. Thanks.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RNN46XCJEQQPS2MYRDRH64OFANCNFSM4LMSJMYQ>.
|
Add back package_find for netcdf. Remove set of compiler and compiler flags from dell build module, which are not used by cmake. Minor cleanup of "build_chgres_cube.sh".
Update compiler flags to those used by 'develop'. Update install directory to that used by 'develop'.
Updates to compile chgres_cube on Hera.
|
Using the branch at 24a7829, I can compile chgres_cube on Dell and Hera. Now I am having problems on Jet. It fails on the link step because the "-openmp" flag is obsolete when using intel v18. I don't have this problem on Dell and Hera, the correct flag "-qopenmp" is used. So how is the link.txt file created? And why does it contain the correct flag on Dell and Hera, but not Jet? |
|
I was looking at your branch. Firstly, the compiler flags are not set in the same way as they are in the release v1 branch ( The way @aerorahul did the rework, the magic happens in Then, in release v1 branch your branch Thus, the first thing I would do is to remove the hard-coded If this works, try it with |
Updates to build on Jet. Turn on openmp check in ./CMakeLists.txt. Remove hard-coded openmp flag in .sorc/chgres_cube.fd/CMakeLists.txt. The flag should be set automatically by cmake openmp check.
|
Per @climbfuji recommendation, updated the branch to remove the hard-coded openmp flag, and to turn on cmake's OPENMP check (54428ec). On Jet, the check works and adds the correct openmp flag during compilation, but not at link time. I updated ./sorc/chgres_cube.fd/CMakeLists.txt to print this message. I assume that is where the link step occurs: and the logic is being tripped with the correct flag: but it is still using -openmp at link time. |
|
@aerorahul do you have any insight on what might be going on? |
|
@GeorgeGayno-NOAA Can you point me to your branch and setup where you are trying to build this. |
|
@climbfuji @GeorgeGayno-NOAA |
|
also, you don't need |
|
Which ESMF version is it that you are using on Jet? I "usually" build ESMF with OPENMP=OFF. |
I have never used ESMFF90LINKOPS when compiling (maybe I should have?). chgres_cube works perfectly fine without it. |
module use /mnt/lfs3/projects/hfv3gfs/gwv/ljtjet/lib/modulefiles |
@GeorgeGayno-NOAA The L103 property is set in L96 of |
Update to build.jet per Rahul's suggestion.
Updates to make threading optional. Note: global_chgres and global_cycle require threads. So don't build them when user does not choose to use threads.
Bug fix to ./emcsfc_snow2mdl.fd/CMakeLists.txt
Move Intel compilation flags to root level CmakeLists.txt file.
Move GNU compilation flags to the root level CMakeLists.txt file.
Add load of build module to the regression test and gdas_init driver scripts (Hera). Ensures consistent module use thru the repository (per Rahul).
Point to Dusan's updated FindWGRIB2.cmake.
Load build module in Jet regression test scripts.
Load build modules within Dell reg test and gdas_util driver scripts.
Load build module within the Cray reg test and gdas_init driver scripts.
Additional clean up for the Cray driver scripts.
Additions updates to Hera driver scripts.
Additional cleanup for Dell driver scripts.
Some additional driver script clean up.
Additional Cray driver script clean up.
|
All reviewer comments have been addressed. See #101 for more details. Next, compile and then rerun all regression tests on Jet, Hera, Cray and Dell. |
|
First, ensure the latest version of the branch (608e52e) compiles on all officially supported machines. This was confirmed on Orion, Hera, Jet, WCOSS-Cray and WCOSS-Dell for the Intel compiler (both Release" and "Debug" build types). On Hera, it was successfully compiled using the GNU compiler (both Release" and "Debug" build types). Additionally, Dusan was able to build it on his Linux workstation. Next, the regression tests will be run. |
|
The grid generation driver scripts (under ./driver_scripts) were modified to remove individual module loads. These (608e52e) were rerun on Jet, Hera, WCOSS-Cray/Dell and confirmed to be working. The GDAS initialization scripts (under ./util/gdas_init) were also modified to remove module loads. They were rerun on Hera, WCOSS-Cray/Dell (there is no Jet version) and confirmed to be working |
|
The nemsio utilities (
All tests worked correctly using 608e52e. |
|
The
All tests worked correctly using the branch at 608e52e. |
|
The |
|
The The test compares the output tiled netcdf files to a baseline set using the These differences are insignificant. |
|
The On Surge, the output from the branch was compared to the baseline file in Grads. The snow cover records were identical. Six snow depth points near -73/Greenwich differed by 0.0001 meters. Differences are likely due to using compiling the branch with "O3" vs "O0" for 'develop' But I can not explain why this difference happened only on the Cray. Anyway, the output, while different, is correct. |
|
The last regression test is for the grid generation codes (./reg_tests/grid_gen) (used 608e52e). The test creates a C96 global uniform grid and C96 regional grid. The 'grid', 'oro' and surface climo files are compared to a baseline set of data using the nccmp command. On Jet, Hera, Surge and Vensu, the global test passed, but the regional test failed. The 'grid' files had differences in the grid box area record. But these are small compared to their magnitude (~10**7). Here is the difference (Venus) for the C96_grid.tile7.halo4.NC file: The differences on other machines were similar. So this is not a problem. The other differences were noted in the filtered orography record. Here is the difference (Venus) for the C96_oro_data.tile7.halo4.nc file: These differences are large enough to be concerning. Examining the differences in ncview, they were confined to the few rows along the lateral boundaries. The interior had no differences. Wanting to know what could be happening, I started to add some print statements. I then discovered an array dimension problem in filter_topo.F90. The orography was incorrectly dimensioned with a rank of 4 instead 3 in routine FV3_zs_filter . When I made the correction: I got this difference from the baseline file: That is very different. So I suspect there is a bug in the |
|
I am seeing similar behavior with If I add another print statement for phis(1,2), I get this difference: So there is likely some kind of memory leak going on with the 'regional' option. So, the CMake build is not the culprit. Will merge the feature/cmake branch to develop. |
|
Merged to 'develop' at 3ad7d83. Closing issue. |
v1 of the public release used CMake to build
chgres_cube. Use CMake to build all programs in the repository. Remove the old build system.The text was updated successfully, but these errors were encountered: