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

GDASApp EE2 compliance checklist for GFS v17 & v18 #1254

Open
2 of 10 tasks
RussTreadon-NOAA opened this issue Aug 15, 2024 · 7 comments
Open
2 of 10 tasks

GDASApp EE2 compliance checklist for GFS v17 & v18 #1254

RussTreadon-NOAA opened this issue Aug 15, 2024 · 7 comments

Comments

@RussTreadon-NOAA
Copy link
Contributor

RussTreadon-NOAA commented Aug 15, 2024

This issue is opened as a one-stop-shop to list GDASApp related EE2 compliance issues

  • Build issues; Do not build libraries e.g. CRTM, FMS, FV3, MOM6, Icepak, etc.
    • Use the ufs-weather-model library in GDASApp in place of FV3, MOM6, Icepak (Dom H. was working on this in JEDI)
    • Use CRTM and CRTM-fix module instead of building and downloading fix files - GDASApp issue #1268.
    • Don’t download test data as part of build process - GDASApp issue #1269
    • Use FMS module - GDASApp PR #1221
  • Install executables into $HOMEgfs/exec - GDASApp issue #1302
  • Build warnings and build and run in debug mode
  • Relocate job scripts to global-workflow
    • partially addressed by g-w PR #2920
  • Copy any other needed files to global-workflow as part of link_workflow.sh (no job script should look in the gdas.cd directory)

Separate issues and PRs will be opened to address the above tasks.

@RussTreadon-NOAA
Copy link
Contributor Author

GDASApp PR #1221 resolved the FMS task.

@RussTreadon-NOAA
Copy link
Contributor Author

CRTMv3 should address task Use CRTM and CRTM-fix module instead of building and downloading fix files.

@RussTreadon-NOAA
Copy link
Contributor Author

GDASApp issue #1268 has been created to track the move from using a GDASapp built CRTM to using a pre-installed CRTM build via a module load.

@RussTreadon-NOAA
Copy link
Contributor Author

GDASApp issue #1269 has been created to track the addition of flags to optionally turn off the downloading of test data during the GDASApp build.

@CoryMartin-NOAA
Copy link
Contributor

I see in this PR: JCSDA-internal/ioda-converters#1548

  set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
  set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_RPATH}:${CMAKE_BINARY_DIR}/lib64")

I wonder if we can add this to our gdas.x compile and solve the copy vs link executable issue?

@RussTreadon-NOAA
Copy link
Contributor Author

Thanks @CoryMartin-NOAA for spotting JCSDA-internal/ioda-converters#1548. Trying this in GDASApp is a good idea. Worse case is that it doesn't solve the copy -vs- link executable issue. Best case is that it does and we can check this item off the GDASApp EE2 compliance list.

@RussTreadon-NOAA
Copy link
Contributor Author

GDASApp PR #1282 along with g-w PR #2920 partially address checklist item Relocate job scripts to global-workflow. Work for these PRs is complete.

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

No branches or pull requests

2 participants