-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
From @DanFMartin on March 23, 2015 21:27 For the idealized dome test case mentioned here, do you need to use On 03/23/2015 02:12 PM, stephenprice wrote:
Dan Martin email: DFMartin@lbl.gov |
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. |
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).
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
The text was updated successfully, but these errors were encountered: