Questions about myLusgsFoam solver for simulating low Mach number flow about myfoam HOT 5 OPEN

Hi,

concerning low Mach flows: the myLusgsFoam does not contain low Mach preconditioning. Therefore, rhoSimpleFoam will be much more efficient ii that case (let say for Ma<0.3). The myLusgsFoam is sutable for transonic or high subsonic flows!

The simpleFoam uses completely different formulation. It solves N-S equations for incompressible flows with constant density. The pressure is therefore in m2/s2 and not in Pascals! Moreover, it is legal for simpleFoam to have p=0 (which is not the case for myLusgsFoam)

The myLusgsFoam is not compatible with pressureInletVelocity or pressureDirectedInletVelocity. Look at the source code of these conditions and you will probably found the reason :). Therefore, the correct combination of inlet BC is ether totalPressure+totalTemerature+subsonicInletTotal, or flowRateInletVelocity+totalTemperature+zeroGradient for p.

Concerning the bug with inletDirection and rho: I will check it...

from myfoam.

Questions I had:

1. Whether this is due to a mismatch between the fixed-value velocity import boundary condition and the density-based coupled solver, I will next try the effect of mass flow inlet boundary, namely flowRateDirectletVelocity as you provide.

2. ​Similar problems have been encountered with the total temperature and pressure inlet boundaries, where the flow field always diverges when OpenFOAM's built-in pressureDirectedInletOutletVelocity replaces the subSonicInletTotal boundary as professor provides.

In my case, the inlet velocity profile is given based on experimental measurements, and the back pressure is specified. ​I would like to know whether the myLusgsFoam solver can also be used to handle cases with such boundary conditions.

Thanks for professor!

from myfoam.

Hi Prof.,
Trying to adopt the flowRateDirectedInletVelocity inlet boundary instead of the fixedValue, the convergence of the results is improved obviously, and some inspiration is achieved:
the inlet boundary for density-based solver is best to explicitly contain the constraints of density information, which seems to contribute to computational stability. I should learn about the implementation of boundary conditions in OpenFOAM.

Also I found a bug:

Using OpenFOAMv2106 and flowRateDirectedInletVelocity boundaries, a uniform velocity direction is specified in the initial field. In the subsequently updated velocity field, the inlet velocity direction, namely "inletDirection" term, becomes a non-uniform vector field, and the information of the "rho" item is also lost, which may affect the convergence of the calculation to some extent.

Later, I will upload a low Mach 2D test case for reference.

from myfoam.

Hi Prof.,
I have solved the problem of flowRateDirectedInletVelocity boundary condition mentioned above. The modified boundary has been uploaded to my repositories. :)

Unfortunately, the convergence of the test case has not been further improved.

from myfoam.

Thanks for prof's reply！

Previously, the commercial software Fluent or Numeca was commonly used, but without much concern about boundary condition settings. I think it's necessary to learn about them in the future.

Thanks again！

from myfoam.