additional testing of centered vs. upwided surface gradient calculations in Glissade dycore

_From @stephenprice on March 23, 2015 21:12_

When using incremental remapping (or FO upwinding) for thickness evolution of idealized test cases (e.g. Halfar) checkerboard surface elevation patterns have been observed to develop when using a centered sfc elevation gradient calculation scheme. An "upwinding" sfc elev. gradient scheme was introduced and shown to alleviate the problem.

However, for realistic test cases (e.g. 4 km Greenland), exactly the opposite behavior has been observed; the centered gradient scheme results in smooth sfc elev (and velocity) fields and the upwinded gradient scheme introduces what appears to be a checkerboard mode after only a few years of fwd integration (see example figs below).

This behavior has been observed in multiple branches of the code (including devel), when using different dynamical cores, and when using either IR or FO upwinding for advection. A suggestion for further testing from W. Lipscomb is as follows:

"One test worth trying would be to set accuracy_flag_in = 1 in glissade_velo_higher.F90 in the call to the gradient routines. This would generate a 1st-order rather than 2nd -order accurate one-sided gradient, which might be less prone to checkerboard noise (or at any rate, the differences between 1st order and 2nd order might tell us something)."

---

Image WITH checkerboarding in sfc speed field after ~20 years of integration (when using the upwinded elevation gradient scheme).

Image with NO checkerboarding in sfc speed field after ~20 years of integration (when using the centered elevation gradient scheme).

_Copied from original issue: E3SM-Project/cism-piscees#25_