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

clean up component model initialization #1011

Open
Tracked by #1050
juliasloan25 opened this issue Oct 10, 2024 · 0 comments
Open
Tracked by #1050

clean up component model initialization #1011

juliasloan25 opened this issue Oct 10, 2024 · 0 comments
Assignees

Comments

@juliasloan25
Copy link
Member

juliasloan25 commented Oct 10, 2024

There are a couple of problems with how we currently initialize component models:

  • We initialize a land model even if it isn't used (masked out later) in the slabplanet_aqua case, and initialize ocean even if it isn't used in the slabplanet_terra case - see Don't require all 4 component models #1069
  • There is a lot of redundancy in setting up component models for each of the different mode types we use our driver for (amip, slabplanet, etc)

Possible solutions to this are:

  • Smaller if/else chunks where we check the mode names and come up with flags to pass to generic component model constructors that dispatch off of them. E.g. we could have land_init(:bucket), land_init(nothing) that return different land model types
  • Separate the driver into one for AMIP and one for slabplanet
    • would still need to handle the aqua/terra cases specially
    • would cause some code duplication between drivers
  • Change the UI so the user provides the types of component models they want to use. We could then use these to directly construct the models
    • Would we still allow the user to specify AMIP/slabplanet setup, or now require them to specify all component models?

Update 1/14/25

Today I met with @Sbozzolo and @imreddyTeja, and we came up with a plan for this. It has 3 main parts, all working toward removing the idea of a mode type and simplifying the CoupledSimulation construction:

  1. Remove mode-specific prescribed data updates from driver
    a. Introduce component models that read in data directly from files. This will allow us to remove the mode-type-dependent SST and SIC updates in the coupling loop. Update surface models with prescribed data from file in step! #1136
    b. Move prescribed CO2 to ClimaAtmos, will allow us to remove the mode-dependent CO2 update in the coupling loop. Remove CO2 update from driver #1137
  2. (after 1) Remove the use of sim_mode throughout the coupler driver. This will isolate any differences between different setups to the initialization stage. Remove sim_mode use in driver #1138
  3. Add constructors for CoupledSimulation object specific to the AMIP and Slabplanet cases Add CoupledSimulation constructors for AMIP and Slabplanet cases #1139

In the future we would also like to include a notion of Model vs Simulation for each component model, and use that in constructing the CoupledSimulation, but this will require substantial changes from each component model so we won't work on it yet.

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

3 participants