[nimasam]

Hello foamer

please look at the attached file, this file solves a flow over plate by simpleFoam solver in OF-2.2.0, instead of farfield condition, it uses empty BC. I expected it crashes, but it works fine, so whats farfield BC for p,U, and so on? how they can be calculated when we assign it an empty patch?


Best Regards

[ngj]

Good evening,

That is very strange. I quickly tried the case on a couple of versions of OpenFoam, and the report is as follows:

- OF2.2.1: The attached simulation runs.
- OF2.2.0: The attached simulation runs.
- OF2.1.0: The attached simulation runs.
- OF1.7.1: The attached simulation fails.
- OF1.6-ext: The attached simulation fails.

Looking at the data, where is actually a non-zero velocity normal to the farfield boundary, so how does an empty boundary condition behave?

This must be a bug in the mesh check prior during runTime. It is on the other hand interesting that only in OF2.1.0 and OF2.2.* does checkMesh complain over the mismatch between number of empty faces and the number of cells. This is not part of the response in neither OF1.7.1 nor OF1.6-ext.

Kind regards

Niels

[hg2lf]

Originally Posted by nimasam

Hello foamer

please look at the attached file, this file solves a flow over plate by simpleFoam solver in OF-2.2.0, instead of farfield condition, it uses empty BC. I expected it crashes, but it works fine, so whats farfield BC for p,U, and so on? how they can be calculated when we assign it an empty patch?

Have you solved this problem? I faced the problem of how to set far field boundary as well.

[nimasam]

as Niels mentioned it seems it is a bug in OpenFOAM

[wyldckat]

Greetings to all!

Thanks to the OpenFOAM-combo repo I created sometime ago ( https://github.com/wyldckat/OpenFOAM-combo/ ), I managed to see what happened in this case.

As of OpenFOAM 2.0.0, they decided to comment out this check, which was made only when the respective debug flag was active. In the latest code at 2.3.x, have a look into the method "updateCoeffs()": https://github.com/OpenFOAM/OpenFOAM...chField.C#L139 - it has this comment there:

    //- Check moved to checkMesh. Test here breaks down if multiple empty
    //  patches.

Now, the big question is whether this can be considered a bug or not. There are a few details to take into account:

1. The "empty" BC should conceptually act as a "symmetry" BC. Problem is that it is not coded to act as one, since the objective is to report that there are no faces on the respective patch.
2. OpenFOAM usually does not stop us at the beginning of running a solver, just because the mesh has got imperfections. At most, it complains if something is missing or otherwise it will crash due to the incorrect detail.
3. The description for the "empty" BC states: https://github.com/OpenFOAM/OpenFOAM...tchField.H#L31
   

   This boundary condition provides an 'empty' condition for reduced
   dimensions cases, i.e. 1- and 2-D geometries. Apply this condition to
   patches whose normal is aligned to geometric directions that do not
   constitue solution directions.

Therefore, according to point #2, the user is always responsible for first diagnose the sanity of the mesh. And according to #3, this can be considered a feature, namely the ability to not calculate in certain "solution directions" .

Best regards,
Bruno