You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
(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
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.
The text was updated successfully, but these errors were encountered:
There are a couple of problems with how we currently initialize component models:
Possible solutions to this are:
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:
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!
#1136b. 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
sim_mode
throughout the coupler driver. This will isolate any differences between different setups to the initialization stage. Removesim_mode
use in driver #1138CoupledSimulation
object specific to the AMIP and Slabplanet cases AddCoupledSimulation
constructors for AMIP and Slabplanet cases #1139In the future we would also like to include a notion of
Model
vsSimulation
for each component model, and use that in constructing theCoupledSimulation
, but this will require substantial changes from each component model so we won't work on it yet.The text was updated successfully, but these errors were encountered: