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

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, ...

The current VF implementation suffers of some shortcomings regarding the solution of the linear system of Eq, VF method and agglomeration algorithm that might need to be reviewed/updated. This is a considerable effort which needs funds to be carried out

changed the description

added bug label

added feature request label

closing due to the lack of available internal/external funding.

closed

I used the same solver, it works for complex geometries, the problem is in the discretization of the view factor formula. In the discretized integral if the distance between two faces gets small the view factor can easily overshoot 1 by a lot, which trips the solver because it changes the matrix coefficients of the linear system to inconsistent values. To overcome such a problem you need to counterbalance with the face dimensions, that is mesh resolution and nFacesInCoarestLevel. But it is sufficient to refine the mesh and view factor faces only in that region.

For a more accurate explanation, I leave this paper https://doi.org/10.2514/1.T6165