Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
billsacks opened this issue Jul 6, 2018 · 2 comments

Comments

@billsacks
Copy link
Member

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).
check

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

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

@billsacks
Copy link
Member Author

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

@billsacks
Copy link
Member Author

From @stephenprice on March 23, 2015 21:38

@DanFMartin, the relevant one-side gradients mentioned for the Halfar test case are applied in the interior. There's a range of options for how the gradients are calculated at the margins, but I'm not clear if those are relevant here or not.

billsacks added a commit that referenced this issue Jun 23, 2021
Add a GPTL enabled build for Cheyenne, and update BATS

This PR: 
 - Adds a `Makefile.sgi_intel` Makefile template so GPTL will build on Cheyenne and a `cheyenne-intel-cmake.bash` script has been added to build CISM with GPTL timer support (and out-of-source-build support). This bash script will allow BATS to build CISM on Cheyenne.

- Some additional BATS support has been added for Cheyenne, but the submission script dictionary is incomplete. What PBS directives should be default? 

- Some updates to the build and test structure (BATS) to work with the new LIVVkit 2.1, mostly to clean up some of the python, adjust the output directory structure, and check for GPTL.
    
- All calls to python are now explicitly python 2 in case CISM is being run on a python 3 based system (modern ubuntu).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant