Skip to content

Conversation

@jshaw35
Copy link
Contributor

@jshaw35 jshaw35 commented Sep 3, 2025

This PR contains significant additions to COSP that enable two new functionalities:

  • Coupling with the RTTOV radiative transfer model has been reestablished and expanded. COSP users may specify an arbitrary number of instruments supported by RTTOV and produce clear-sky and all-sky radiance and brightness temperature fields consistent with these instruments' spectral response function. For each instrument, any subset of spectral channels may be simulated.
  • New swathing routines allow users to specify a simplified satellite-like sampling routine. Sampling routines are parametrized by a list of equator crossing times (in local time) and swath widths (in km). These parameters define an evolving mask the describes which model grid cells are sampled by the instrument. Only these grid cells are passed into the individual instrument simulators while remaining grid cells are masked to avoid incorrect temporal averaging. These masking routines produce realistic sampling patterns that favor high-latitudes and allow for the isolation of day- or nighttime orbits without saving high-frequency model output. Computational cost is also reduced due to fewer simulator calls. This functionality can be specified separately for ISCCP, MISR, MODIS, PARASOL, ATLID, and CloudSat+CALIPSO outputs as well as for each RTTOV instrument.

For an exhaustive description of implementation, validation, and science applications, see our GMD paper (https://gmd.copernicus.org/articles/18/4935/2025/). @dustinswales has been an invaluable contributor to all aspects of this work.

Remaining items:

  • CI checks should be expanded to validate the swathing routine.
  • CI checks for RTTOV would be great, but would require an RTTOV installation.
  • Two variables: modis_optical_thickness_vs_ReffLIQ and modis_optical_thickness_vs_ReffICE are saved at all timesteps. These variables should probably be limited to sunlit timesteps only. Minor changes to address this issue can be found here, but require a further update to the KGOs: (dustinswales@a8e61ad)

jshaw35 and others added 30 commits January 30, 2023 10:01
Merge updates into working version (2023/01/30)
Merging with the main branch. Should not do again.
The RTTOV v13 code files are copies of cosp_rttov_interface.F90 and cosp_rttov11.F90

No changes made yet.
… added conditional dependencies in cosp2_test.F90 and cosp.F90
…efile has changed

cosp_rttov_interface_v13.F90 will not be compiled unless RTTOV is being built into COSP, so I no longer need #ifdef RTTOV statements in this file.
…it passes the RTTOV instrument, channel, etc information into the cosp_rttov_init call.
Shifted DDT in both the STUB and main files.
dustinswales and others added 19 commits July 2, 2025 11:34
…al, remove emis_in and refl_in, appropriately allocate so2 field even if it isn't used, and only run rttov_cleanup when needed.
…tputs that were being assigned R_UNDEF values inconsistently.
@RobertPincus
Copy link
Contributor

@jshaw35 You're a rock star thanks a lot. A few questions for the assembled multitudes:

  • Do we want to ask for the RTTOV and swathing bits to be submitted as separate PRs? This PR touches a LOT of files
  • Are we comfortable adding changes that aren't covered by the continuous integration? That's not ideal practice... maybe @jshaw35 could use help figuring out how to install RTTOV as part of the CI?

@klein21
Copy link

klein21 commented Sep 4, 2025

Jonah, This is truly great work! Much thanks for all of your efforts!

@jshaw35
Copy link
Contributor Author

jshaw35 commented Sep 4, 2025

@jshaw35 You're a rock star thanks a lot. A few questions for the assembled multitudes:

* Do we want to ask for the RTTOV and swathing bits to be submitted as separate PRs? This PR touches a LOT of files

* Are we comfortable adding changes that aren't covered by the continuous integration? That's not ideal practice... maybe @jshaw35 could use help figuring out how to install RTTOV as part of the CI?

Great points @RobertPincus.

re: separate PRs. @dustinswales had also raised this but the swathing and COSP-RTTOV changes are difficult to separate at this point. We decided to submit this as a single PR. I'd rather not separate the changes but also want to make this easy to review. Perhaps there is a middle ground.

re: CI for RTTOV, I think this is a great idea and could try to support it. I have experience building RTTOV on HPC platforms but not much familiarity with the CI workflow. Dustin, what do you think?

@dustinswales
Copy link
Contributor

@jshaw35 Thanks for adding the swath test to the CI scripts. I just updated the CI script to include the swathed case in the artifact.
As for RTTOV in the CI, to get started we need to have the RTTOV codebase (tarball) staged somewhere so we can grab it. @alejandrobodas Maybe we could add this to the Google Drive folder where you currently keep the KGOs? Or @jshaw35 maybe you have access to a FTP site or something similar? (You might have other files to store for RTTOV config?)
Once that is in place, I could update the CI script to download/build/install RTTOV. Then @jshaw35 could add a new RTTOV enabled COSP test.
Thoughts?

@mo-abodas
Copy link

@jshaw35 @dustinswales thank a lot for this, it's great!
I agree that it would be good to have a CI test that covers this new simulator.
@dustinswales I'm hesitant to get RTTOV from the GDrive folder unless we are completely sure that that doesn't break the terms of the license.

@jshaw35
Copy link
Contributor Author

jshaw35 commented Sep 30, 2025

@alejandrobodas thanks for these comments!
re: CI for swathing, I think adding this to CI can be accomplished now by adding kgos for the new swathed test.

re: RTTOV, I totally agree that we should follow the license terms. Is there a location we can host the source code that can be accessed by the CI only?

@mo-abodas
Copy link

mo-abodas commented Oct 3, 2025

re: RTTOV, I totally agree that we should follow the license terms. Is there a location we can host the source code that can be accessed by the CI only?

I suppose we could use a Github 'secret' to download code from a password-protected location, but I've never used secrets so I don't know how it's done.

@mo-abodas
Copy link

All, I'm not sure if we're going to make too much progress on solving the problem of running CI tests with an RTTOV installation. What do people think about progress with this PR with a stub interface and investigate the RTTOV installation in a separate discussion?

@jshaw35
Copy link
Contributor Author

jshaw35 commented Oct 20, 2025

All, I'm not sure if we're going to make too much progress on solving the problem of running CI tests with an RTTOV installation. What do people think about progress with this PR with a stub interface and investigate the RTTOV installation in a separate discussion?

@alejandrobodas / @mo-abodas, a few comments/updates regarding this question.

I had been working with @dustinswales to create set up an RTTOV test in the CI, but that work is currently tabled and will likely be further delayed. Furthermore, in December we should hear if the RTTOV license is granted an exception and made open source, which would help ease the creation of the CI/CD workflow. I think that RTTOV functionality should be brought into the CI and plan to support that work, but am also eager to see this PR added to COSP2 (for disclosure, COSP-RTTOV cannot be added to CESM without being a part of the official CFMIP COSP repository).

The current COSP-RTTOV code maintains the stub functionality as in previous COSP versions. CI tests are currently failing because we have added an additional test of the swathing functionality but the kgos with masked outputs are not updated yet. If a new kgo is created for the swathed output then the swathing functionality will be brought into CI and RTTOV will remain an optional stub.

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.

5 participants