Oceananigans.jl: Are we computing CFL correctly?

[ali-ramadhan]

https://github.com/CliMA/Oceananigans.jl/blob/a343711f1101b1a433124f5f9697ce60b1011a40/src/Utils/cell_advection_timescale.jl#L2-L12

I guess the proper way (?) to compute the cell advection timescale would be to compute Δx/u + Δy/v + Δz/w at every grid point then take the maximum of that field but this requires an intermediate field and is probably slower than the current implementation.

I guess the problem is you can have diagonal velocities, i.e. time step needs to be lower if u = v = w = 1 compared to u = 1, v = w = 0 even with isotropic grid spacing.

Could this help explain why we find that we have to keep CFL a bit lower than expected by theory?

[navidcy]

how other codes compute it? e.g. Dedalus (cc @kburns)?

[kburns]

Dedalus adds all the "grid-crossing frequencies" (e.g. u/dx, v/dy, w/dz) at each point, takes the maximum of this quantity across all grid points, and takes its reciprocal to determine the CFL time. We chose this because its pretty simple and properly handles doppler boosting of waves on top of mean flows. Apparently according to wikipedia this is also the right thing for diagonal velocities... but I'm not sure that's something you can show rigorously for spectral methods. Maybe so. In any event, we find that the stability boundaries in terms of the CFL safety factor (scaling the dt selected as described) vary a lot based on the timestepper and problem, anyways.

[francispoulin]

If the current approach is significantly faster than one option is to simply take the time step to be 1/3 of what you are currently doing. This assumes the worst case that the velocity is as fast in each direction. It's more conservative than the sum but should be slightly better to ensure stability. However if you take your clf number to be 1/3 of what you are doing, then you get the same result.

This doesn't seem to be a problem to me but maybe I'm not getting all the details.

[ali-ramadhan]

Ah true. I suppose if you're gonna do something quick and dirty, then better be conservative than lenient.

Might be nice to have a proper kernel that computes CFL but we have to reduce over the whole grid which will require an extra field to store CFL values for each grid point so maybe it's just better to do a quick conservative estimate for CFL, seeing as an accurate estimate might even be that useful as @kburns pointed out it varies a lot based on the model setup and the problem.