Does it blow up at the leading edge every time?

Sent from my iPhone

On Dec 15, 2016, at 5:09 AM, Selbach, Fabian <fabian.selbach@student.uni-siegen.de> wrote:

Hi Gianmarco,

thanks for your answer.

Decreasing the CFL condition does not help. Neither using a very low CFL, nor using a constant dt.

Starting with a lower IC helps only in terms of using a lower Re. Higher Re terminates, so I think it must be a problem due to physics.

By running DG-collocated you mean using an expansion tag like:

<E COMPOSITE=“C[0]” BASISTYPE=“Modified_A,Modified_A" NUMMODES="3,3" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre" NUMPOINTS="6,6"  FIELDS="rho,rhou,rhov,E" />  ?
Yes I tried that what you mentioned in the paper, but it does not help.

Finally using a polynomial degree of p=1 and a relative coarse mesh (I refined every time at the points of oscillation after termination) helps to run the simulation (actually until dimensionless t=14) , but with very bad accuracy. After increasing p = 2 with the same mesh it terminates again after t<1. Of course I adjust the time-step.
So it seems that there must be an addiction between the resolution of the mesh and the possible polynomial degree? Is this the case?

Is there actually a way to do a LES or is the only possibility to use an unresolved DNS?

Best regards
Fabian

  
Von: Mengaldo, Gianmarco [g.mengaldo11@imperial.ac.uk]
Gesendet: Montag, 12. Dezember 2016 18:50
An: Selbach, Fabian
Cc: Moxey, David; Mengaldo, Gianmarco; Serson, Douglas; nektar-users
Betreff: Re: [Nektar-users] Nonphysical terminated simulation - CompressibleFlowSolver

Hi Fabian,

can you try with a constant dt that satisfies the CFL condition (i.e. take the one plotted at the first few time-steps when using the CFL tool and decrease it by one order of magnitude).

Also, I think that your proposed strategy of starting with a lower IC might help.

Finally, are you running DG-collocated?
If so, I suggest you increase the number of quadrature points. while keeping the same polynomial order.
You can find more details on this topic here: http://www.sciencedirect.com/science/article/pii/S0021999115004301 

Let me know if this helps!

Best,
Gianmarco


Gianmarco Mengaldo
Department of Aeronautics and Mathematics
Room 730/731, Huxley Building
Imperial College London
South Kensington Campus
London SW7 2AZ 
M: +447462029290 



On Dec 5, 2016, at 9:35 AM, Selbach, Fabian <fabian.selbach@student.uni-siegen.de> wrote:

Hi Dave,
Hi Gianmarco,

thanks for your answer.
Yes I have already tried some mesh refinement, but either the time step is getting horrible small or it still terminates.
I tested the expansion type, but it does not help (still termination).

Actually I am thinking about starting with lower initial conditions and increasing them step by step. Maybe this helps.

In addition to it some input from Gianmarco or a working example at a high Reynoldsnumber with the CompressibleFlowSolver would be great.

Thanks in advance.

Best regards

Fabian
________________________________________
Von: David Moxey [d.moxey@imperial.ac.uk]
Gesendet: Montag, 5. Dezember 2016 11:20
An: Selbach, Fabian
Cc: Serson, Douglas; nektar-users@imperial.ac.uk
Betreff: Re: [Nektar-users] Nonphysical terminated simulation - CompressibleFlowSolver

Hi Fabian,

Thanks for getting in touch and apologies for the slow response. I have a few thoughts that might help.

- I would say that from your pictures, the meshes look very coarse, so you could definitely try some additional refinement.

- Another source of instability can arise through the default quadrature points being used for inner products etc. You might find that using a more consistent integration could help, particularly if the grid is not well resolved. Depending on your mesh and setup, you can use an expansion tag like:

<E COMPOSITE=“C[0]” BASISTYPE=“Modified_A,Modified_A" NUMMODES="3,3" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre" NUMPOINTS="6,6"  FIELDS="rho,rhou,rhov,E" />

Note that this would use a polynomial order of 2 (nummodes = 3) whilst using double the number of grid points for integration (numpoints = 6) -- the default is one extra (numpoints = 4) which is generally sufficient but in the case of marginal resolution may lead to significant aliasing error. It'll therefore be more expensive but may be more robust.

- I am not sure our CFL estimate for the compressible solver is all that great, so I would probably stick to a constant timestep, at least in the short term to investigate the reason for this instability. This is something we need to work on.

- You should be aware that for these explicit schemes, larger polynomial orders will have a greater impact on the size of the maximum timestep, so perhaps best to limit to p=3-5 -- p=7 might be a bit restrictive on the timestep. It is probably better to try a grid refinement rather than increase the polynomial order.

