viewFactor cannot deal with complex geometry (#1794) · Issues · Development / openfoam

viewFactor cannot deal with complex geometry

Summary

Steps to reproduce

Example case

What is the current bug behaviour?

What is the expected correct behavior?

Relevant logs and/or images

Environment information

OpenFOAM version :
Operating system :
Hardware info :
Compiler :

Possible fixes

/label bug Environment information OpenFOAM version : v1912 Operating system : Ubuntu 18.04 Compiler : gcc v7.4.0

Summary : The radiation model viewFactor seems to be unsuitable for complex geometry and fine mesh. Regarding the complexity of the geometry, I have attached a case with a tore and a cylinder in its centre. halftore_cylinder.zip

Because it is not a simple cube, the parameters nFacesInCoarsestLevel and maxDynListLength needs to be highly increased. For instance in the case I have attached, to run properly the tools faceAgglomerate and viewFactorsGen for this geometry, I need to increase maxDynListLength to 15 Millions (default value is 100 000) and nFacesInCoarsestLevel to 8000 for one of the two patch (this value varies from 10 to 40 in the tutorials).

Finally when I ran the solver (chtMultiRegionSimpleFoam), when the solver initialised the factor matrices, it crashes with the error : terminate called after throwing an instance of 'std::bad_array_new_length' what(): std::bad_array_new_length

The full error message is in the file logFiles/log.chtMultiRegionSimpleFoam. So it seems that an hard-coded value in the code is exceeded regarding the view factor matrices length (F in processor*/Air/F).

Possible fixes: When you look at the distribution for the view factor matrices through each processors, it is unequal where some processor are 0 matrix and others with a huge matrix length. So maybe a smoother distribution through each processor can be achieved to solve this problem ? Or the hard-coded value can be increased ? But this solution can cause others troubles

Steps to reproduce : Please run the bash script Allrun-parallel with the provided configuration. The case runs with 12 cores. It must be crash when the solver runs. Please run with 12 cores as the viewFactor model is extremely sensitive to the number of cores used, the meshing size, ...

<!--
  *** Please read this first! ***

Before opening a new issue, make sure to search for keywords in the issues
  filtered by the "bug" label and check to see if it has already been reported

You can see how your report will be rendered on the platform by using the
  "preview" tab above
-->

### Summary

### Steps to reproduce

### Example case

<!--
  If possible, please create a SMALL example and attach it to your report

If you are using an older version of OpenFOAM this will also determine
  whether the bug has been fixed in a more recent version
-->

### What is the current *bug* behaviour?

### What is the expected *correct* behavior?

### Relevant logs and/or images

### Environment information

- OpenFOAM version :
- Operating system :
- Hardware info    :
- Compiler         :

### Possible fixes

<!--
  If you can, link to the line of code that might be responsible for the
  problem

The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
  issue
-->

/label ~bug
Environment information
OpenFOAM version : v1912
Operating system : Ubuntu 18.04
Compiler         : gcc v7.4.0

Summary : The radiation model viewFactor seems to be unsuitable for complex geometry and fine mesh. 
Regarding the complexity of the geometry, I have attached a case with a tore and a cylinder in its centre.
[halftore_cylinder.zip](/uploads/d14b12bb79035922e086123829d92754/halftore_cylinder.zip)

Because it is not a simple cube, the parameters nFacesInCoarsestLevel and maxDynListLength needs to be highly increased. 
For instance in the case I have attached, to run properly the tools faceAgglomerate and viewFactorsGen for this geometry, I need to increase maxDynListLength to 15 Millions (default value is 100 000) and nFacesInCoarsestLevel to 8000 for one of the two patch (this value varies from 10 to 40 in the tutorials).

Finally when I ran the solver (chtMultiRegionSimpleFoam), when the solver initialised the factor matrices, it crashes with the error :
`terminate called after throwing an instance of 'std::bad_array_new_length'
  what():  std::bad_array_new_length`

Possible fixes: 
When you look at the distribution for the view factor matrices through each processors, it is unequal where some processor are 0 matrix and others with a huge matrix length. 
So maybe a smoother distribution through each processor can be achieved to solve this problem ?
Or the hard-coded value can be increased ? But this solution can cause others troubles

Steps to reproduce : Please run the bash script Allrun-parallel with the provided configuration. 
                     The case runs with 12 cores. It must be crash when the solver runs.
                     Please run with 12 cores as the viewFactor model is extremely sensitive to the number of cores used, the meshing 
                     size, ...

Discussion
Designs

The one place for your designs

To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.