Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

How to install WRF using configure_new in a specific folder

William.Hatheway

William.Hatheway

Active member
Good morning,

I have a question for the admins. I have successfully install WRF v4.6.1 using the configure_new script with Intel OneAPI 2025.

Bash: 
./configure_new -x -p "oneAPI LLVM" -- -DCMAKE_Fortran_COMPILER=ifx -DMPI_Fortran_COMPILER=mpiifx -DMPI_C_COMPILER=mpiicx -DWRF_CORE=ARW -DWRF_NESTING=BASIC -DWRF_CASE=EM_REAL -DUSE_MPI=ON 2>&1 | tee wrf.configure.log

However, I notice that everything is built and installed in the _build folder that is created as part of the script.

It appears that the same folders are in the root directory /WRF AND /_build directory but the .exe files are only in the _build/main folder instead of the WRF/main folder.

I am confused as to why the installation is built in two different locations and the files appear to be the same. Wouldn't that make the installation larger in file size?

Thanks ahead for clearing this up for me.
 
Bash: 
[workhorse@localhost WRFV4.6.1]$ pwd && ls -a
/home/workhorse/WRF_Intel/WRFV4.6.1
.               compile        .git           io_netcdfpar  RSL_LITE
..              compile_new    .github        io_pnetcdf    run
arch            confcheck      .gitignore     lib           share
bin             configure      .gitmodules    LICENSE.txt   test
_build          configure_new  hydro          main          tools
chem            doc            inc            Makefile      var
.ci             dyn_em         include        modules       wrf.compile.log
clean           esmf_time_f90  io_grib1       phys          wrf.configure.log
cleanCMake.sh   external       io_grib_share  README        wrftladj
cmake           fftpack5       io_int         README.md
CMakeLists.txt  frame          io_netcdf      Registry


Bash: 
[workhorse@localhost _build]$ pwd && ls -a
/home/workhorse/WRF_Intel/WRFV4.6.1/_build
.                    dyn_em                main          test
..                   external              Makefile      tools
CMakeCache.txt       frame                 phys          wrf_config.cmake
CMakeFiles           inc                   Registry      WRFConfig.cmake
cmake_install.cmake  install_manifest.txt  registry.log  WRFConfigVersion.cmake
confcheck            libWRF_Core.a         share
[workhorse@localhost _build]$
 
I also noticed that the exeacutables created using configure_new and compile_new are not label with an .exe in the name. Does that change how you execute the commands ./wrf.exe ./real.exe ./tc.exe ???
 
What you are seeing is the out-of-source build nature of CMake. This may appear as a duplication of the folder structure of the project, but does not inherently copy all the files. This keeps the source tree clean of modifications, preventing much of the in situ file changing that is notorious in the make build.

On compilation, you should see now two folders, "_build" and "install" - these are the default locations if no alternate paths are provided. To use a different location for each you can use -d and -i when configuring to change the build or install directories, respectively. Once done, the install path is "baked into" that configuration so this does not need to be specified again. Instead if the first argument is a directory for ./compile_new it will use that directory's configuration to build (if none is provided it will look for _build and use what is in there).