If none of this helps we can also see if Gianmarco has some input since he has run these cases extensively during his PhD and encountered may similar problems!

Cheers,

Dave

On 2 Dec 2016, at 09:53, Selbach, Fabian <fabian.selbach@student.uni-siegen.de> wrote:

Hi Douglas,
Dear users,

thanks for your explanation of the EulerADCFE.

Your hint to decrease the CFL does not help to stabilize the simulation. Also decreasing the time step on my own to a very small one (analogical CFL=0.4) and to use another time integration method makes no difference. The simulation terminates at the same time.
But I observed, that using less CPUs for parallel simulation helps to remain stable for a longer time, but finally it terminates too. Could it be a problem due to parallelization?

I will try to generate a new and better grid, because this is the last clue I got.

Has somebody else an idea what could causes this oscillations?

Thanks in advance!

Best regards

Fabian
Von: Serson, Douglas [d.serson14@imperial.ac.uk]
Gesendet: Mittwoch, 30. November 2016 15:17
An: Selbach, Fabian; nektar-users
Betreff: Re: [Nektar-users] Nonphysical terminated simulation - CompressibleFlowSolver

Hi Fabian,

I don't know what is causing these oscillations (maybe you need a lower CFL), but regarding your other question: EulerADCFE allows using artificial diffusion for shock capture, while EulerCFE is just the standard Euler solver. For EulerADCFE you need to set the "ShockCaptureType" property (possible values are "Smooth" and "NonSmooth") and the parameters described in section 9.4.1 of the user guide.

In the most recent version of the master branch (this was changed just a few days ago), it is also possible to use shock capture directly with EulerCFE. In this newer version, EulerCFE and EulerADCFE are the same thing, with the second name kept for backwards compatibility.

Cheers,
Douglas
From: nektar-users-bounces@imperial.ac.uk <nektar-users-bounces@imperial.ac.uk> on behalf of Selbach, Fabian <fabian.selbach@student.uni-siegen.de>
Sent: 30 November 2016 13:21:42
To: nektar-users
Subject: [Nektar-users] Nonphysical terminated simulation - CompressibleFlowSolver

Dear users,

I hope you can help one more time. I got nonphysical oscillations during my airfoil-simulation. At that time my simulations terminate with the message: "NaN found during time integration". For more information of the error and parameters see pictures below. I tried to solve this by a higher polynomial degree up to p=7 (this generates 1.5 Mio grid-points here for a 2D simulation), but the simulation terminates still. The time step itself is computed by a fixed CFL=0.9 condition. Maybe this is the wrong way, because this condition is not sufficient?

So please can somebody give me a hint about that? Do I have to use another kind of grid, because the resolution of the boundary at the peak of the airfoil is not high enough or the grid lines have no be orthogonal to the surface? I am already using the spherigons-tool and tried to get a smooth boundary of my airfoil.

I am using the CompressibleFlowSolver on a parallel run up to 96 CPUs by solving the Euler-Equations (EulerCFE) and the Navier-Stokes-Equations (NavierStokesCFE). The simulation terminates for both.

By the way what is the difference between EulerCFE and EulerADCFE (there are no information about it anywhere)? I tried to run the example NACA0012 of the paper "Nektar++: An open-source spectral/hp element framework". The conditions use the EulerADCFE, but by running this example the simulation does not terminate, but also does not change (values of every variable in the whole domain are constant over the time - no changes?).

Thanks for any help!

Best regards

Fabian


Visualization of the grid at a polynomial degree of p=2 just before terminating:

<Screenshot_2016-11-29_14-04-05.png>

With auto-scale:
<Screenshot from 2016-11-29 14-27-59.png>

Same solution with scaling by user:
<Screenshot from 2016-11-29 15-33-10.png>

Please take into account the scaling above.

Error and conditions for example p=2:


<Screenshot from 2016-11-29 14-32-53.png>
<Screenshot from 2016-11-29 14-33-22.png>
<Screenshot from 2016-11-29 14-33-38.png>

Visualization of the grid at a polynomial degree of p=7 just before terminating:

<Screenshot from 2016-11-29 16-18-39.png>

(a few time steps after that the simulation terminates and the values go against inf...)








_______________________________________________
Nektar-users mailing list
Nektar-users@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/nektar-users



--
David Moxey (Research and Teaching Fellow)
d.moxey@imperial.ac.uk | www.imperial.ac.uk/people/d.moxey

Room 364, Department of Aeronautics,
Imperial College London,
London, SW7 2AZ, UK.