View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002369 | OpenFOAM | Bug | public | 2016-12-03 10:16 | 2018-07-10 11:23 |
Reporter | rrossi | Assigned To | wyldckat | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | GNU/Linux | OS | Centos | OS Version | 7 64bit |
Summary | 0002369: faceSource.C gives wrong total area of cyclic patch | ||||
Description | I'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. | ||||
Tags | cyclic, faceSource, processoCyclic | ||||
|
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. |
|
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. |
|
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. |
|
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'. |
|
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) |
|
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. |
|
@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." |
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 |