Options to choose between .bin and .nc4 coefficients

[wilsonr1]

Is there a way to chose between using the different types of coefficient files? I have gotten a few segmentation faults when I am computing brightness temperatures for AIRS and CrIS, and I don't subset down to a very small number of channels. I'd like to check to see if its an issue with the netCDF coefficients, or if its something else.

[wilsonr1]

This might be related. Only some of the test scripts work correctly when I run them. Some of them give me a Segmentation fault (core dumped) error. For example running test_atms.py gives me this error, "CRTM_Compute_SfcOptics(FAILURE) : Unrecognised polarization flag for microwave channel index 817
Assign_Common_Input(FAILURE) : Error computing SfcOptics for atms_npp channel -1441107185
CRTM_Compute_RTSolution(FAILURE) : Error assigning input for RTSolution algorithms
CRTM_Forward(FAILURE) : Error computing RTSolution for atms_npp, channel 129, profile #1
Segmentation fault (core dumped)" . But I can run test_atms_threads.py just fine.

[karpob]

If you use subsetting with multi-threading, this can be an issue in general for CRTMv3.

If you're running test_atms.py with no modifications, that is definitely not something I've seen before. What OS platform and compiler version are you using? Are you using the make_it_so.sh script, or pointing to another pre-built crtm build? As a first test to isolate things, I would make sure to set this in your shell when running test_atms.py:

export OMP_NUM_THREADS=8

The easiest way to make sure the interface is using either netCDF or binary is to remove/move/rename the symlink in crtm_coefficients (if you used the make_it_so.sh script) or whatever is set in setup.cfg for path_used. I doubt this is a netCDF issue, however, this seems like an OpenMP configuration problem to me.

[wilsonr1]

Hi Bryan,

This is was built Red Had Enterprise Linux system version 8, and was built with gcc/gfortran version 12.2.1. It was actually a labor of love getting it built as I am very new to cmake. I ran make_it_so.sh and got it to build CRTMv3.1.1 , but it had errors building pyCRTM. I had to create my own python (3.11) environment, and I loaded all the packages I saw in your discover.sh file. I also had to set the cmake_args environment variable to point to the places where the python libraries were. One thing that I found interesting is that I had to set CMAKE_GENERATOR=Ninja to get pyCRTM to build, but that would mess up building CRTM.

Back to the original question though. setting OMP_NUM_THREADS=8 did make all the test scripts run now. Thank you for that!

One more question though. CRTM can take various units for gases and water vapor in. Does pyCRTM assume a unit for this? From the h5 file it seems like g/kg for water vapor.

[karpob]

Yes, units are all the same as in CRTM, pyCRTM is just a wrapper around CRTM, so any units etc, are going to be that documented in CRTM (e.g., https://github.com/JCSDA/crtm/wiki)