Questions about possible singularity and compressible flow
I have a simulation with external flow where the air velocities vary from a low of zero (still air) to ~ 500-600 ft/sec in places. Simply to get things going, I have been running the solver in incompressible mode but want the best accuracy. Most of the the fluid flow that is generating the lift is at > 0.3 Mach. For such a range of velocities is it best to run the solver in incompressible mode or compressible mode? For Caedium, Is there any rule of thumb abut the difference in accuracy (lift, velocity values) with solving being done in incompressible mode, versus in subsonic compressible mode?.
When I have tried to run the solver in compressible mode, it fails on the first iteration. Could that be because my initial velocity for the simulation is 0, 0, 0, or is it more likely that something else is going on, i.e., compressive flow solving is simply less robust than incompressible flow solving? Is there any rule of thumb for reducing the subsonic compressible flow relaxation factors to see if that is the problem?
Thanks for your help. Despite my questions I have really benefitted from Caedium and have gotten a ton of useful information from it regarding the design of my project.
Feedback
Questions? Ideas? Problems?
Compressible solver
It sounds like you'll have subsonic compressible flow, so for accuracy you do want to run with State:Gas->Compressible = Subsonic. For an idea of the differences in accuracy between running incompressible for a compressible flow try experimenting with a simple case such as the tutorial "Transonic Flow Over the NACA 0012 Airfoil".
Your velocity initialization to zero could be a problem, so try using a finite value.
Compressible simulations are particularly sensitive to the 'p' (pressure) relaxation factor, so try reducing it successively by a factor of 2. Note that this then will extend your turnaround time to convergence proportionately. Typically you can expect 1000s of iterations before you see convergence.
Yes, the incompressible solver is more robust than the compressible solver. For compressible simulations you have to be sure your reference values and boundary conditions are consistent. All your inlet conditions for the subsonic compressible solver have to also be subsonic.
That got it running but it fails with reasonable velocities
This was very helpful!
After changing my reference velocity from 0 to 0.001 ft/sec, the solver ran. However, in compressible mode the solver fails within several hundred iterations even with mesh refinements and decreasing the relaxation factors. The error message is this:
“Warning:
volume_39 [www.1519.5] RANS Flow: Failed
Unexpected process exit.
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Maximum number of iterations exceeded
[1]
[1] From function thermo::T(scalar f, scalar T0, scalar (thermo::*F)(const scalar) const, scalar (thermo::*dFdT)(const scalar) const, scalar (thermo::*limit)(const scalar) const) const
[1] in file /Users/rjs/projects/of/2.2/OpenFOAM-2.2.x/src/thermophysicalModels/specie/lnInclude/thermoI.H at line 76.
[1]
FOAM parallel run aborting
[1]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpiexec has exited due to process rank 1 with PID 27975 on
node Peters-MacBook-Pro.local exiting improperly. There are two reasons this could occur:
1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.
2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"
This may have caused other processes in the application to be
terminated by signals sent by mpiexec (as reported here)."
--------------------------------------------------------------------------
Prior to the solver failing, the residuals often appear to be converging nicely and invariably, the “e” residual is the one that spikes.
The same simulation, in incompressible mode will run for thousands of iterations. A bit after 3,000 iterations all residuals settle into a rhythmic, oscillatory pattern between 0.0001 and 1e-7 that repeats itself every ~ 2,200 iterations. I understand that this is not true convergence. When I apply the U vector field to all faces I am not getting any areas with unusually high velocities, and with the lowest E ratio value being ~ 0.33 and the lowest Vol ratio being ~ 0.12, I think the mesh is okay.
If relevant, for the purposes of my simulation, I do not need to consider heat transfer other than for its direct effects on the fluid flow.
What does this error message mean? Many thanks for your help.
Compressible flow needs to solve for energy
Compressible flow is tightly coupled to the energy (temperature) of the system, so it is not an option to switch off heat transfer. The compressible flow solver is less robust than the incompressible flow solver as you are seeing. Assuming your setup (mesh and boundary conditions) is viable then the main control you have is to reduce the relaxation factors - I suggest reducing 'p' (pressure) and 'e' (energy).
The first few lines of the warning indicate that the energy equation is corrupt. The references to MPI are just describing how the main process stopped.
The problem could still either be geometry or mesh related. Try setting the Substance->Solver->Iterations = 10 and then observe the progress of velocity and pressure contours just prior to the solver stopping. Look for regions of unrealistic values.
Check that your Substance->Phase->Reference->Omega (or Epsilon dependent on your turbulence model):Turbulent Length Scale->Length Scale is representative of your inlet size - especially for small areas. If you have multiple inlets with different sizes then you may need to override the reference value locally in the specific boundary condition as in the section "Inlet at the Nozzle" in the tutorial "Flow Over a CO2 Dragster".
Another option to try is to increase (by doubling) Substance->Solution->Non-Orthogonal Correctors and U Correctors.
Thank you. This was very
Thank you. This was very helpful and enabled me to solve my problem.