billsacks
commented
6 years ago From @DanFMartin on March 23, 2015 21:27
For the idealized dome test case mentioned here, do you need to use upwinded/one-sided gradients everywhere, or just at the ice margin? (we've known for some time that we need to use one-sided differencing for surface elevations at grounding lines, for example)
On 03/23/2015 02:12 PM, stephenprice wrote:
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). check https://cloud.githubusercontent.com/assets/4983771/6790578/54fd143c-d16e-11e4-89a8-b1a8645b2338.png
Image with NO checkerboarding in sfc speed field after ~20 years of integration (when using the centered elevation gradient scheme). nocheck https://cloud.githubusercontent.com/assets/4983771/6790610/870461f6-d16e-11e4-87ca-7c6cce9f1320.png
— Reply to this email directly or view it on GitHub https://github.com/ACME-Climate/cism-piscees/issues/25.
Dan Martin email: DFMartin@lbl.gov Mail Stop 50A-1148 phone: (510) 495-2852 Lawrence Berkeley National Laboratory fax: (510) 486-6900 1 Cyclotron Rd. Berkeley, CA 94720
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