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.

Sign up for GitHub

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

Jump to bottom

Metadata should contain dependency information for CCPP scheme #308

Closed
climbfuji opened this issue Jun 30, 2020 · 6 comments · Fixed by #317
Closed

Metadata should contain dependency information for CCPP scheme #308

climbfuji opened this issue Jun 30, 2020 · 6 comments · Fixed by #317
Labels
capgen bugs, requests, etc. that involve ccpp_capgen ccpp_prebuild bugs, requests, etc. that involve ccpp_prebuild

Comments

@climbfuji
Copy link
Collaborator

CCPP schemes can have their own (private) dependencies, for example a microphysics scheme may contain modules that perform certain computations for cloud effective radii etc.

The CCPP code generator only knows about which schemes to compile (by parsing the suite definition files it is given), but not which dependencies it needs to compile for the schemes.

If we had an attribute like

dependencies=file_name_1.F90,file_name_2.f,file_name_3.inc

associated with the scheme metadata, the CCPP could create such a list of files to compile and hand it back to the host model. I am unclear how to fit this into the metadata, though, because the dependencies are independent of the _run etc routines - do we have a section that applies to the scheme as a whole, and not an individual CCPP entry point?
@climbfuji climbfuji added capgen bugs, requests, etc. that involve ccpp_capgen ccpp_prebuild bugs, requests, etc. that involve ccpp_prebuild labels Jun 30, 2020
@climbfuji
Copy link
Collaborator Author

My question is how the exactly that line dependencies=... would look like. Paths relative to this file? Just file names? Or just module names and impose that modules need to be unique? And above the ccpp_arg_table entry for a specific _run, _init, _finalize routine?

@climbfuji
Copy link
Collaborator Author

@gold2718 since we are having difficulties to hold our regular meetings, can we proceed with the discussion here? I would like to have a way forward to alleviate some of the concerns brought up by EMC and make compiling faster. Thanks ...

@gold2718
Copy link
Collaborator

Some thoughts and questions:

  • Currently, the capgen database communicates a module list to the host model build system. This module list currently is all the module names referenced in scheme metadata. We could have the dependencies list be module names (which cannot really be duplicated for a successful build). I am okay with that.
  • On the other hand, perhaps the build system really wants the filenames for all the schemes in use. In that case, the dependencies should be filenames. For instance, you can retrieve all the generated filenames (host capfiles, suite capfiles, ccpp_kinds) from the database. I am okay with the dependencies being filenames.
  • Which do the current build systems (e.g., FV3, SCM) use?
  • @davegill, how about MPAS?
  • @areinecke, if NEPTUNE were going to try to run imported CCPP suites, what would your build system want to know to be able to build the model with all the required files for the suite?
  • For the record, the CESM-CAM system does not need this information and would not use either version.
  • As for which header the dependencies keyword would go in, I do not think it matters. Filenames (or module names) would just be added to a set which will be put into the database for build-time retrieval.

@climbfuji
Copy link
Collaborator Author

Some additional information can be found in the meeting minutes here: https://github.com/NCAR/ccpp-framework/wiki/CCPP-Framework-Meeting-Minutes-2020-07-16

This was referenced Aug 4, 2020
Merged
Merged
Merged
Merged
Closed
@climbfuji
Copy link
Collaborator Author

Update: this dependency-specific implementation has been superseded by a more generic implementation of a ccpp-table-properties section for module, ddt and scheme tables. See #318

@climbfuji climbfuji mentioned this issue Aug 7, 2020
Merged
DusanJovic-NOAA pushed a commit to NOAA-EMC/fv3atm that referenced this issue Sep 2, 2020
@climbfuji
Add dependencies to CCPP metadata (#153)
223f092 
This PR removes dependency information from the CCPP prebuild config. See NCAR/ccpp-framework#308 and NCAR/ccpp-framework#317 for details on the motivation for this change and the actual implementation. It also removes some legacy code used by the dynamic CCPP build in the past.

This PR also contains the changes in #156, i.e. the completion of adding the active attribute to GFS_typedefs.F90. On top of this PR, the missing active attribute for phy_fctd is added.

Additionally, gfortran-10 compiler flags are added to CCPP's CMakeLists.txt.
@climbfuji
Copy link
Collaborator Author

Fixed and merged for ccpp-prebuild.py in #317.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
capgen bugs, requests, etc. that involve ccpp_capgen ccpp_prebuild bugs, requests, etc. that involve ccpp_prebuild
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add dependencies to metadata climbfuji/ccpp-framework
2 participants
@gold2718 @climbfuji