Questions about myLusgsFoam solver for simulating low Mach number flow

[lpz456]

Hi professor Furstj, I'm curious about the applicability of myLusgsFoam solver to simulate low-speed flow (almost incompressible).

The troubles are as follows:

Previously, simpleFoam solver was used to solve the low Mach compressor cascade, where the Mach number in the inlet was about 0.067. Using SST turbulence model, the results show perfect convergence. ​Nowadays, I would like to simulate the same case with myLusgsFoam solver with the following boundary conditions: inlet: fixed value for velocity and temprature, zero gradient for pressure; outlet: fixed value for pressure, zero gradient for velocity and temprature.

I found that the results simulated by myLusgsFoam solver is more sensitive to the initial field than the rhoSimpleFoam solver.

1) When uniform initialization is used, the pressure field fails to converge for the myLusgsFoam solver, while it converges well for the rhoSimpleFoam solver. 2) Using the results of the simpleFoam solver for initialization, the pressure dimension is modified and the exit back pressure is adjusted. The results also fail to converge for the myLusgsFoam solver, where the pressure field in the channel appears to oscillate back and forth.
3) The flow field is stabilized only with the initialisation of the results computed by the simpleFoam solver. However, the residuals still fail to converge properly, with the 'rhoE' residual fluctuating around 10.

[lpz456]

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!

[lpz456]

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.

[lpz456]

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.

[furstj]

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...

[lpz456]

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！