View Issue Details

IDProjectCategoryView StatusLast Update
0002369OpenFOAMBugpublic2018-07-10 11:23
Reporterrrossi Assigned Towyldckat  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
PlatformGNU/LinuxOSCentosOS Version7 64bit
Summary0002369: faceSource.C gives wrong total area of cyclic patch
DescriptionI'm dealing with a straight pipe where I need to compute the surface area of cyclic patch at runtime.

When using faceSource from functionObjects, the reported total area of the cyclic patch is correct in serial execution whereas the reported value is wrong and changes with the number of partitions in parallel mode.

After some initial testing, it looks to me that the bug appears only when "processorCyclic" patch types are created during domain decomposition, whereas the total area is correct when partition interfaces do not run across the cyclic patches.
Tagscyclic, faceSource, processoCyclic

Activities

wyldckat

2016-12-03 20:13

updater   ~0007390

I stumbled upon this situation some months ago and then realized/remembered that the currently implemented workaround for that issue is to use the "preservePatches" constraint in "decomposeParDict".

For more details, see the full detailed dictionary file: https://github.com/OpenFOAM/OpenFOAM-4.x/blob/master/applications/utilities/parallelProcessing/decomposePar/decomposeParDict

For example for your case:

  // Optional decomposition constraints
  constraints
  {
    preservePatches
    {
        //- Keep owner and neighbour on same processor for faces in patches
        // (only makes sense for cyclic patches. Not suitable for e.g.
        // cyclicAMI since these are not coupled on the patch level. Use
        // singleProcessorFaceSets for those)
        type preservePatches;
        patches (sectionSideA sectionSideB);
    }
  }

where "sectionSideA" and "sectionSideB" are the hypothetical names of each side of your cyclic patch-pair.


As for not having to specify this manually, I believe this is one of those situations where automatic constraints may not work as desired sometimes. For example, if you had several cyclic patches and only a couple of them are meant to be monitored, then the automatic constraints for all cyclics could potentially lead to a suboptimal decomposition.


Either way, please let us know if the constraints feature is working as intended for your case or not.

wyldckat

2016-12-09 01:52

updater   ~0007440

I'm closing this report as "no change required".

@rrossi: If the 'preservePatches' constraint doesn't work for your case, please re-open this report.

rrossi

2016-12-28 15:13

reporter   ~0007562

I'm reopening the ticket to confirm the suggested workaround works for my case.

I also wanted to report the same issue was affecting the use of "gSum" when computing the mass flow rate (and any other type of calculation I guess) through the cyclic patches within a coded library.

Using the "reduce" function, the computed mass flow rate is correct and matches the output from serial execution.

Hope this will be useful for the community.

wyldckat

2016-12-28 15:28

updater   ~0007563

Many thanks for the feedback, although I'm a bit confused by your description about "gSum" vs "reduce".

From your description, it seems that 'preservePatches' must also be used for calculating the mass-flow rate in a cyclic patch, when the calculation is done using a coded library, so I'm guessing that you used the '#codeStream' feature?

But... if you used the 'preservePatches' feature, you don't need to use 'gSum' for a specific patch, because that patch is all in the same processor sub-domains...

Hold on, do you mean to say that you're adding the mass-flow from several patches, where each patch may be in different processor sub-domains? If this is the case, then yes, you need to use one of the reduction operators, not 'gSum'.

MattijsJ

2016-12-29 20:31

reporter   ~0007573

Bit of background: when owner and neighbour cell of cyclic faces get on to different processors the decomposer will automatically introduce processorCyclic patches to hold the faces (similar to processorPatches being created for internal faces). So if you want the flow through these patches as well you have to include them in your specification for faceSource)

rrossi

2016-12-30 08:48

reporter   ~0007574

Sorry, I should have give a bit of background too to the whole issue.

The reason why I ended up realizing "faceSource" was giving the wrong count of the patch total area was in fact while trying to compile a library (from scratch, not using the #codeStream feature").

In such library, I needed to compute the mass flow rate through the cyclic patch (the geometry is a straight pipe, so only one cyclic pair is present) I've tried to use "gSum" at first.

When running the code, the reported mass flow rate was always much smaller than the expected result so I tried to simply use whatever "functionObject" to double check was the function was doing.

I then realized "faceSource" was also giving the wrong result in terms of total surface area and after performing some tests in serial and parallel execution I've found out the issue with "processorCyclic" patch types.

While waiting for replies to the ticket and knowing the possibility to use the "reduce" function in place of "gSum", I've managed to solve the issue in the library.

I don't have on hand all the tests/code I've used back then anymore but I can try to recover the essential steps in case they will be of help to better understand the issue and/or improve the code.

wyldckat

2017-01-01 18:35

updater   ~0007578

@rrossi: Many thanks for the detailed feedback! Then what you're describing is what was expected that OpenFOAM is meant to do in this scenario, as detailed by @MattijsJ.

Since there isn't any change required in OpenFOAM's source code, I'm closing this issue again as "no change required."

Issue History

Date Modified Username Field Change
2016-12-03 10:16 rrossi New Issue
2016-12-03 10:16 rrossi Tag Attached: cyclic
2016-12-03 10:16 rrossi Tag Attached: faceSource
2016-12-03 10:16 rrossi Tag Attached: processoCyclic
2016-12-03 10:16 rrossi Tag Attached: total area
2016-12-03 20:13 wyldckat Note Added: 0007390
2016-12-03 20:13 wyldckat Priority urgent => normal
2016-12-09 01:52 wyldckat Assigned To => wyldckat
2016-12-09 01:52 wyldckat Status new => closed
2016-12-09 01:52 wyldckat Resolution open => no change required
2016-12-09 01:52 wyldckat Note Added: 0007440
2016-12-28 15:13 rrossi Status closed => feedback
2016-12-28 15:13 rrossi Resolution no change required => reopened
2016-12-28 15:13 rrossi Note Added: 0007562
2016-12-28 15:28 wyldckat Note Added: 0007563
2016-12-29 20:31 MattijsJ Note Added: 0007573
2016-12-30 08:48 rrossi Note Added: 0007574
2016-12-30 08:48 rrossi Status feedback => assigned
2017-01-01 18:35 wyldckat Note Added: 0007578
2017-01-01 18:35 wyldckat Status assigned => closed
2017-01-01 18:35 wyldckat Resolution reopened => no change required
2018-07-10 11:23 administrator Tag Detached: total area