[pawank]

This is about explicit, 3D, compressible NS solver. Consider two cases:
1) Code diverges after n time steps with step size dt. When I reduce the time step to 0.1*dt, the code diverges after 10*n time steps. i.e. code blows at the same actual time.
2) Code diverges after n time steps with step size dt. When I reduce the time step to 0.1*dt, the code still diverges after n time steps.

Which of the cases indicate a problem in CFL condition/numerical instability? What does the other case indicate? Or is it that either of the cases don't indicate anything specific, and there can be multiple possibilities where the problem is?

Thanks

[FMDenaro]

I think that before to talk of a numerical instability you have to check that exists a certain smaller dt for which your computation is stable. Conversely, I would always check for some bug in the code.

[pawank]

The code works when Mach no of the flow is 2. When I increase it to 4, it diverges. I decreased dt several times but it diverges at the same nth time step.

[FMDenaro]

Are you solving Euler equations? Do you consider in the CFL condition the sound velocity? no dt values drive to a stable solution at M=4?

[pawank]

I'm solving compressible navier stokes.
Actually the code is not mine and the person who wrote the code has not included any CFL condition. He used a dt which worked for him for Mach no 2. I have to run it for Mach no 4. I just wanted to test it out quickly so when it diverged, I reduced dt, but does not work.
And no dt works. Reduced it to at least 0.0001*dt just to see if it works, but it doesn't.

[FMDenaro]

Originally Posted by pawank

I'm solving compressible navier stokes.
Actually the code is not mine and the person who wrote the code has not included any CFL condition. He used a dt which worked for him for Mach no 2. I have to run it for Mach no 4. I just wanted to test it out quickly so when it diverged, I reduced dt, but does not work.
And no dt works. Reduced it to at least 0.0001*dt just to see if it works, but it doesn't.

these details are not sufficient to understand the problem.... what are you simulating? Increasing the Mach number you increase the velocity and the Reynolds number. Have you checked the fields before the code diverges?

[pawank]

Originally Posted by FMDenaro

these details are not sufficient to understand the problem.... what are you simulating? Increasing the Mach number you increase the velocity and the Reynolds number. Have you checked the fields before the code diverges?

I am simulating a laminar boundary layer. The code diverges in very few iteration and hence there is not much seen in the flow field. It is as good as initial conditions.
The conditions are standard atm. And with the present conditions, Reynolds no is around 1000

And thanks for the help

[FMDenaro]

Usually, numerical instability does not appear in few steps... I would check for a bug in the code ...I suggest to run the code for a single dt and check all the variables.

[pawank]

Originally Posted by FMDenaro

Usually, numerical instability does not appear in few steps... I would check for a bug in the code ...I suggest to run the code for a single dt and check all the variables.

Thanks for the suggestion

[ashi.ismd]

I use Cradle CFD for my simulations and I do a lot of transients. You may want to refine the mesh close to the boundaries especially. Secondly, run the simulations with a fixed time step instead of CFL and monitor the CFL number as the simulation progresses. Go back and use a Courant number that is lower than that.

[pawank]

Thanks ashi.ismd

[sbaffini]

Generally speaking, if the simulation blows up at a given physical time, then it is a matter of physics or how you represented it in your code.

In this sense, a CFL instability is physics, because your scheme amplifies perturbations at a given rate. But you might have, as well, also introduced additional
"unwanted" physics by some coding mistake.

In contrast, when the simulation blows after a fixed number of steps, no matter how small they are, it is much more likely that something is wrong from the programming point of view (allocations, etc.).

[pawank]

Originally Posted by sbaffini

Generally speaking, if the simulation blows up at a given physical time, then it is a matter of physics or how you represented it in your code.

In this sense, a CFL instability is physics, because your scheme amplifies perturbations at a given rate. But you might have, as well, also introduced additional
"unwanted" physics by some coding mistake.

In contrast, when the simulation blows after a fixed number of steps, no matter how small they are, it is much more likely that something is wrong from the programming point of view (allocations, etc.).

Thanks...What i was looking for...