Add area integrated annual mean to data iceberg and ice-shelf flux files

[xylar]

This is needed for an Antarctic balance approach in which all Antarctic solid runoff is converted into iceberg and ice-shelf melt with the patterns from the Merino et al. (2020) and Paolo et al. (2023) datasets.

Checklist

• Developer's Guide has been updated
• API documentation in the Developer's Guide (api.rst) has any new or modified class, method and/or functions listed
• Documentation has been built locally and changes look as expected
• Document (in a comment titled Testing in this PR) any testing that was used to verify the changes

[xylar]

@cbegeman, this is part of the design https://acme-climate.atlassian.net/wiki/spaces/PSC/pages/4210098268/Design+Document+Data+iceberg+and+ice-shelf+melt+flux+patterns+for+E3SM+spin-up+runs. Do you want to take a quick look at this, particularly the run() method, to see if you notice any immediate problems?

In the meantime, i'll run this through the IcoswISC240 workflow to see what I get.

[xylar]

Testing

I ran the IcoswISC240 workflow through files_for_e3sm. I was able to produce the expected "normalized" files. I verified by eye in paraview that the fluxes times areaCell looked plausible (they are less than 1 and look like they could plausibly sum to something close to 1). More rigorous testing will, of course, be needed.

I also have the test print out the total fluxes before and after normalization:

total_dib_flux:     37077587.7
total_dismf_flux:   30060820.9
total_flux:         67138408.6

norm_total_dib_flux:     0.552
norm_total_dismf_flux:   0.448
norm_total_flux:         1.000

(Interesting to see that the calving flux is higher than the melt flux. I didn't remember that being the case in observations.)

[cbegeman]

@xylar I think this looks correct. I'm just wondering whether we will run into underflow issues on a grid-cell basis since I think we are dividing a flux with units kg m^-2 s^-1 by the total flux over 1 year and the whole domain. Have you looked at this? I could also be misunderstanding your approach.

[xylar]

I don't anticipate underflow issues but I also don't really know how we might avoid them. Do you have a suggestion?

[xylar]

@cbegeman, thinking about this a bit further, one solution that would likely avoid the underflow issue (if there is one) would be simply to precompute and store totalDataIcebergIceShelfFreshwaterFlux in both the DIB and DISMF files. Then, we could simply multiply each field by the ratio of totalRemovedIceRunoffFlux/totalDataIcebergIceShelfFreshwaterFlux in MPAS-Ocean and MPAS-Seaice. This has several advantages:

• it may avoid underflow
• we don't create extra, mostly redundant DIB and DISMF files (at least for future meshes)
• we don't need to fix the units for the normalized fields (and the names are not deceptive)

I will probably switch to that approach but want to see what you think first.

[cbegeman]

@cbegeman, thinking about this a bit further, one solution that would likely avoid the underflow issue (if there is one) would be simply to precompute and store totalDataIcebergIceShelfFreshwaterFlux in both the DIB and DISMF files. Then, we could simply multiply each field by the ratio of totalRemovedIceRunoffFlux/totalDataIcebergIceShelfFreshwaterFlux in MPAS-Ocean.

@xylar I like that solution.

[xylar]

Testing with the new approach

I reran files_for_e3sm with the new approach of just adding the totals to the datasets. With the modified formatting, I see:

total_dib_flux:     37077587.7
total_dismf_flux:   30060820.9
total_flux:         67138408.6

norm_total_dib_flux:     0.5522559813506136
norm_total_dismf_flux:   0.4477440186493862
norm_total_flux:         0.9999999999999998
1 - norm_total_flux:     2.220446049250313e-16

so things look good here, but we'll have to verify this in MPAS-Ocean and -Seaice.

I also verified that I see the new fields in the NetCDF output files:

...
	double areaIntegAnnMeanDataIcebergFreshwaterFlux(Time) ;
		areaIntegAnnMeanDataIcebergFreshwaterFlux:units = "kg s-1" ;
	double areaIntegAnnMeanDataIceShelfFreshwaterFlux(Time) ;
		areaIntegAnnMeanDataIceShelfFreshwaterFlux:units = "kg s-1" ;
	double areaIntegAnnMeanDataIcebergIceShelfFreshwaterFlux(Time) ;
		areaIntegAnnMeanDataIcebergIceShelfFreshwaterFlux:units = "kg s-1" ;
...

For the DIB file, we have to have 12 redundant copies along the Time axis because:

1. NetCDF output files don't seem to like having scalar values without any dimensions
2. The MPAS-Framework isn't set up to read scalar values either

[cbegeman]

@xylar I think this looks great. Thanks! Let me know if you want me to do any testing.

[xylar]

@cbegeman, I think this branch is probably in good shape and you don't need to test. Next steps would be to make new Icos DIB and DISMF files with this branch, and then to use those in testing the capability in E3SM. But that's a little way off still.

[xylar]

This appears to be working as expected in my E3SM branch in E3SM-Ocean-Discussion/E3SM#109. I am almost a year into a test with scaling enabled:

In blue is the original DISMF, in orange is the scaled version, in green is the original DIB and in red is the scaled version. These are area integrals of daily snapshots.

[xylar]

@cbegeman, I think it would be convenient if this were to get merged in to Compass. This way, any new meshes we create would be ready to go for E3SM-Project/E3SM#6696. Could you just give the code a once-over? You are also welcome to look at the files I created for Icos and SORRM meshes (you can see where the dates for the Paolo and Merino files are changed in E3SM-Project/E3SM#6696) but I don't think that level of sanity checking is necessary. I believe my testing has shown that they have the right values for Icos and the planned E3SM testing should show this for SORRM as well.

[cbegeman]

Do we want to use variables for the iceberg and ismf dataset names so it's a little easier to replace them as new datasets come along?

[xylar]

I'm fine with adding those. There's no huge rush on this PR.

[xylar]

On second thought, I think generalizing Compass so it can handle new iceberg and ISMF datasets based on config options seems like a fairly significant challenge that's beyond the scope of this PR. I think it would make sense to take that on as soon as we have such a new dataset.

[cbegeman]

I read through the code but did not look at the files. I think this all looks good. I made one minor suggestion which you can ignore if you like to keep this work moving forward.

[xylar]

@cbegeman, thanks for the review! I considered your suggestion but I think it's too big a project to take on here. I'm happy to take it on the next time we want to update the DIB or DISMF dataset.