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

Positive preserving scheme (SSP & limiter ) #1327

Open
Zhengyu-Huang opened this issue Jun 15, 2023 · 6 comments
Open

Positive preserving scheme (SSP & limiter ) #1327

Zhengyu-Huang opened this issue Jun 15, 2023 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@Zhengyu-Huang
Copy link
Contributor

Zhengyu-Huang commented Jun 15, 2023

cosine bells with $q \in [0, 1]$ , the setup in the main is $q \in [0.1, 1]$, so no negative value is observed

extrema with 12 day / 1200 steps: ne = 6 ne = 16
(-4.33710126096385e-22, 0.7604223043784831) (-5.501461995104536e-5, 0.9508024233242366)

extrema with 120 day / 12000 steps: ne = 6 ne = 16
(0.001258494405958857, 0.06971253964379465) (-0.005024378170539984, 0.10875800730425647))

The modified branch is dzh/limiter-issue,

examples/sphere/limiters_advection.jl
@Zhengyu-Huang
Copy link
Contributor Author

For the cosine bells case (12 day / 1200 steps, ne = 16): element 23 has smallest averaged q, -5.4674658761003794e-5, all nodal values are negative [-5.064671434859331e-5 -5.501461995104535e-5 -5.501461995104534e-5 -5.4975440065034456e-5; -4.964183135120574e-5 -5.492509505874185e-5 -5.501461995104534e-5 -5.501461995104533e-5; -5.5006230363461435e-5 -5.501461995104534e-5 -5.501461995104534e-5 -5.501461995104534e-5; -5.2596713587859534e-5 -5.501461995104534e-5 -5.2834909059669035e-5 -5.2927768138292654e-5]

@Zhengyu-Huang
Copy link
Contributor Author

For the cosine bells case (120 day / 12000 steps, ne = 16): element 1118 has smallest averaged q,-0.004942804044896136, all nodal values are negative [-0.005017511375060559 -0.005011217573981225 -0.004867585800051765 -0.004691781410777255; -0.004890483207688044 -0.004898234251674527 -0.004922189197276045 -0.0048917399323111605; -0.004915287575676262 -0.00499609889886179 -0.005024308420427279 -0.005024308420427279; -0.004629447065001463 -0.0048151350251337665 -0.004889046868750097 -0.004880251388114655]

@Zhengyu-Huang
Copy link
Contributor Author

Suggestions from Mark Taylor:

  1. check that whether it is due to that the roundoff accumulates over long times
  2. Comparison with E3SM, "In E3SM, we still maintain the ability to run the dycore in standalone mode, which can run these shallow water tests. I'd be happy to try and run this case for these long times if that would be helpful."
  3. Comparison with E3SM. Strict mass conservation with the roundoff error accumulating in the clipping, "When we were still using SE transport, we switched to a version that finds a solution without iteration - latest version is "limiter_option=9", code here:
    https://github.com/E3SM-Project/E3SM/blob/master/components/homme/src/share/derivative_mod_base.F90
    subroutine "limiter_clip_and_sum" Maybe it has different roundoff accumulation properties."
  4. Lauritzen's "bakeoff" paper, doi:10.5194/gmd-7-105-2014 , might be useful. It's got results from HOMME and CAM-SE, which should nearly identical, except CAM-SE is running with larger hyperviscosity. I think it only has results after 1 revolution though so doesn't address this particular issue.

@charleskawczynski
Copy link
Member

I spoke with @Zhengyu-Huang today about these issues. It seems to me that we have a few critical questions to answer:

  • Assuming machine precision errors can accumulate, is the limiter expected to strictly ensure positivity?
  • If the limiters are behaving "as expected", is the time stepper limiting the state at all of the necessary stages?

It seems to me that the two most critical parts of these issues revolve around two points:

  • How we can characterize the behavior of the limiter application, and
  • Is the time stepper going to ensure positivity

The first point can be tested in a script rather quickly by testing limiters with a variety of fields values. For the second point, I was hoping that we added a meta collection utility into ClimaTimeSteppers.jl to improve transparency: CliMA/ClimaTimeSteppers.jl#106.

Are we calling limiters everywhere we need to in CTS? It's a bit difficult to extract this information in a non-invasive way, maybe there's introspection utilities?

@sriharshakandala
Copy link
Member

@charleskawczynski , @szy21 : Is this issue still active?

@szy21
Copy link
Member

szy21 commented May 30, 2024

@charleskawczynski , @szy21 : Is this issue still active?

We should be able to close this, and all other dycore related issues after the recent modification/refactoring of the dycore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants