View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001240OpenFOAMBugpublic2014-03-27 09:292015-08-17 01:16
Reporteruser841Assigned Touser21 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
PlatformLinuxOSOpenSuseOS Version11.1
Summary0001240: ViewFactorsGen crashes in parallel (might be a bug or wrong usage)
DescriptionTo exclude certain patches from the viewfactor calculation, I set the boundary condition in Qr file to "calculated". This might not be the correct way to do this. There might be a different and more suitable boundary condition to exclude patches from the calculation. If there is, just give me a short information and close this bug report.

Otherwise, if "calculated" is used, the error given in the correspondend file in the attached testcase is produced by viewFactorsGen.

As far as I could investigate this matter, the reason might be the following:

In "searchingEngine.H" the labelList triSurfaceToAgglom is initialized with size 5*nFineFaces. During the later calculations, this list can get larger than the initial size and calling
-> triSurfaceToAgglom.resize(localTriFaceI-1);
in function "triangulate(...)" in "viewFactorsGen.C" will produce the error.

nFineFaces is only the sum of the number of faces from patches, that are of type "fixedValue" and have a size greater 0. Code part in "viewfactorsfGen.C" is:

349 label count = 0;
350 forAll(Qrb, patchI)
351 {
352 const polyPatch& pp = patches[patchI];
353 const fvPatchScalarField& QrpI = Qrb[patchI];
354
355 if ((isA<fixedValueFvPatchScalarField>(QrpI)) && (pp.size() > 0))
356 {
357 viewFactorsPatches[count] = QrpI.patch().index();
358 nCoarseFaces += coarsePatches[patchI].size();
359 nFineFaces += patches[patchI].size();
360 count ++;
361 }
362 }

Patches with "calculated" are excluded here, which is correct for the viewFactor calculation, but this patches are still needed for the triangulation of the mesh. To solve this I introduced a further "label totalnFineFaces", which I later used to initialize "triSurfaceToAgglom(2*totalNfineFaces)". And I extended the if-block above as follows:


356 if ((isA<fixedValueFvPatchScalarField>(QrpI)) && (pp.size() > 0))
357 {
358 viewFactorsPatches[count] = QrpI.patch().index();
359 nCoarseFaces += coarsePatches[patchI].size();
360 nFineFaces += patches[patchI].size();
361 totalNFineFaces += patches[patchI].size();
362 count ++;
363 }
364 else if(!pp.coupled())
365 {
366 totalNFineFaces += patches[patchI].size();
367 }


After introducing this changes, viewFactorsGen will run a little further and crash when the maxDynListLength in shootRays.H is exceeded. But that is a different problem I guess.
Steps To ReproduceRun viewFactorsGen on the given test case:

blockMesh
decomposePar -force -cellDist -copyUniform -latestTime -noFunctionObjects
mpirun -np 2 faceAgglomerate -parallel
mpirun -np 2 viewFactorsGen -parallel > log.vFGen
TagsNo tags attached.

Activities

user841

2014-03-27 09:29

 

TestCaseViewFactorGen.tar (112,640 bytes)

user21

2014-03-27 09:45

  ~0002979

It should exclude the patch from the view factor calculation if it is not listed in the viewFactorDict

user841

2014-03-27 16:00

  ~0002982

Hallo Sergio,

thanks for your reply. Removing surround from the viewFactorsDict, does not seem to have the effect I try to achieve.

I tested your suggestion with the following set up and results:
-removed Surround from viewFactorsDict, set it to greyDiffusive... in 0/Qr

-decomposePar ->ok
-faceAgglom ->runs perfectly. Surround is not agglomerated anymore.
-viewFactorsGen-> still seems to include the patch Surround. The output
"total number of coarse faces" is 13260. Which is the sum of the faces from SURROUND plus the number of the agglomerated faces. Proc[1] still seems to include the SURROUND patch.

Actually I got the idea to set the patch to calculated from this description in the viewFactorsGen.C file:

The patches involved in the view factor calculation are taken from the Qr volScalarField (radiative flux) when is greyDiffusiveRadiationViewFactor otherwise they are not included.


So what step do I miss? I want to achieve that only WALLS,OUTLET,INLET patches are included in the calculation for the viewfactors.

Thanks for your efforts.

Fabian

user21

2014-03-28 10:06

  ~0002984

Hi,
I tested the case you sent. I think you have run out memory as the case is quiet
large. You are right "calculated" on a patch on Qr avoids the calculation of the view
factors on that patch. The sizing on the array for the triangulated surface works fine for me. You might need to resize the "const label maxDynListLength = 100000"; in line
6 in shootRays. I reduced the agglomeration of the OUTLET as nFacesInCoarsestLevel 100 and the view factor were correctly calculated.

Thanks

user841

2014-04-01 12:56

  ~0002992

Hi,

I am aware of the maxDynListhLength problem and already solved it by increasing the number. If you cannot reproduce the triangulation problem, I might have run out of memory as you suggested.

So for now, I think the report can be closed.

If the error appears again, during my further work I might come back to this report.

Thank you

Issue History

Date Modified Username Field Change
2014-03-27 09:29 user841 New Issue
2014-03-27 09:29 user841 File Added: TestCaseViewFactorGen.tar
2014-03-27 09:45 user21 Note Added: 0002979
2014-03-27 16:00 user841 Note Added: 0002982
2014-03-28 10:06 user21 Note Added: 0002984
2014-04-01 12:56 user841 Note Added: 0002992
2015-08-17 01:16 wyldckat Status new => closed
2015-08-17 01:16 wyldckat Assigned To => user21
2015-08-17 01:16 wyldckat Resolution open => no change required