Refine CFL condition in seismic

[mloubout]

refine elastic cfl according to Sei paper
https://doi.org/10.1137/0916052

[codecov]

Codecov Report

Merging #1348 into master will increase coverage by 0.13%.
The diff coverage is 98.57%.

@@            Coverage Diff             @@
##           master    #1348      +/-   ##
==========================================
+ Coverage   86.62%   86.76%   +0.13%     
==========================================
  Files         183      183              
  Lines       26330    26379      +49     
  Branches     3619     3617       -2     
==========================================
+ Hits        22808    22887      +79     
+ Misses       3095     3065      -30     
  Partials      427      427              

Impacted Files	Coverage Δ
examples/seismic/acoustic/acoustic_example.py	50.94% <92.30%> (+24.75%)	⬆️
devito/types/basic.py	94.78% <100.00%> (+0.03%)	⬆️
examples/seismic/acoustic/operators.py	96.20% <100.00%> (+16.45%)	⬆️
examples/seismic/acoustic/wavesolver.py	100.00% <100.00%> (ø)
examples/seismic/elastic/elastic_example.py	77.14% <100.00%> (+5.71%)	⬆️
examples/seismic/model.py	91.48% <100.00%> (+6.57%)	⬆️
examples/seismic/skew_self_adjoint/wavesolver.py	100.00% <100.00%> (ø)
...les/seismic/viscoacoustic/viscoacoustic_example.py	70.37% <100.00%> (ø)
...mples/seismic/viscoelastic/viscoelastic_example.py	77.14% <100.00%> (+5.71%)	⬆️
examples/seismic/viscoelastic/wavesolver.py	100.00% <100.00%> (ø)
... and 7 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d411d93...e9816f4. Read the comment docs.

[georgebisbas]

I suggest adding somewhere the source of the changes.(i.e. the paper).
Seems fine for me. Tested locally.

[mloubout]

I suggest adding somewhere the source of the changes.(i.e. the paper).

It's ref to in _cfl_coeff in model.py

[georgebisbas]

I can see tests passing, all seem fine for me, minor comments.

[rhodrin]

Not sure I like this:

1. We are seeing instabilities without this factor?
2. Why this way instead of modifying the critical dt calc?

[mloubout]

1. yes. You can look at Thorbecke's implementation where he basically says that with Q, it's not always stable and need to play with dt.
2. I can try to put in model, but that would probably make it smaller for some other examples too.

[rhodrin]

1. Yeah, had seen that before.
2. Indeed, it's a bit tricky - I'm not sure if it's better to have our 'default' critical_dt air on the side of caution for 'robustness' or not? What do you think? But maybe we could add a factor kwarg which is by default 0.9 or 1.0 (don't really mind)? At least this way the api will robust/trivial to change for any tinkering down the line - and then people will easily be able to look at the docstring to understand why such factors are sometimes needed. But I think that some_factor*critical_dt with no comment should be avoided at least.