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

Put information for initializing tracers into marbl_tracer_type #449

Open
mnlevy1981 opened this issue Dec 27, 2023 · 1 comment
Open

Put information for initializing tracers into marbl_tracer_type #449

mnlevy1981 opened this issue Dec 27, 2023 · 1 comment

Comments

@mnlevy1981
Copy link
Collaborator

POP has an io_read_fallback_mod module that can be used to tell the model "if [tracer name] isn't available in the initial condition file, initialize it some other way"; that other way could be "read a different tracer," "read a different tracer but scale it by some factor", or "set it to a constant." (The implementation for the MARBL tracers is here.)

Given the general design principal that the GCM should have as little semantic knowledge of MARBL as possible, it makes sense for MARBL to provide the GCM information on what to do if the tracer is not available in the IC file. I think it would make the most sense to extend tracer_metadata_type:

  type, public :: marbl_tracer_metadata_type
     character(len=char_len) :: short_name
     character(len=char_len) :: long_name
     character(len=char_len) :: units
     character(len=char_len) :: tend_units
     character(len=char_len) :: flux_units
     logical                 :: lfull_depth_tavg
     character(len=char_len) :: tracer_module_name
+    character(len=char_len) :: fallback_option
+    character(len=char_len) :: fallback_tracer
+    real(r8)                :: fallback_const
+    real(r8)                :: fallback_scalef
  end type marbl_tracer_metadata_type

Where fallback_option could be 'none', 'alt_tracer', or 'const' and the other new variables are pretty self-explanatory. POP could continue to use io_read_fallback, but instead of explicitly defining the fallbacks in the linked code snippet, it would just loop through the tracer metadata and register any tracer where fallback_option is not 'none'.

@mnlevy1981
Copy link
Collaborator Author

One tricky bit is providing fallback information for the PFTs. I think it makes sense to add these fallback variables to autotroph_settings_type and zooplankton_settings_type and use them in init_autotroph_tracer_metadata() and init_zooplankton_tracer_metadata(), but there's an edge case with the cocco tracers... we want all the cocco tracers fallback to be 0.07x the sp tracers, except coccoCaCO3 = spCaCO3 since all the calcification comes from coccolithophores in the 4pNz configurations. For testing purposes I can hard-code an exception for CaCO3 but I want a better solution than that before merging a PR to development

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

1 participant