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

Adaptive time step constraints not stict enough #29

Open
fjansson opened this issue Jan 5, 2018 · 2 comments
Open

Adaptive time step constraints not stict enough #29

fjansson opened this issue Jan 5, 2018 · 2 comments

Comments

@fjansson
Copy link
Contributor

fjansson commented Jan 5, 2018

In tstep.f90, tstep_update() determines the largest dt that is safe to use.
In the model, there are two diffusion rates, ekm for momentum and ekh for other quantities (thl, qt). W.r.t. diffusion, the time step is currently limited only based on ekm. However, ekh is larger than ekm, and thus the time step limit is not always strict enough.
Some of our model crashes showed checkerboard-like disturbances in qt, of the kind that show up when a diffusion problem is solved with too large time steps. When I added ehk to the time step criterion, those problems disappeared.

peclettotl=max(peclettotl,maxval(ekm(2:i1,2:j1,k))*rdt/minval((/dzh(k),dx,dy/))**2) 
peclettotl=max(peclettotl,maxval(ekh(2:i1,2:j1,k))*rdt/minval((/dzh(k),dx,dy/))**2)   ! propose adding this

Note there are two places in the code where this should be done. This of course comes with the cost of smaller time steps, so the simulations take longer.

In another sense, the diffusion time step limit is sometimes too strict. It considers the smallest of (dx, dy, dz). When dz << dx, dy, this is stricter than necessary.

The current condition is

ekh * dt * (1/min(dx,dy,dz)**2) < 1/6

which could, I think, be relaxed to

ekh * dt * (1/dx**2 + 1/dy**2 + 1/dz**2) < 1/2

The constant 1/6 is actually the parameter peclet.

@Chiil
Copy link
Contributor

Chiil commented Jan 5, 2018 via email

@fjansson
Copy link
Contributor Author

fjansson commented Jun 5, 2019

The issue of ekh and ekm is fixed in version 4.2, commit e9257ef.
The question of considering all of dx,dy,dz instead of the smallest is still open (i.e. the limit may now be stricter than necessary).

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

2 participants