Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
openfoam
openfoam
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 331
    • Issues 331
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 6
    • Merge Requests 6
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • Development
  • openfoamopenfoam
  • Issues
  • #1794

Closed
Open
Opened Jul 31, 2020 by Guillaume SELVAME@Guillaume_

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

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: Development/openfoam#1794