Use common color map setup for all plots with color maps

[xylar]

All these tasks now support a choice of either contours (via indexed color maps) or continuous plotting (via a "norm"). Tick marks can be specified (optionally) differently from contour levels.

Contour lines can also be plotted on top of any plot by specifying contour values, a color for contours and a line width.

These changes generalize and consolidate some redundant code related creating color maps.

The changes also enable a new SSH plot, similar to Maximenko et al. (2009):

[xylar]

Here is an example of an SSH plot from this branch:

I'm happy with this but it would also be easy to go back to the Spectral_r color map by default and still keep these contours.

[mark-petersen]

Wow! That is really beautiful! I love the bright colors with the contours.

I wonder if the AVISO data does not have a zero mean for SSH. Zero is arbitrary, of course. MPAS-O begins with an actual mean SSH of zero, but can drift with P&E. By visual integration, AVISO looks positive, so the diff is confusing. That is really a topic for a different issue.

[xylar]

@mark-petersen, that's a good point. My guess is that it's the offset from a reference surface of some kind but @maltrud and @milenaveneziani would have a better idea.

It would be somewhat risky to adjust AVISO to have zero mean, given that it has a lot of missing values in polar regions where the SSH has its most negative values in MPAS-O. I'm definitely open to suggestions.

[xylar]

I suppose one option would be to just shift AVISO (or MPAS-O) SSH by a constant value so the mean model-data mismatch is zero (on the assumption that the mean offset between the 2 is not meaningful).

[xylar]

I believe my title for the observation are incorrect and that this is the AVISO absolute dynamic topography above the geoid. @milenaveneziani, can you confirm, since I think you downloaded the data?

That doesn't really answer the question of what we should do about the systematic offset between the model and the observations.

[xylar]

Here is the analysis for an example run with ice-shelf cavities:
http://portal.nersc.gov/project/m2833/mpas_analysis_output/20180209.GMPAS-IAF.T62_oEC60to30v3wLI.cori-knl.afterSalinityFix_general_colormap/

Everything except SSH should look the same and indeed I think it does, though I didn't do a careful comparison of each and every figure.

[vanroekel]

@xylar code looks good. I'm testing now. In my high res test I see this error

Traceback (most recent call last):
  File "./run_mpas_analysis", line 238, in add_task_and_subtasks
    analysisTask.setup_and_check()
  File "/blues/gpfs/home/lvanroe/MPAS-Analysis/mpas_analysis/ocean/climatology_map_antarctic_melt.py", line 163, in setup_and_check
    raise ValueError('*** climatologyMapMeltAntarctic requires '
ValueError: *** climatologyMapMeltAntarctic requires config_land_ice_flux_mode
    to be standalone or coupled.  Otherwise, no melt rates are available
    for plotting.
ERROR: analysis task climatologyMapAntarcticMelt failed during check and will not be run
Traceback (most recent call last):
  File "./run_mpas_analysis", line 238, in add_task_and_subtasks
    analysisTask.setup_and_check()
  File "/blues/gpfs/home/lvanroe/MPAS-Analysis/mpas_analysis/ocean/time_series_antarctic_melt.py", line 104, in setup_and_check
    raise ValueError('*** timeSeriesAntarcticMelt requires '
ValueError: *** timeSeriesAntarcticMelt requires config_land_ice_flux_mode
    to be standalone or coupled.  Otherwise, no melt rates are available
    for plotting.
ERROR: analysis task timeSeriesAntarcticMelt failed during check and will not be run

I assume this is okay as I don't have a land ice in this run. But it might be nice to not have a valueError if config_land_ice_flux_mode is not enabled. Or would it make more sense to have the default set of analysis run not include land ice melt time series and maps?

[xylar]

It’s better if you disable this analysis by using no_landIceCavities as part of the generate option in your config file. That’s the case for a bunch of our example config files.

[vanroekel]

Ah, of course. I realize I was running this test from the command line without that option. It's already in my config files. Sorry for that mix-up

I successfully tested on 18to6 and even tinkered with the options for other fields like MLD. It works great! Thanks @xylar

[milenaveneziani]

I agree, the SSH plots are beautiful.
For removing a ref level: we could remove the global mean from both products. MPAS's mean is probably very close to 0, since the negative numbers are concentrated at the poles, while we'll shift the Obs overall values towards 0 by removing the (almost definitely) positive mean.

let me double check the observations website, but I think you are right: it is absolute dynamic height.

[milenaveneziani]

Actually, the observations are mean sea-level anomalies (msla), computed with respect to the 20-year mean for which the data was taken. So maybe I would just change the title to 'AVISO mean sea-level anomaly)'.

[xylar]

@milenaveneziani, are you sure the zos field is an anomaly field? My web search suggested it was an absolute deviation from the geoid and that makes more sense to me. I think we are looking at precisely the field (the 1993-2010 climatology) that is used as the baseline for the anomalies. That is, the climatology of the anomalies should be zero by definition.

[xylar]

@milenaveneziani, I like your suggestion of removing the mean from both. Would we do that before or after regridding? Would we do that for all cells or only cells not masked out by either MPAS-O or AVISO? It probably doesn't matter a whole lot but could matter some.

[maltrud]

@xylar and @milenaveneziani you should remove the mean from the model, too. we only care about the mean when we're doing sea level rise.

a question: what field is being plotted? is it the pressure adjusted SSH? that's what we want, not the actual SSH.

[xylar]

@milenaveneziani, the link I can find for the particular file I used is here:
https://podaac.jpl.nasa.gov/ws/metadata/granule?granuleName=zos_AVISO_L4_199210-201012.nc&datasetId=PODAAC-DYNTO-1D1M1&format=iso

If you search for "dynamic topography", you see:

AVISO Level 4 Absolute Dynamic Topography for Climate Model Comparison

So I think the title should be AVISO Zero-mean Absolute Dynamic Topography (1993-2010) (once we have removed the mean).

[xylar]

@maltrud, it's the SSH, not the pressure-adjusted SSH. I agree we want the latter, and that probably explains why we're so deep in the polar regions. I'll fix that.

[xylar]

@vanroekel, thanks very much for the testing. I think you tested feature combinations I hadn't tried yet so I'm both pleased and a little surprised that things worked!

[xylar]

Here's the result of removing the mean independently for MPAS-O and AVISO:

This is now with the pressure-adjusted SSH.

The fact that there's still a systematic offset between the two might suggest that we need to try removing the mean over the region where both data sets are valid. I'll do this in a new commit and see if it works. (We can always remove the commit if we decide it doesn't improve the result.)

[xylar]

That seems to have done the trick:

[xylar]

Okay, @maltrud, @mark-petersen and @milenaveneziani, let me know if you're happy with the result now.

[mark-petersen]

Yes, that looks really great, thanks!

[milenaveneziani]

Great @xylar.

So I think the title should be AVISO Zero-mean Absolute Dynamic Topography (1993-2010)

yeah, I think you are right, I need to correct my notes.

[maltrud]

@xylar it looks good. still SSH, not pressure adjusted, though, right?

[xylar]

@maltrud, yes this is now with pressure-adjusted SSH.

[xylar]

I'm going to go ahead an merge this. @maltrud, i assume since this is using the pressure-adjusted SSH now, you're happy with it...