Skip to content

Load NLTE/ACCoeff when using netCDF coefficients - #329

Closed
cd10kfsu wants to merge 3 commits into
JCSDA:developfrom
cd10kfsu:bugfix/cda/nlte_ac
Closed

Load NLTE/ACCoeff when using netCDF coefficients#329
cd10kfsu wants to merge 3 commits into
JCSDA:developfrom
cd10kfsu:bugfix/cda/nlte_ac

Conversation

@cd10kfsu

Copy link
Copy Markdown

Description

I’m using CRTMv3 tag v3.1.4 from JCSDA’s GitHub and simulating cris399_npp. It seems that NLTE correction is not activated even if I choose to apply NLTE in CRTM_Options_Type.

A further digging shows that using the netCDF coefficients, the NLTE and Antenna Correction Coefficients are not loaded into CRTM, so no correction to final output radiance no matter if choosing to apply NLTE or AC corrections in CRTM_Options_Type.

Cause

The cause is due to the missed component loading NLTE and AC coefficients from separate nc files in the function of SpcCoeff_netCDF_ReadFile in the file Coefficients/SpcCoeff/SpcCoeff_netCDF_IO.f90
The corresponding module reading the binary coefficients does not have this problem (SpcCoeff_Binary_ReadFile loads NLTE and AC in the file Coefficients/SpcCoeff/SpcCoeff_Binary_IO.f90).

Impact of this bug

  • This bug affects the simulation of hyper IR (NLTE), and AMSU-A/B, MHS (AC).
  • Simulations reading binary coefficients are not affected by this bug.

Fix

Corrections have been made to SpcCoeff_netCDF_IO.f90 to read in AC/NLTE coeffs.

Note that My fixing branch is https://github.com/cd10kfsu/CRTMv3/tree/bugfix/cda/nlte_ac
This change is made upon the tag v3.1.4 (commit cd10kfsu@0f1ab81), but it seems I cannot directly file my PR on top of it, so I temporarily PR to develop.

Let me know if you want me to write some ctests for it.

Issue(s) addressed

n/a

Dependencies

n/a

Impact

Expected impact on downstream repositories:

This bug fix affects the simulation of hyper IR (NLTE), and AMSU-A/B, MHS (AC). Now the simulation for these sensors should be consistent between using netCDF and Binary coefficients.

Checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have run the unit tests before creating the PR

BenjaminTJohnson and others added 3 commits June 8, 2026 17:49
@BenjaminTJohnson

Copy link
Copy Markdown
Contributor

Thanks for identifying and fixing this. Closing without merging because the same issue is already resolved on the v3.2.0 release line (feature/btj_REL-3.2.0): SpcCoeff_netCDF_ReadFile now loads the ACCoeff and NLTECoeff siblings into SpcCoeff%AC and SpcCoeff%NC, with the same sensor-consistency checks (Sensor_Id, WMO ids, channels).

One detail worth flagging: the REL-3.2.0 fix tree ships the siblings in their own subdirectories (fix/ACCoeff/netCDF/ and fix/NLTECoeff/netCDF/), not next to the SpcCoeff file. This PR resolves the sibling in the same directory as the SpcCoeff file, so it would not find them in the shipped fix tree. The release-line reader handles the canonical subdirectory layout and also falls back to the same-directory layout, and it uses a dynamically sized path buffer so long paths are not truncated.

The fix reaches develop when the release line merges back. Happy to have you review that change when it lands, and thanks again for the clear diagnosis.

@cd10kfsu

Copy link
Copy Markdown
Author

Thanks for the update! It's great to know that this issue will be fixed in REL-3.2.0.

For the coefficients, I usually soft link all the coefficients into a single directory. Seems that I need to create the required subdirectory structure when using REL-3.2.0.

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants