jcsda / crtm Goto Github PK

Hello Benjamin,

Please help me to fix this issue i am unable to compile crtm-2.3.0 with GCC.
I have loaded module

$ module load gcc/6.3.0
$ module load gnu/hdf5/1.8.20
$ module load gnu/lib/netcdf_c/4.6.0
. config-setup/gfortran.setup
./configure --prefix=/home/raj/software/crtm/raj/crtm_gcc/REL-2.3.0/codes

Above command run successfully, but when i run make command it gives me error.
I don't know where i am doing the mistake please suggest me to fix this issue. Without crtm i am unable to compile CRTM_tutorial.

$ make
cd libsrc && make all
make[1]: Entering directory '/home/raj/software/crtm/raj/crtm_gcc/REL-2.3.0/libsrc'
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Type_Kinds.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c File_Utility.f90
File_Utility.f90:328:0:

     IF ( Buffer(1:1) == cChar ) CYCLE Count_Loop
Warning: 'cchar[1]{lb: 1 sz: 1}' may be used uninitialized in this function [-Wmaybe-uninitialized]
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Message_Handler.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Date_Utility.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c DateTime_Utility.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Timing_Utility.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Compare_Float_Numbers.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Endian_Utility.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Binary_File_Utility.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Sort_Utility.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Search_Utility.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c String_Utility.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Fundamental_Constants.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Hyperbolic_Step.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Spectral_Units_Conversion.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c UnitTest_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c SensorInfo_Parameters.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c Subset_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c NLTECoeff_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c ACCoeff_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c SpcCoeff_Define.f90
SpcCoeff_Define.f90:1482:0:

ELEMENTAL SUBROUTINE SpcCoeff_ClearSensor(SpcCoeff)

Warning: 'spccoeff_clearsensor' defined but not used [-Wunused-function]
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c NLTECoeff_Binary_IO.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c ACCoeff_Binary_IO.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c SpcCoeff_Binary_IO.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c CloudCoeff_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c CloudCoeff_Binary_IO.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c AerosolCoeff_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c AerosolCoeff_Binary_IO.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c CRTM_Aerosol_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c CRTM_Cloud_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c CRTM_Parameters.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c CRTM_Atmosphere_Define.f90
gfortran -fconvert=big-endian -O3 -fimplicit-none -ffree-form -fno-second-underscore -frecord-marker=4 -funroll-loops -ggdb -Wall -Wconversion -std=f2008 -c CRTM_CloudCover_Define.f90
CRTM_CloudCover_Define.f90:1423:8:

 self         , &
    1
Error: INTENT(OUT) argument 'self' of pure procedure 'create' at (1) may not be polymorphic
CRTM_CloudCover_Define.f90:1355:36:

ELEMENTAL SUBROUTINE Destroy( self )
1
Error: INTENT(OUT) argument 'self' of pure procedure 'destroy' at (1) may not be polymorphic
CRTM_CloudCover_Define.f90:1478:8:

 self         , &
    1
Error: INTENT(OUT) argument 'self' of pure procedure 'ivar_create' at (1) may not be polymorphic
CRTM_CloudCover_Define.f90:1360:41:

ELEMENTAL SUBROUTINE iVar_Destroy( self )
1
Error: INTENT(OUT) argument 'self' of pure procedure 'ivar_destroy' at (1) may not be polymorphic
make.rules:14: recipe for target 'CRTM_CloudCover_Define.o' failed
make[1]: *** [CRTM_CloudCover_Define.o] Error 1
make[1]: Leaving directory '/home/raj/software/crtm/raj/crtm_gcc/REL-2.3.0/libsrc'
Makefile:17: recipe for target 'all' failed
make: *** [all] Error 2

Thanks on Advance

A simple issue: make it so the CRTM_Planck_Functions are available for use in the GSI

Required for related GSI Issue NOAA-EMC/GSI#546. A subroutine added to crtm_interface.f90 for this issue requires the use of a few of the subroutines in CRTM_Planck_Functions.f90 (CRTM_Planck_Radiance, CRTM_Planck_Radiance_TL, and CRTM_Planck_Temperature_TL).

