sonicFoam not matching shock theory
Hi all,
I am trying to use sonicFoam for some inviscid simulations, and my test case (supersonic flow over a wedge) does not seem to be following the analytical solution. I am simulating a 14.03 deg wedge at Mach 7, sea level atmospheric conditions. If you look at the image below, it shows that the shock sits lower than the analytical solution (the line source). http://img693.imageshack.us/img693/9880/wedge.png I can adjust the thermophysical properties get the shock to sit in the right position, but this does not give me much faith in other solutions! My thermophysical properties are: Code:
thermoType ePsiThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>; Does anyone have any ideas as to what could be causing this? I have simulated the same wedge in other solvers (rhoCentralFoam and rhopSonicFoam) and the results match the analytical theory. Thanks in advance for any help, Alan 
Hello, I'm sorry to answer with a question: what does rhoSonicFoam does?
The major difference I can see between the solvers you used is that rhopSonicFoam and rhoCentralFoam solve for conserved variables, while sonicFoam does not. I hope this additional test can help to clarify. Best, 
No problems at all Alberto, your help is much appreciated. Here is an image of the wedge simulated in rhoSonicFoam, as you can see shock lies in the correct position.
http://img339.imageshack.us/img339/4...sonicwedge.png Thanks again, Alan 
Interesting.
To exclude a possibility: in your run in rhoCentralFoam, did you set thermoPhysical properties to the same data you report for air (some tutorials use the normalised gas)? Best, 
Hi Alberto,
If I run the wedge in rhoCentralFoam with the same thermophysical properties as my sinicFoam case (i.e. not normalised) then the shock matches the theory. It appears to be a problem with the sonicFoam solver, as it gives the same (incorrect) shock position in both normalised and regular thermophysical properties. Thanks again for your help, it is much appreciated. 
If there is no bug, it might be related to how the equations are discretized, as I said before, but it's just a guess.
I'd suggest to use codes with the conservative form of the equations for shock capturing. Best, 
Try tutorial
I tried sonicFoam on OF1.3, shock tube case in tutorial. It gives the wrong result (as said before, probably due to the fact that scheme is not conservative).
I checked against exact solution, obtained from Ccode in the link below http://num.math.unigoettingen.de/kn...ro_ss2006.html Haven't checked later versions (but that would be easy to do). 
So is there a way to fix this? sonicFoam seems to be the obly stable solver for my problem, the others seem to get anomalies in the solution that diverge

Quote:

Well, in rhoCentralFoam I am unable to progress the solution without it crashing within a few iterations (getting a maximum number of iterations exceeded error). This is the error I get:
Code:
Create time http://img197.imageshack.us/img197/7...entralfoam.png This is what the simulation looks like in rhopSonicFoam: http://img101.imageshack.us/img101/4...psonicfoam.png Note the 'stagnation' points at the top of the compression wedge. These slowly over the time of the solution go to zero, causing the time step (with adjust time step on) to go to a very large number. Here is the simulation in sonicFoam: http://img101.imageshack.us/img101/9417/sonicfoam.png This gives a nice stable solution, although with the incorrect shock angle. I have a well refined, structured mesh, so I do not believe this to be the problem. This is also only a simple case which I need to expand to much more complex geometries, so the apparent stability of sonicFoam is quite appealing to me. Thanks for your help KrisT. 
Quote:

Quote:
Are you performing inviscid runs in rhoCentralFoam? It seems to me the behaviour at the walls is different. Additionally, could you show a zoom of the mesh with the solution under it (Surface with edges in paraview) around the tip of the triangle at the exit (where rhoCentralFoam has a sort of blue circle in the solution). Best, Alberto 
Hi Alberto,
Im not sure what you mean by 'is it converging before the crash?'. Do you mean is the energy equation converging, or is the entire solution converging? I am solving this case as inviscid, as far as I am aware rhoCentralFoam is only an inviscid solver? My wall BC's are slip for the velocity file, and zeroGradient for p and T. Here is the image that you asked for (note the flow is from left to right, so this is at the inlet, not the outlet): http://img13.imageshack.us/img13/991...tralfoam01.png I have also attached a similar picture around the entry to the isolator, which is the area of flow I believe is giving the solvers all the trouble. http://img185.imageshack.us/img185/9...tralfoam02.png Thanks again for your help Alberto, it is very much appreciated. Alan 
Quote:
Quote:
Quote:
Best, Alberto 
Ramp up Mach number?
Maybe I'm stupid here, but what happens if you ramp up the Mach number?
Would you get a stable solution for a lower Mach number? Is it possible to specify varying (increasing) inlet Mach number? /j 
Hi Alan
although a somewhat old thread.but I saw the same problem when a moving shock goes near the wall.residuals of U.x and h increases,although crashing doesn't occur.I use maxCo too. has had anyone this problem too to share? well,then sonicFoam solves only nonconservative form of equations.that was a very good information you gave to me! 
All times are GMT 4. The time now is 01:11. 