Line Sample Skips Over Processor Region

dgreen · November 29, 2024, 07:42

Hi everyone,

I have encountered a problem with the line sampling for a case file that is decomposed using Scotch for 36 processors. The line sample works for almost all of the domain, however, it appears to skip a region associated with one of the processors.

In the image attached, the black line represents the line sample, the grey line represents the skipped section and the colouring represents the processor regions. On the right of the image, I have highlighted the lines within the output CSV file where a jump from y=0.005 to y=-2.5379 can be seen. There are no warnings or errors within the logs.

Screenshot from 2024-11-29 11-28-16.jpg

I encountered this bug for OFv2006 and found this related issue:

https://develop.openfoam.com/Develop.../-/issues/2067

Since then I have upgraded to using v2206 but I still encounter the same problem.

I am running OFv2206 compiled from source on Ubuntu 24.04.1 LTS. For this case, I am using the pimpleFoam solver. The line sampling is a uniform sample with cellPoint interpolation.

Any ideas on how to resolve this?

Thank you in advance.

dgreen · December 5, 2024, 08:15

For anyone who encounters a similar problem, this is due to the fact that the line sample runs parallel to the mesh and encounters a processor boundary that is parallel to the line. For this reason, the bHits (boundary hits) in the source code are not counted correctly.

To solve this you can switch from a uniform to a cloud sample and specify a uniform distribution of points. In this case the cloud sample will output 2 lines for each point representing the two neighbouring cell values. This will throw a warning.

Alternatively, you can displace the line by a fraction of a cell length to avoid parallel meetings. I would avoid using 1/2 cell length if you are using refinement regions.

November 29, 2024, 07:42	Line Sample Skips Over Processor Region	#1
dgreen New Member Dylan Join Date: Apr 2024 Posts: 2 Rep Power: 0	Hi everyone, I have encountered a problem with the line sampling for a case file that is decomposed using Scotch for 36 processors. The line sample works for almost all of the domain, however, it appears to skip a region associated with one of the processors. In the image attached, the black line represents the line sample, the grey line represents the skipped section and the colouring represents the processor regions. On the right of the image, I have highlighted the lines within the output CSV file where a jump from y=0.005 to y=-2.5379 can be seen. There are no warnings or errors within the logs. Screenshot from 2024-11-29 11-28-16.jpg I encountered this bug for OFv2006 and found this related issue: https://develop.openfoam.com/Develop.../-/issues/2067 Since then I have upgraded to using v2206 but I still encounter the same problem. I am running OFv2206 compiled from source on Ubuntu 24.04.1 LTS. For this case, I am using the pimpleFoam solver. The line sampling is a uniform sample with cellPoint interpolation. Any ideas on how to resolve this? Thank you in advance.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Gmsh] Structured meshing in Gmsh	the_phew	OpenFOAM Meshing & Mesh Conversion	19	August 24, 2022 04:19
[Gmsh] 3D Mesh conversion from gmsh-2.5.0 to OpenFOAM	Ancioi	OpenFOAM Meshing & Mesh Conversion	17	January 9, 2019 00:50
Derivative of velocity and mean velocity	hiuluom	OpenFOAM Post-Processing	1	May 30, 2015 00:42
OpenFOAM 1.7.1 installation problem on OpenSUSE 11.3	flakid	OpenFOAM Installation	16	December 28, 2010 09:48
Problems of Duns Codes!	Martin J	Main CFD Forum	8	August 15, 2003 00:19

December 5, 2024, 08:15		#2
dgreen New Member Dylan Join Date: Apr 2024 Posts: 2 Rep Power: 0	For anyone who encounters a similar problem, this is due to the fact that the line sample runs parallel to the mesh and encounters a processor boundary that is parallel to the line. For this reason, the bHits (boundary hits) in the source code are not counted correctly. To solve this you can switch from a uniform to a cloud sample and specify a uniform distribution of points. In this case the cloud sample will output 2 lines for each point representing the two neighbouring cell values. This will throw a warning. Alternatively, you can displace the line by a fraction of a cell length to avoid parallel meetings. I would avoid using 1/2 cell length if you are using refinement regions.