Apologies as this might not be the proper place for this post, but I realized that while the ocean outputs of the ACCESS-ESM1.5 supposedly include diagnostics for ocean heat transport across all the basins, they are in fact the same: i.e. TEMP_MERID_FLUX_OVER_“GLOBAL” is also the one named “Atlantic”, “Pacific”, “Indian”… so the global field is written instead of each basin separately. This is the same issue for the TEMP_MERID_FLUX_ADVECT_GLOBAL, TEMP_MERID_FLUX_GYRE_GLOBAL … I have not checked the Salt fluxes, but it is probably the same. This is coming from several experiments of the “unreleased ACCESS-ESM”, so it would be great to check if this has been fixed in the released version, as this diagnostics are quite useful (and if they are written anyways, they might as well be correct).
Thanks,
Laurie
Thanks for the report @LaurieM. I’ve moved this to a new topic so we can triage and deal with it.
Hi @LaurieM, thanks for bringing this up!
The new release of ESM1.5 appears to have the same problem, with the same data being written to the temp_merid_flux_... variables for the different basins:
It looks like MOM5 uses a namelist switch read_basin_mask to determine whether to read an external netCDF file defining each basin’s extent. Both the older and newer versions of ESM1.5 omit this switch from the namelist, causing it to default to false. It looks like in this case, MOM5 uses the same global domain for all the calculations.
I tested adding read_basin_mask = .true. back into the namelist, and linking to the basin_mask.nc that’s available in the ESM1.5 inputs directory that wasn’t being used. This gives different results for the different basins:
I’ll confirm with the ocean team whether the file and results using it look correct, e.g. if it lines up with the land mask, and if everything is ok we’ll include it in version 1.2 of the ESM1.5 configurations.
Thanks Spencer! It looks better!