Conversation
Instead of just fesedflux and feventflux, updates to MARBL from UCI now add an fesedfluxred forcing field.
Added optional argument num_pass to MOM_initialize_tracer_from_Z(), which then gets passed down to horiz_interp_and_extrap_tracer() eventually is passed to fill_miss_2d() [where the optional argument is already part of the API but is never used]. I tested this updated by setting num_pass=0 for the MARBL tracers and verifying that the smoothing step was not run, but that was just a test to see if the smoothing was responsible for some unexpected tracer values in the MARBL initial conditions -- in general, we do want to smooth the MARBL tracers after they are initialized.
There was an issue where smoothing the MARBL tracer initial conditions led to some inconsistent tracer values for tracers associated with MARBL's autotrophs. For each autotroph, if any tracer (C, N, P, etc) is 0 we want all of that autotroph's tracers to be 0... but the smoothing algorithm in MOM_initialize_tracer_from_Z() would sometimes leave one tracer at 0 but introduce a nonzero value in a different tracer at the same location. The subroutine on the MARBL interface enforces this consistency. This function is called whenever any MARBL tracer is initialized with MOM_initialize_tracer_from_Z(); if all the tracers are read in from a restart file then this subroutine is skipped. If this function is called, it is noted in the log with the following message: Enforcing consistency across autotroph tracer initial conditions
Added autotroph_tracer_consistency_enforce() to the dummy MARBL interface so MARBL_tracers.F90 can still be built without MARBL
MARBL_tracers_stock() was writing a list of all tracers from all processors, filling up cesm.log unnecessarily
We decided to update the MARBL interface instead of playing with how MOM6 smooths the MARBL ICs, so we don't need to modify src/framework or src/initialization in this PR. Also changed some ".eq." to "==" in MARBL_tracers.F90
|
With ESCOMP/MOM_interface#231 and ESCOMP/FMS#7, this passes |
There was a problem hiding this comment.
Below is a minor suggestion. Aside from that, have you run the DIMCSL test? It tends to timeout because reading in JRA datastreams take so long. Unless you were able to run it successfully, I suggest running a DIMCSL test with CORE2 with and without MARBL.
| character(len=200) :: feventflux_file !< name of [netCDF] file containing iron vent flux | ||
| character(len=200) :: fesedflux_file !< name of [netCDF] file containing iron sediment flux | ||
| character(len=200) :: fesedfluxred_file !< name of [netCDF] file containing reduced iron sediment flux | ||
| character(len=200) :: feventflux_file !< name of [netCDF] file containing iron vent flux |
There was a problem hiding this comment.
Optional: While it's probably unlikely to hit the character limit of 200, I suggest using deferred-length character strings, which are more robust and memory-efficient.
|
@alperaltuntas -- I opened #410 to note that it would be nice to switch to deferred-length character strings, but I'd like to put that off until a future PR. I forgot to mention that the DIMCSL tests in |
|
DIMCSL tests ran over the weekend; the good news is that the Unfortunately, there are a few issues with the MARBL compset: @alperaltuntas and @klindsay28 -- I think it's important that we fix this before the CESM3 release, but I'm okay creating a new issue ticket about this test failure and tackling it in a future PR if that's okay with the two of you. Otherwise I'll fix it in this PR. |
|
I am currently running a DIMCSL test with MARBL out of the current |
|
Thanks @mnlevy1981. My experience is that CORE2 DIMCSL tests run much faster compared to JRA tests since datm doesn't have to slowly read through the relatively large JRA datastreams, but I understand if CORE2 testing is not meaningful in your case. |
|
@alperaltuntas I've verified that the DIMCSL test is failing for MARBL compsets in |
|
@mnlevy1981 Seems like there is at least one build failure in CI tests, but otherwise, LGTM. |
CI was complaining about dust_ratio**-0.9 ("Unary operator following arithmetic
operator (use parentheses)") so I took the message's advice and changed to
dust_ratio**(-0.9)
Fixed! Sorry about that, the first few times I looked through the failed test log I had trouble finding the actual cause of the failure (gfortran wants |
3 participants
marbl-ecosys/MARBL#464 updates MARBL's iron sediment forcing scheme, which will change what forcing fields MOM6 needs to provide to MARBL