|
|
ascii1.png (29,918 bytes) ascii2.png (26,828 bytes) binary1.png (29,982 bytes) binary2.png (27,021 bytes) |
|
|
I ran the casebug case with ascii and binary output in OpenFOAM-dev and see no difference in the results, do you have an OpenFOAM-dev installation you can try? Looking at your files it appears that there is an inconsistency in your installation, it says that it is version 7 of ESI's fork of OpenFOAM, but they do not release their fork using the official numbering of the OpenFOAM Foundation. |
|
|
Hi, The case setup is for version 7 of openfoam.org. I will install the dev version and check. jg |
|
|
The file headers are inconsistent: | \\ / O peration | Version: 7 | | \\ / A nd | Web: www.OpenFOAM.com | indicating that the version in 7 but of ESI's fork of OpenFOAM, but ESI have not released a version 7. |
|
|
Putting aside the issue of the header. I ran the case using OF7, OFDEV and OF1912. And in all version I got those artifacts in the binary output. |
|
|
The header issue indicates that there is something inconsistent with your installation. I am able to reproduce the problem in OpenFOAM-7 but not in OpenFOAM-dev, in fact if I run the OpenFOAM-dev postProcess on the OpenFOAM-7 results I also do not see the artifacts. Maybe your OpenFOAM-dev installation is rather old or also inconsistent. |
|
|
Hi, I am updating the installation. In any-case, I updated the header and the problem still is present in OF7 and OF1912. |
|
|
OF1912 is a fork of OpenFOAM produced by ESI, we take no responsibility for it and ESI choose not to contribute to OpenFOAM development, see https://openfoam.org/dev/contributors/ |
|
|
I still see the artifacts in the dev version. Though they are different from version 7, which is even weirder (see attached figure). I am using this branch: 3659fb478b8517081f53deafdee7c4a3619bc152 I also updated the headers so they are consistent with the OF version. Annotation 2020-03-09 172712.png (149,632 bytes) |
|
|
I am still unable to reproduce the problem in OpenFOAM-dev, I have attached the results from the binary run. |
|
|
|
|
|
I can reproduce this with latest dev, but only when running parallel. Serial works without issues. binary_bug.png (27,261 bytes) |
|
|
I did some further tests and I can also reproduce it with ASCII if I increase the precision to 18. The problem seems to be related to parallel sampling, because reconstructing and then postProcessing works. It seems that if the mesh is decomposed with binary or high precision ASCII and then sampled in parallel, the location of the sampling points will be slightly different than in serial with some near duplicate points. The output depends on the decomposition type and number of processors, so probably something to do with how the sampling line and processor domains are aligned. Here are sampled points with just decomposing 0-time and running postProcess in serial and parallel. serial_0.png (17,007 bytes) parallel_0.png (17,155 bytes) |
|
|
One further comment: the sampling line is exactly aligned with the mesh grid and is in between two cell rows (there is even number of cells). This means there is 50/50 odds for each cell pair which cell the sampling should pick. Any slight perturbation might mean that the line cuts through different rows of cells and thus produces jitter. sampling_line.png (97,735 bytes) |
|
|
User error. If you sample exactly along a line of cell faces using interpolationScheme cell; the result is not well defined as it is not clear which cell on either side of the faces should be sampled. You should either use interpolationScheme cellPoint; or another interpolating method which will provide a consistent interpolation to the sampling points. Alternatively set the line such that it passes through the cells rather than along cell faces. |
- Anonymous