For .exe suffixes (which are not *nix standard and a Windows thing) the primary executables do not have this suffix within the install/bin/ directory. However, to provide backward compatibility symlinks are supplied to these binaries in the locations that one would normally see them after adapting workflows to use the install directory. As an example :
Code: 
$ ll install/run/*.exe
lrwxrwxrwx. 1 aislas aislas 44 Mar  7 16:44 install/run/ndown.exe -> /home/aislas/wrf-model/wrf/install/run/ndown*
lrwxrwxrwx. 1 aislas aislas 43 Mar  7 16:44 install/run/real.exe -> /home/aislas/wrf-model/wrf/install/run/real*
lrwxrwxrwx. 1 aislas aislas 41 Mar  7 16:44 install/run/tc.exe -> /home/aislas/wrf-model/wrf/install/run/tc*
lrwxrwxrwx. 1 aislas aislas 42 Mar  7 16:44 install/run/wrf.exe -> /home/aislas/wrf-model/wrf/install/run/wrf*
$ ll install/test/em_real/*.exe
lrwxrwxrwx. 1 aislas aislas 53 Mar  7 16:44 install/test/em_real/ndown.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/ndown*
lrwxrwxrwx. 1 aislas aislas 52 Mar  7 16:44 install/test/em_real/real.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/real*
lrwxrwxrwx. 1 aislas aislas 50 Mar  7 16:44 install/test/em_real/tc.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/tc*
lrwxrwxrwx. 1 aislas aislas 51 Mar  7 16:44 install/test/em_real/wrf.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/wrf*
$ ll -la install/test/em_real/wrf*
lrwxrwxrwx. 1 aislas aislas 42 Mar  7 16:44 install/test/em_real/wrf -> /home/aislas/wrf-model/wrf/install/bin/wrf*
lrwxrwxrwx. 1 aislas aislas 51 Mar  7 16:44 install/test/em_real/wrf.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/wrf*

run/ and test/em_real inside the install directory have wrf and wrf.exe where wrf.exe -> wrf and the local wrf in those folders just points to the actual executable found at install/bin/wrf
 
islas said:
What you are seeing is the out-of-source build nature of CMake. This may appear as a duplication of the folder structure of the project, but does not inherently copy all the files. This keeps the source tree clean of modifications, preventing much of the in situ file changing that is notorious in the make build.

On compilation, you should see now two folders, "_build" and "install" - these are the default locations if no alternate paths are provided. To use a different location for each you can use -d and -i when configuring to change the build or install directories, respectively. Once done, the install path is "baked into" that configuration so this does not need to be specified again. Instead if the first argument is a directory for ./compile_new it will use that directory's configuration to build (if none is provided it will look for _build and use what is in there).

For .exe suffixes (which are not *nix standard and a Windows thing) the primary executables do not have this suffix within the install/bin/ directory. However, to provide backward compatibility symlinks are supplied to these binaries in the locations that one would normally see them after adapting workflows to use the install directory. As an example :
Code: 
$ ll install/run/*.exe
lrwxrwxrwx. 1 aislas aislas 44 Mar  7 16:44 install/run/ndown.exe -> /home/aislas/wrf-model/wrf/install/run/ndown*
lrwxrwxrwx. 1 aislas aislas 43 Mar  7 16:44 install/run/real.exe -> /home/aislas/wrf-model/wrf/install/run/real*
lrwxrwxrwx. 1 aislas aislas 41 Mar  7 16:44 install/run/tc.exe -> /home/aislas/wrf-model/wrf/install/run/tc*
lrwxrwxrwx. 1 aislas aislas 42 Mar  7 16:44 install/run/wrf.exe -> /home/aislas/wrf-model/wrf/install/run/wrf*
$ ll install/test/em_real/*.exe
lrwxrwxrwx. 1 aislas aislas 53 Mar  7 16:44 install/test/em_real/ndown.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/ndown*
lrwxrwxrwx. 1 aislas aislas 52 Mar  7 16:44 install/test/em_real/real.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/real*
lrwxrwxrwx. 1 aislas aislas 50 Mar  7 16:44 install/test/em_real/tc.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/tc*
lrwxrwxrwx. 1 aislas aislas 51 Mar  7 16:44 install/test/em_real/wrf.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/wrf*
$ ll -la install/test/em_real/wrf*
lrwxrwxrwx. 1 aislas aislas 42 Mar  7 16:44 install/test/em_real/wrf -> /home/aislas/wrf-model/wrf/install/bin/wrf*
lrwxrwxrwx. 1 aislas aislas 51 Mar  7 16:44 install/test/em_real/wrf.exe -> /home/aislas/wrf-model/wrf/install/test/em_real/wrf*

run/ and test/em_real inside the install directory have wrf and wrf.exe where wrf.exe -> wrf and the local wrf in those folders just points to the actual executable found at install/bin/wrf
Click to expand...
Thank you for explaining that clears up a lot.

Does the physical size of the WRF folder get larger due to the install and build location's having multiple copies of the other folder/files that are in the old method of compiling or are they all just links?
 
I think it would be tough to generalize whether the old or new compilation takes more memory. While there are significantly new folders created in the out-of-source build, it avoids preprocess intermediate files where possible saving almost entire duplication of the code from .F to .f90. This would be further influenced by the size of the includes generated by the registry, which is variable based on configuration.

If there is concern over the on-disk memory footprint of a WRF install, you can entirely delete the _build directory after compilation is finished.
 
islas said:
I think it would be tough to generalize whether the old or new compilation takes more memory. While there are significantly new folders created in the out-of-source build, it avoids preprocess intermediate files where possible saving almost entire duplication of the code from .F to .f90. This would be further influenced by the size of the includes generated by the registry, which is variable based on configuration.

If there is concern over the on-disk memory footprint of a WRF install, you can entirely delete the _build directory after compilation is finished.
Click to expand...
So the build directory doesn't need to remain for the installation directory to function?
 
Correct. In fact, using the -i and -d flags, one can build multiple instances of WRF at the same time from the same source tree and install to different locations, further reducing the need of one WRF source tree per build.

Once installed, the install folder should function one-to-one with the expected workflow of the make build in executables and relative location of files (ex going into test/em_real when building the EM_REAL case). The install process makes sure to copy everything that is needed first, and only create links referencing items within the install so that the _build directory is not a dependency. At the very least, that is the intention.
 
You must log in or register to reply here.
Top