No major code changes are required here (I think, please correct me if I'm wrong); the CRTM_Planck_Functions just need to be added to CRTM_Module.F90

Associated commit to https://github.com/erinjones2/crtm.git - da5e474

Affected Branch

release/REL-2.4.0

Machine & env

1. Apple Silicon M1 Pro + Homebrew gcc version 13.1.0 (Homebrew GCC 13.1.0)
2. Apple Silicon M1 Pro + Homebrew gcc version 12.2.0 (Homebrew GCC 12.2.0)
3. Intel 6700 + ubuntu 22.04 LTS + gcc version 11.0

Description

I'm building the REL-2.4.0 following the steps documented in REDME.md instead of using ecbuild.
When running ./configure --prefix=${PWD} in the Build Step 1, I got the following error

configure: error: Fortran compiler cannot create executables

The error tracing back shows that this was due to the compling flag -mieee-fp (FCFLAGS in configuration/gfortran*.setup) not supported by gfortran 12.2.0/13.1.0 on my Apple Silicon Macbook Pro.
After removing this flag, the CRTM can be built successfully.

The corrected one has been tested in the above three envs and passed building tests.

Solution

I have updated this branch at https://github.com/gmao-cda/crtm/tree/fix/release/REL-2.4.0_armflag

1. One additional check is added to configuration/gfortran.setup and configuration/gfortran-debug.setup to see if the computer arch is arm64-based. If so, drop the-mieee-fp flag
2. Besides, remove the hard-coded approach to get NC4_DIR and HDF_DIR in configuration/gfortran*.setup.

Downloading src/Build/CMakeFiles/3.17.1/CMakeDetermineCompilerABI_Fortran.bin (803 KB)
Error downloading object: src/Build/CMakeFiles/3.17.1/CMakeDetermineCompilerABI_Fortran.bin (1459d4a): Smudge error: Error downloading src/Build/CMakeFiles/3.17.1/CMakeDetermineCompilerABI_Fortran.bin (1459d4a96c146edcaf484f8a4230cc1dfa26cf798ac6f30179f954d669042e76): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

Errors logged to /Users/KIG/Desktop/crtm-v2.4.0/.git/lfs/logs/20220218T120023.172711.log

git-lfs over the limit. What is git-lfs downloading here? I think I just want the source code.

The distributed installation guide and scripts assume a particular installation directory. This assumption may not be universal applicable. the installation guide suggests the standard configuration syntax,

./configure --prefix=/your/preferred/installation/path

it is a bit odd that some of the setup scripts (Set_CRTM_Environment.sh)
has a different syntax (a BINDIR has to be defined which is /your/preferred/installation/path/bin if i understood it correctly) and has to be run first.
also all netcdf4/hdf5 libraries does not have to be available in the location which is hard coded in some of the scripts which has to be run first.
the setting of the BINDIR and of the NC4_DIR, HDF_DIR was not mentioned in the README.md file. This was causing some issues as the first attempt to compile as the first pass returned an error

Once i had figured this out and modified in the fortran setup scripts
export NC4_DIR=${HOME}/local/ #singularity container only
export HDF_DIR=${HOME}/local/ #singularity container only

compilation went smooth, and make check went fine, make install worked also fine
I did not modify the BINDIR so not sure this is critical as my PATH environment has the ${HOME}/local/bin where all my code ends up (not to confuse the system directories).

Maybe you could update the README.md file to inform the new user of setting some of the environmental variables to local situation.

Per EMC request: This issue covers the removal of extraneous print statements from the CRTM output, particularly regarding the cloud coefficient file.

branch release/REL-2.4.0_emc

this is a test for public issue creation.

I am adding cloud_liquid_water as a bias correction predictor for GMI/GPM. The cloud is a mean cloud amount value of retrieved from observations and simulations. These two retrievals are compared to determine whether this mean cloud predictor should be used for data at the observed location. In other words, this predictor is not used for all GMI observations. Therefore, these two clouds, not the mean value, are needed. In order to make source codes and configurations simple, I tend to use the "CLWRetMW " function in a new subroutine in "CloudLiquidWater.h":

static void clwDerivative_gmi(const ObsFilterData &,
std::vector &);

Here is a section of my configuration in my yaml file. :

obs bias:
input file: Data/ufo/testinput_tier_1/gsi.x0044j.bc.gmi_gpm.2020-12-14T21:00:00Z.satbias.nc4
variational bc:
predictors:
- name: constant
- name: lapse_rate
order: 2
tlapse: &gmitlap Data/ufo/testinput_tier_1/gsi.x0044j.bc.gmi_gpm.2020-12-14T21:00:00Z.tlapse.txt
- name: lapse_rate
tlapse: *gmitlap
- name: emissivity
- name: cloud_liquid_water
satellite: GPM
options:
clwret_ch37v: 6
clwret_ch37h: 7
clwret_types: [ObsValue, HofX]
....

My changes are added in the attached CloudLiquidWater.h and CloudLiquidWater.cc (renamed as *txt). Here is the error message when I tried to build UFO:
[ 37%] Building CXX object ufo/src/ufo/CMakeFiles/ufo.dir/predictors/CloudLiquidWater.cc.o
/discover/nobackup/jjin3/jedi/fv3-bundle/ufo/src/ufo/predictors/CloudLiquidWater.cc(182): error: type name is not allowed
CloudLiquidWater::clwDerivative_gmi( ObsFilterData,
^
/discover/nobackup/jjin3/jedi/fv3-bundle/ufo/src/ufo/predictors/CloudLiquidWater.cc(242): error: declaration is incompatible with "void ufo::CloudLiquidWater::clwDerivative_gmi(const ufo::ObsFilterData &, std::vector<float, std::allocator> &)" (declared at line 80 of "/discover/nobackup/jjin3/jedi/fv3-bundle/ufo/src/ufo/predictors/CloudLiquidWater.h")
void CloudLiquidWater::clwDerivative_gmi(const ObsFilterData & in,
^
compilation aborted for /discover/nobackup/jjin3/jedi/fv3-bundle/ufo/src/ufo/predictors/CloudLiquidWater.cc (code 2)
ufo/src/ufo/CMakeFiles/ufo.dir/build.make:730: recipe for target 'ufo/src/ufo/CMakeFiles/ufo.dir/predictors/CloudLiquidWater.cc.o' failed
make[2]: *** [ufo/src/ufo/CMakeFiles/ufo.dir/predictors/CloudLiquidWater.cc.o] Error 2
CMakeFiles/Makefile2:15843: recipe for target 'ufo/src/ufo/CMakeFiles/ufo.dir/all' failed
make[1]: *** [ufo/src/ufo/CMakeFiles/ufo.dir/all] Error 2
Makefile:165: recipe for target 'all' failed
make: *** [all] Error 2

Is there any suggestions to solve this problem? Thanks.

gmi_qc_filters.yaml.txt
CloudLiquidWater.h.txt
CloudLiquidWater.cc.txt
.

I am installing crtm with gfortran but getting an error message:
arallels@debian:~/METPLUS/crtm/src/Build$ make -j4
cd libsrc && make all
make[1]: Entering directory '/home/parallels/METPLUS/crtm/src/Build/libsrc'
Makefile:94: make.rules: No such file or directory
make[1]: *** No rule to make target 'make.rules'. Stop.
make[1]: Leaving directory '/home/parallels/METPLUS/crtm/src/Build/libsrc'
make: *** [Makefile:17: all] Error 2

any hint on this?

reported by gmao-yzhu the CRTM v2.4 AMSU-A coefficient for MetOp-C in the little endian folder is actually big endian

I am getting some unexpected results and I wonder if I am doing something wrong or there is some other reason. I am using pyCRTM (with CRTM 2.4.0) but have also verified just using Fortran 90.

Emissivity and reflectivity don’t sum to 1 (sometimes as much as 1.15) for microwave channels (e.g. GMI). Is this intentional?

Some temperature Jacobians are negative in places (see figure). From a basic analysis of radiative transfer equations, it would seem that increasing the temperature of a level (and changing nothing else) should always make the TB change positive (or zero). What am I missing?

Thanks!

I am unable to compile v2.4.0_emc.3 with GCC (I tried with versions 8 and 11) on account of some lines in RSS_Emissivity_Model.f90 being too long (i.e., past the default limit which I think is 132). I'm able to get around it by adding -ffree-line-length-none to CMAKE_Fortran_FLAGS in libsrc/CMakeLists.txt. On a related note, I would suggest allowing CMAKE_Fortran_FLAGS to accommodate user-provided values (from $FFLAGS env variable or by setting -DCMAKE_Fortran_FLAGS=... on the command line). I think doing something like set(CMAKE_Fortran_FLAGS "-g -fbacktrace -fconvert=big-endian ${CMAKE_Fortran_FLAGS}") would have that effect.

Per NOAA-EMC/GSI#447 (comment)

EMC finds substantial differences between the 2.4.0_emc fix/ directories and what spack stack provides for v2.4.0.

"445 Sensor/TauCoeff files differ" 1706 files in spack-stack vs 1410 files in production.

Also: JCSDA/spack-stack#735

$ sh Get_CRTM_Binary_Files.sh
downloading fix_REL-2.4.0.tgz, please wait about 5 minutes (3.2 GB tar file)
tar (child): fix_REL-2.4.0.tgz: Cannot open: No such file or directory

Could you please check if the ftp link "ftp://ftp.ucar.edu/pub/cpaess/bjohns/fix_REL-2.4.0.tgz" works? Thanks!

Hello, I conducted a couple of clear-sky runs with CRTM-2.1.3 and the latest 2.4.0 version with the latest database. One thing I found is that, for both versions, the TOA BT simulations for all CO2 channels varies only if CO2 concentrations are in 360~400 ppmv range. I tested this for MODIS and GOES-R ABI. Is there a way we can go beyond the 360-400 boundary? Thanks!