View Issue Details

IDProjectCategoryView StatusLast Update
0001147OpenFOAMBugpublic2018-10-03 09:19
Reporteruser672Assigned Towill  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSScientific LinuxOS Version6.4
Fixed in Versiondev 
Summary0001147: Sample utility: line passing through internal cyclic boundary using midPoint set sampling definition isn't possible
DescriptionNo error happens if "face" set sampling definition is chosen. Same error for either a sampling functionObject, or using the postProcessing sample utility.
Steps To ReproduceIn the attached minimal case I've set up a square baffle in the centre of a channel of square cross-section, and a sampling functionObject to output the velocity along two axial lines; one going through the baffle and one running past it. The line running through the baffle fails if midPoint is used.
Additional InformationSame behaviour observed for both GCC-4.6 and Clang-4.3 builds.
Tagsbaffle, sample

Activities

user672

2014-02-01 19:47

 

sampleCyclic.tgz (3,373 bytes)

wyldckat

2015-03-29 21:29

updater  

bug1147.patch (12,741 bytes)   

wyldckat

2015-03-29 21:53

updater   ~0004549

@wallace: Many thanks for the simple and quick test case! It's really just a matter of following your instructions!


@Henry: Attached is the file "bug1147.patch", which one crazy hack of a patch. Seriously consider it only a proof of concept, because I couldn't code anything barely more elegant than that in a short time.
And sorry, but I left in a few stray debug lines, to assess if things were working as intended.

The explanation for the reported bug is simple: the method "particle::trackToFace()" always teleports the tracking point to the other side of the cyclic baffle, which after going through the all of the correct steps, it results in "midPointSet::genSamples()" crashing midway of "sampledSet::getCell()", because the second face is always on the other side of the cyclic patch pair, due to the teleport.


Hopefully the following step-by-step makes it a bit clearer, with the details on how to the provided patch tries to overcome this problem:

  1- The story begins in "faceOnlySet::trackToBoundary()", which is where the collection of faces crossed by the tracking line is gathered. The hack here was to use the new option to properly handle teleporting, where:

    a- In the first hit, it stores the first face before teleport, along with a flag indicating that a teleport needs to be performed.

    b- In the second hit, it executes the teleport, stores the face from the other side and resets the flags related to the need for handling a teleport.

    c- The tricky part is how "faceOnlySet::trackToBoundary()" and "particle::trackToFace()" handle the teleportation. This is because in "particle::trackToFace()" it has to postpone the jump to the second pass, which is why it has to rely so heavily on the flag "markedToTeleport_".

  2- Later on, in "midPointSet::genSamples()" we have to handle the new scenario of "cell1" or "cell2" being -1, which occurs when it's a situation of having the two faces be related to the same special pair of patches.

  3- In "sampledSet::getCell()", when it's not an internal face and if it fails to find the cell the point belongs to, then double-check if the "faceI" is part of one of the special patches that do particle teleportation... which if true, then return "-1".

henry

2015-03-29 22:03

manager   ~0004550

This is a lot of change for this particular purpose. I am also not happy about the increase in storage for ALL particle/parcel types even though it is only needed for this particular post-processing use. Actually this is a general problem with the Lagrangian library that all data which might be possibly used for any application/model is stored even if it is not needed for the particular case. My feeling is that we need more levels in the class hierachy to handle all the options, i.e. in this case we need a derived variant of particle which stores and handles the "teleportation" data appropriately. I think this will need to be delayed until we start writing the new robust tracking algorithm which handles bad cell which decompose with negative volume pyramids.

MattijsJ

2018-09-28 11:29

reporter   ~0010076

Attached fixes the hanging in getting the boundary intersections (meshSearch.[CH]). It removes any geometric offset but instead makes sure it only checks a face once.

Thanks Will for the testcase and analysis.
meshSearch.C (20,510 bytes)   
meshSearch.H (8,416 bytes)   

will

2018-10-03 09:19

manager   ~0010081

Thanks for the fix, @MattijsJ. It needed a bit of modification, as marking all visited faces meant some similarly located hits (like the ones on the cyclics in the test case) were being missed. I changed it to consider only successfully hit faces. There's also an extra step in there to discount point-connected faces that the line projects through in the same direction. This gets rid of the duplicates when the line hits an edge or point.

This fix is now in dev as of 39ad49bc. This change, along with various modifications to Lagrangian since this bug was reported, I think this is now fixed.

Issue History

Date Modified Username Field Change
2014-02-01 19:47 user672 New Issue
2014-02-01 19:47 user672 File Added: sampleCyclic.tgz
2014-02-05 00:03 user672 Tag Attached: Added the used Allrun script
2014-02-05 00:03 user672 Tag Attached: baffle
2014-02-05 00:03 user672 Tag Attached: functionObject
2014-02-05 00:03 user672 Tag Attached: sample
2014-02-05 00:03 user672 Tag Detached: functionObject
2015-03-29 21:29 wyldckat File Added: bug1147.patch
2015-03-29 21:53 wyldckat Note Added: 0004549
2015-03-29 22:03 henry Note Added: 0004550
2018-07-10 11:16 administrator Tag Detached: Added the used Allrun script
2018-09-28 11:29 MattijsJ File Added: meshSearch.C
2018-09-28 11:29 MattijsJ File Added: meshSearch.H
2018-09-28 11:29 MattijsJ Note Added: 0010076
2018-10-03 09:19 will Assigned To => will
2018-10-03 09:19 will Status new => resolved
2018-10-03 09:19 will Resolution open => fixed
2018-10-03 09:19 will Fixed in Version => dev
2018-10-03 09:19 will Note Added: 0010081