Basin mask for basin specific heat and salt flux diagnostics

[blimlim]

The ESM1.5 configurations currently save several 1D heat and salt flux variables over different ocean basins:

        float temp_merid_flux_advect_global(time, yu_ocean) ;
    float temp_merid_flux_over_global(time, yu_ocean) ;
    float temp_merid_flux_gyre_global(time, yu_ocean) ;
    float salt_merid_flux_advect_global(time, yu_ocean) ;
    float salt_merid_flux_over_global(time, yu_ocean) ;
    float salt_merid_flux_gyre_global(time, yu_ocean) ;
    float temp_merid_flux_advect_southern(time, yu_ocean) ;
    float temp_merid_flux_over_southern(time, yu_ocean) ;
    float temp_merid_flux_gyre_southern(time, yu_ocean) ;
    float salt_merid_flux_advect_southern(time, yu_ocean) ;
    float salt_merid_flux_over_southern(time, yu_ocean) ;
    float salt_merid_flux_gyre_southern(time, yu_ocean) ;
    float temp_merid_flux_advect_atlantic(time, yu_ocean) ;
    float temp_merid_flux_over_atlantic(time, yu_ocean) ;
    float temp_merid_flux_gyre_atlantic(time, yu_ocean) ;
    float salt_merid_flux_advect_atlantic(time, yu_ocean) ;
    float salt_merid_flux_over_atlantic(time, yu_ocean) ;
    float salt_merid_flux_gyre_atlantic(time, yu_ocean) ;
    float temp_merid_flux_advect_pacific(time, yu_ocean) ;
    float temp_merid_flux_over_pacific(time, yu_ocean) ;
    float temp_merid_flux_gyre_pacific(time, yu_ocean) ;
    float salt_merid_flux_advect_pacific(time, yu_ocean) ;
    float salt_merid_flux_over_pacific(time, yu_ocean) ;
    float salt_merid_flux_gyre_pacific(time, yu_ocean) ;
    float temp_merid_flux_advect_arctic(time, yu_ocean) ;
    float temp_merid_flux_over_arctic(time, yu_ocean) ;
    float temp_merid_flux_gyre_arctic(time, yu_ocean) ;
    float salt_merid_flux_advect_arctic(time, yu_ocean) ;
    float salt_merid_flux_over_arctic(time, yu_ocean) ;
    float salt_merid_flux_gyre_arctic(time, yu_ocean) ;
    float temp_merid_flux_advect_indian(time, yu_ocean) ;
    float temp_merid_flux_over_indian(time, yu_ocean) ;
    float temp_merid_flux_gyre_indian(time, yu_ocean) ;
    float salt_merid_flux_advect_indian(time, yu_ocean) ;
    float salt_merid_flux_over_indian(time, yu_ocean) ;
    float salt_merid_flux_gyre_indian(time, yu_ocean) ;

However the output for each basin is identical to the global output, as brought up here:

The ocean namelist for the ESM1.5 configs don't include a read_basin_mask flag, which defaults to .false., and they also don't link the basin mask file currently at /g/data/vk83/configurations/inputs/access-esm1p5/modern/unused/ocean/uncategorised/global.1deg/2020.05.19/basin_mask.nc in the config.yaml files, and it looks like MOM reverts to computing global integrals when this file isn't supplied.

Adding the namelist flag and path to the file give different output for the different basins:

For reference, the basin mask file looks like: And it also lines up with the land mask used in ESM1.5.

Unfortunately, including the basin mask seems to break bit reproducibility. The following shows the difference in monthly mean surface temperature for the first month of simulation for a PI run with and without the basin mask file added in:

I'll rerun some tests to double check that it is the basin mask causing the differences.

[blimlim]

Confirming that including the basin mask influences the simulation. The following shows hourly global average sea surface temp for the first month of simulation with and without the basin mask added:

[aidanheerdegen]

Nice work. I wonder if it breaks bit reproducibility because the ocean mask (cells containing ocean) aren't consistent with the ocean mask in basin_mask.nc?

I looked at the code, and the mask is used in advection, so if the mask changed that might affect the tracer fields.

[blimlim]

I wonder if it breaks bit reproducibility because the ocean mask (cells containing ocean) aren't consistent with the ocean mask in basin_mask.nc?

Good question. I've compared it against what I think is the land mask (the variable wet in /g/data/vk83/configurations/inputs/access-esm1p5/modern/share/ocean/grids/mosaic/global.1deg/2020.05.19/grid_spec.nc), and the land points appear to match up between the two:

Land mask: Basin mask:

Difference between the two after matching dimension names, and setting nan points to 0, non-nan points to 1:

I looked at the code, and the mask is used in advection

Is this in ocean_tracer_advect.F90? I'm wondering whether these subroutines should be affecting the actual running of the model, or just the calculations for those tracer diagnostics?

I also saw that it was read in by ocean_thickness.F90 but because we have read_rescale_rho0_mask=.false. in the ocean namelist, I don't think this one would be used.

[blimlim]

Results from a few more (possibly ill informed) tests:

1 Read the basin mask but do not request any of the (temp/salt)_merid_flux... variables in the diag_table

Matches the previous case where the basin mask is read:

2 Modify basin mask to be southern ocean everywhere:

Replace all values over the ocean with 1.0, which specifies the southern ocean. This again results in the same output as the original basin mask

3 Add extra land to the basin mask:

Add a big chunk of land to the pacific: This again results in the same output as the original basin mask:

[access-hive-bot]

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/access-esm1-5-basin-ocean-heat-transports-incorrect/3674/6

[aidanheerdegen]

Is this in ocean_tracer_advect.F90? I'm wondering whether these subroutines should be affecting the actual running of the model, or just the calculations for those tracer diagnostics?

I also saw that it was read in by ocean_thickness.F90 but because we have read_rescale_rho0_mask=.false. in the ocean namelist, I don't think this one would be used.

You're right. I don't think there should be any way that this is used to do anything other than diagnose those transports, and yet they do make a difference, right?

I guess you've tried not reading in the basin_mask and confirmed you get the same (original) output?

If this hits the too-hard basket would it be straightforward to use the regionmask package to achieve the same effect?

https://cmip6-preprocessing.readthedocs.io/en/latest/regionmask.html

[blimlim]

I guess you've tried not reading in the basin_mask and confirmed you get the same (original) output?

Good question! I hadn't originally rerun it, but it's definitely worth double checking this. I tried cloning my original basin mask run's control directory, and then in the cloned control directory I deleted the ocean_tracer_advect_nml section from the namelist.

 &ocean_tracer_advect_nml
    read_basin_mask   = .true.
/

I left in the path to the basin_mask.nc in the config.yaml however, meaning it would still be copied to the work directory.

This reproduced the original run which didn't include the basin mask.

And so it looks like reading the basin mask is confusingly affecting the run

[blimlim]

Ok it looks like I wasn't being completely competent when editing the namelist settings. I suspect including the basin properly should work fine without affecting reproducibility. Currently testing it and will update with the details.

[blimlim]

When I couldn't find the read_basin_mask setting in the ocean's input.nml, I'd wrongly assumed that the relevant namelist group ocean_tracer_advect_nml was not present, and that the defaults were being used for all its settings. I then added a new copy of the group to the file in order to add the read_basin_mask setting.

This wasn't correct though, and this namelist group was further down in the file:

 &ocean_tracer_advect_nml
      debug_this_module=.false.
      advect_sweby_all=.true.
/

When I added the extra copy of the group, it probably overwrote these settings, breaking the reproducibility.

Moving the read_basin_mask=.true. setting into the already existing group then reproduces the original run

basins:

and also gives the different fluxes over the different basins: