Bernard & Salvador

Sorry to butt in to your exchange but I have followed it with great interest.

With regard to instability, I presume that both of you refer to algorithm failure (not code failure) which can occur (i) when the solution goes out of physical bounds (ii) when genuine mathematical instability occurs (either linear or nonlinear) and perturbations grow without bounds. The latter cannot be rectified by fixes but the former can be fixed with some luck by artificial means (like setting lower bounds for pressure, density or temperature, resorting to lower CFL numbers etc.). In my view this is not an instability in the usual sense of the term although we expect our iterive schemes to keep all intermediate solution within the physically valid domain. Remember that higher order TVD schemes are not really TVD for nonlinear systems.

Bernard's experience with the Roe solver may not be surprising since the latter does not always produce valid solutions to physically valid Riemann data. You may refer to Sjogreen et.al's JCP paper published a few years ago on this problem. Positively conservative schemes are an attempt to overcome this problem, but here again one ought to be careful with higher order schemes. I mean, that this property is dependent on the way the HO extensions are formulated. This may also explain why Salvador has a positive experience with the HLLC solver, whose first order formulation is known to be PC

Both of you might know all or some of this, but I thought if this has not figured in your discussion I might draw your attention to these aspects.

Ravi

I agree with most of the JC Chien explanations but one. It is not correct to say implicit methods are inherently faster than explicit methods (the cup of cofee at the train station...). The contrary is not right neither.

An explicit solver is several hundred times cheaper per node/per time step than an implicit one (say 200). The downside is that the time step is limited by the CFL condition to something in the vicinity of 1 microsecond (for the applications I'm interested in like airflow around automotive components where the mesh size goes down to 0.5mm-). Therefore, as soon as you need more than 200 explicit time steps per implicit time step, implicit is faster, otherwise explicit is faster. Two exemples: (i) Steady state flow can be reached in one single step in Implicit meanwhile you will need to converge to the steady state in explicit which will take several dozen thousand time steps. Here implicit is clearly better (although onemight argue over the physical value of assuming steady most of the flows of interest...) (ii) High frequency phenomena. We are studying acoustic behavior of car components like fans with frequencies going up to 4000Hz. In order to treat this correctly, you need 4 points per highest frequency => maximal time step is 62 ms (otherwise, although stable, you miss what you are looking for). Doing 62 explicit time step per one implicit time step is faster by a factor of 200/62 = 32.

(1). Good point, I think, I agree with you. (2). It is important to know that more operations are required to implement the implicit method. So, in general, one implicit iteration takes much longer time than one explicit iteration. (3). Within the stability limit, the explicit method is definitely simple and easy to program. (also easier for vector or parallel computers)

Hi Dimitri,

A small disagreement. It is not possible to get accurate steady state solution in one step using implicit methods. It obviously depends on the quality of the initial conditions. The only situation where what you say could be nearly true is when you are solving a purely elliptic problem!

regards, chidu...

Chidu, I agree with you. Actually, we develop explicit software for fluid and structure since 15 years! But I wanted to stress the somewhat theoretical advantage of the Implicit for steady state. Our experience is that steady state sounds more and more as a an inacurate approximation of reality, convenient for CPU/practical reasons. Our M-Explicit code is obviously performing transient analysis and we have been implementing recently an hybrid RANS/LES turbulence model in our M-Implicit solver that leads to transient simulations in order to get better drag/lift solutions. www.mcube.fr

Hi Ravi, Bernard and Salvador,

One point to add to the discussion/confusion...

Obviously, I agree on the importance of positivity-preserving fluxes. Any linearised Riemann solver (eg. Roe) must be used entirely at the owner's risk - without ad hoc corrections, it is a certainty that it will fail at some point. Ravi is also absolutely right to point out the caution you need to take in extending any method to higher order accuracy, although there is a neat solution to this. There is an excellent paper by Perthame and Shu which surprisingly few people seem to know about : B.Perthame and C-W.Shu - On positivity preserving finite volume schemes for Euler equations, Numer. Math 73:119-130, 1996. This shows how to take a positivity-preserving flux and extend it to arbitrary orders of accuracy.

However, it is possible that the problem under discussion here is not due to higher-order methods or even the positivity of the underlying flux. Any first-order method can fail with negative pressures (including schemes based on the exact Riemann solver) if we take a time-step larger than that allowed by the physical limits of our linearisation. The obvious example is a shock wave moving against the flow (ie., associated with the u-c wave). If our Jacobians are estimated in a region slightly upstream of this wave, in a pocket of supersonic flow (where the local u, u-c, u+c are all >0) the numerical `bridges' which connect this region to the downstream u-c wave can be destroyed. Then, there is no way for the upstream-moving wave to influence this region in the next time step, no matter how large the CFL is, or how good our linear solver is. As a result, the wave piles up at the Nyquist frequency of the grid, in much the same way as in explicit schemes with a CFL that is too large. It is very easy to reproduce this problem - in any impulsively-started flow with Mach>1 you will probably not be able to push the CFL very high until the u-c wave (bow shock) settles down. This is the price we pay for our linearisation (in time) of a non-linear problem.

I'd be interested to know if anybody out there has a neat solution to this problem. The only solution I know (other than ramping the CFL) is a cheap and dirty one - to add dissipation until the shock settles. This has the effect of `reconnecting' those bridges. It is debatable how physical this is though. There is no justification for adding this dissipation in an unsteady flow (to resolve our u-c wave properly we need to reduce our CFL, and then our troubles disappear anyway) - even in a steady flow we should make sure the dissipation is removed completely once the shock settles.

Ironically, an implicit scheme based on something that already has lots of evil, insidious dissipation (any complaints/hate mail will be considered as an admission of guilt) is less likely to suffer this problem. If we can accept smeared solutions, we might be able to use a more diffusive flux directly. I think it is preferable to use our best possible flux model, with a judicious combination of CFL control and, perhaps, just through transients, a bit of dissipation. Does anybody else have a better idea ?

Paul.

[Bdew8556]

Hey Patrick, this response is the best! so many people have said that implicit schemes can handle a large time step but don't explain WHY. Yours does. Many thanks.