Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/cd mw water emis #184

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Conversation

chengdang
Copy link
Contributor

@chengdang chengdang commented Oct 8, 2024

Description

  • This PR adds a new module (CRTM_MWwaterCoeff_Load_FASTEM) to load MWwater_Coeff directly from the existing MWwaterCoeff generation packages (EmisCoeff/MW_Water/MWwaterCoeff_CreateFile).
  • With FASTEM6 (default) and FASTEM4, no LUTs are required to initialize CRTM.
  • With FASTEM5, users still need the corresponding Binary LUTs (FASTEM5.MWwater.EmisCoeff.bin, MWwaterLUT.bin). The initialization module (CRTM_MWwaterCoeff_Load) is currently commented out in CRTM_LifeCycle.F90. Users who wish to use this scheme should contact the CRTM team directly.
  • One unit test is added to demonstrate modules CRTM_MWwaterCoeff_Load and CRTM_MWwaterCoeff_Load_FASTEM are equivalent for FASTEM6 and FASTEM4. This test may be deleted after the new loading method is fully tested.

Issue(s) addressed

This PR is part of the CRTM surface emissivity code sprint.

Dependencies

None

Impact

  • CRTM uses FASTEM6 by default (no arguments are needed); No binary table is needed.
  • To use FASTEM4, set MWwaterCoeff_Scheme = FASTEM4 in CRTM_Init(); No binary table is needed.
  • To use FASTEM 5, contact the CRTM team direct for additional support.

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

@chengdang chengdang self-assigned this Oct 8, 2024
@BenjaminTJohnson
Copy link
Contributor

intel 2021.10.0, release build on S4:

The following tests FAILED:
	 17 - test_forward_Simple_atms_n21 (Failed)
	 18 - test_forward_Simple_cris-fsr_n21 (Failed)
	 20 - test_forward_Simple_atms_npp (Failed)
	 21 - test_forward_Simple_cris399_npp (Failed)
	 25 - test_forward_AOD_cris-fsr_n21 (Failed)
	 26 - test_forward_AOD_v.abi_g18 (Failed)
	 27 - test_forward_AOD_cris399_npp (Failed)
	 28 - test_forward_AOD_v.abi_gr (Failed)
	 29 - test_forward_AOD_abi_g18 (Failed)
	 30 - test_forward_AOD_airs_aqua (Failed)
	 37 - test_forward_ClearSky_atms_n21 (Failed)
	 47 - test_forward_ScatteringSwitch_atms_n21 (Failed)
	 63 - test_forward_SOI_atms_n21 (Failed)
	143 - test_adjoint_Simple_atms_n21 (Failed)
	159 - test_tangent_linear_Simple_atms_n21 (Failed)
	167 - test_tangent_linear_ClearSky_atms_n21 (Failed)
	175 - test_forward_OMPoverChannels_atms_n21 (Failed)

These are all failures on matching the previous ctest results. I also see

   AAAAAAAA 2.261634509803921E+06
   AAAAAAAA

Is that your debugging? I can't find where it's coming from though, which is weird....

Also some floating point exceptions are occuring... and there appears to be a STOP statement.

 test_AOD(FAILURE) : RTSolution results are different!
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
STOP 1

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