Decide on default install location for v3.1.x

[BenjaminTJohnson]

in V3.1.0, the default install location (make install) was in the current build directory. This creates a lib64 directory.

in V3.1.1, the default install location reverted to /usr/local -- not clear where that crept in.

Current solution:
<...>/build> cmake -DCMAKE_INSTALL_PREFIX=./ ..

Will replicate the previous default install behavior. Of course you can use the above to set your favorite install location.

[emilyhcliu]

I built CRTMv.3.1.1 with the following command:
<...>/build> cmake -DCMAKE_INSTALL_PREFIX=./ ..

The libcrtm.so and libcrtm_static.a will show up in ./build/src

Then I do make install

-- Install configuration: "Release"
-- Installing: /work/noaa/da/eliu/HERCULES/CRTM/CRTMv3.1.1/build/lib64/libcrtm.so
-- Set runtime path of "/work/noaa/da/eliu/HERCULES/CRTM/CRTMv3.1.1/build/lib64/libcrtm.so" to ""
-- Up-to-date: /work/noaa/da/eliu/HERCULES/CRTM/CRTMv3.1.1/build/lib64/cmake/crtm/crtm-config.cmake
-- Up-to-date: /work/noaa/da/eliu/HERCULES/CRTM/CRTMv3.1.1/build/lib64/cmake/crtm/crtm-config-version.cmake
-- Up-to-date: /work/noaa/da/eliu/HERCULES/CRTM/CRTMv3.1.1/build/lib64/cmake/crtm/crtm-targets.cmake
-- Up-to-date: /work/noaa/da/eliu/HERCULES/CRTM/CRTMv3.1.1/build/lib64/cmake/crtm/crtm-targets-release.cmake

The only libcrtm.so is installed under build/lib.

[emilyhcliu]

When I built CRTMv3.1.1 on Hercules, it worked without problems.
When I built CRTMv3.1.1 on HERA, the following errors occurred:

[  1%] Building Fortran object src/CMakeFiles/crtm_static.dir/AtmAbsorption/ODPS/ODPS_Predictor.f90.o
/scratch1/NCEPDEV/da/Emily.Liu/Tropics/CRTM/CRTMv3.1.1/src/AtmScatter/CRTM_CloudScatter.f90:1722:64:

        cloud_loc = FINDLOC(CLOUD_TYPE_MIE_TAMU, Cloud_Type, DIM=1) - 1
                                                                1
Error: Keyword argument requires explicit interface for procedure ‘findloc’ at (1)
/scratch1/NCEPDEV/da/Emily.Liu/Tropics/CRTM/CRTMv3.1.1/src/AtmScatter/CRTM_CloudScatter.f90:1722:19:

        cloud_loc = FINDLOC(CLOUD_TYPE_MIE_TAMU, Cloud_Type, DIM=1) - 1
                   1

[BenjaminTJohnson]

This is a limitation of older compiler versions. What compiler / version are you using? I can fix this by rewriting findloc (a f2008 intrinsic) using older minval / minloc intrinsics.

[emilyhcliu]

This is a limitation of older compiler versions. What compiler / version are you using? I can fix this by rewriting findloc (a f2008 intrinsic) using older minval / minloc intrinsics.

I am loading jedi spack stack on HERA. So, the intel compiler/version is intel/2022.1.2.
Let me remove my build directory and do it again to make sure if there are errors before you do any work.
I will report back here shortly.

[BenjaminTJohnson]

Usually what's happening here is that the environment is trying to use gfortran compiler instead of intel, you can see what compiler its trying to use during the cmake step.

[emilyhcliu]

Rebuild using the following compiler/version:
The Fortran compiler identification is GNU 8.5.0

make -j12 resulted in the following error message:

[ 67%] Building Fortran object src/CMakeFiles/crtm_static.dir/AtmScatter/CRTM_CloudScatter.f90.o
/scratch1/NCEPDEV/da/Emily.Liu/Tropics/CRTM/CRTMv3.1.1/src/AtmScatter/CRTM_CloudScatter.f90:1722:64:

        cloud_loc = FINDLOC(CLOUD_TYPE_MIE_TAMU, Cloud_Type, DIM=1) - 1
                                                                1
Error: Keyword argument requires explicit interface for procedure ‘findloc’ at (1)
/scratch1/NCEPDEV/da/Emily.Liu/Tropics/CRTM/CRTMv3.1.1/src/AtmScatter/CRTM_CloudScatter.f90:1722:19:

        cloud_loc = FINDLOC(CLOUD_TYPE_MIE_TAMU, Cloud_Type, DIM=1) - 1
                   1

[BenjaminTJohnson]

try:

module unload gcc
module load stack-intel
export FC=ifort

Then do cmake.

[emilyhcliu]

O

try:

module unload gcc
module load stack-intel
export FC=ifort

Then do cmake.

I will try that. Thanks!

[emilyhcliu]

try:

module unload gcc
module load stack-intel
export FC=ifort

Then do cmake.

I will try that. Thanks!

It worked!!
I tried the JEDI models again.
The intel compiler used is the following:
The Fortran compiler identification is Intel 2021.5.0.20211109

The make -j4 completed successfully.

[BenjaminTJohnson]

Great. The use of that intrinsic is a little bit problematic because it raises the base compatibility level with older compiler versions pretty high, so I think I will work on a method for replacing that intrinsic so that we can be compatible with much older versions of compilers.

[emilyhcliu]

My builds on Hercules and Orion were successful.
So, I went ahead and tried CRTMv3.1.1 with GSI.
The simulation of ATMS and AMSU-A are OK.
However, all other sensor, there are failure from CRTM_K_Matrix. Here are the error messages:

 CRTM_K_Matrix(FAILURE) : N_PHASE_ELEMENTS NOT RIGHT FW 0
 CRTM_K_Matrix(FAILURE) : 1 profiles failed
 crtm_interface*call_crtm:  ***ERROR*** during crtm_k_matrix call            3

Do you have any suggestion? I am using the binary coefficients comes with the CRTMv3.1.1 package.
It seems like a coefficient problem. I probably use the wrong coefficients?

[emilyhcliu]

My builds on Hercules and Orion were successful. So, I went ahead and tried CRTMv3.1.1 with GSI. The simulation of ATMS and AMSU-A are OK. However, all other sensor, there are failure from CRTM_K_Matrix. Here are the error messages:

 CRTM_K_Matrix(FAILURE) : N_PHASE_ELEMENTS NOT RIGHT FW 0
 CRTM_K_Matrix(FAILURE) : 1 profiles failed
 crtm_interface*call_crtm:  ***ERROR*** during crtm_k_matrix call            3

Do you have any suggestion? I am using the binary coefficients comes with the CRTMv3.1.1 package. It seems like a coefficient problem. I probably use the wrong coefficients?

@BenjaminTJohnson, I figured out what the issue was. There is nothing wrong with the CRTMv.3.1.1 code. No worries.
GSI needs to make a minor change in crtm_interface.f90 to use CRTMv3.1.1 correctly. Please see my following comments for an explanation.

[emilyhcliu]

CRTMv3/src/CRTM_K_Matrix_Module.f90

Lines 710 to 717 in 229ff89

	IF( (CloudC%N_PHASE_ELEMENTS /= AeroC%N_PHASE_ELEMENTS) .or. &
	(RTV(1)%n_Stokes > 1.and.CloudC%N_PHASE_ELEMENTS < 6) ) THEN
	Error_Status = FAILURE
	WRITE( Message,'("N_PHASE_ELEMENTS NOT RIGHT FW ",i0)' ) CloudC%N_PHASE_ELEMENTS
	CALL Display_Message( ROUTINE_NAME, Message, Error_Status )
	RETURN
	END IF

The above code block indicates that if the cloud coefficients are loaded, the aerosol coefficients need to be loaded as well. So, I modified GSI to load the aerosol coefficients for all-sky assimilation of ATMS and AMSU-A, for which the cloud coefficients are required. This resolved the issue of n_phase_elenemts difference between cloud and aerosol coefficients.