I queried the value of the computed surface area that was coming out of the computeParallelArea() function for an outlet BC. As I understand it, this should compute the aggregate area over all outlet boundary elements (they could be shared across multiple processors, so there is an accumulation). However, the result does not match the known geometric area for an example torch mesh.
For example, I considered the case with a cylindrical outlet of diameter=0.03m which yields an area of A=7.06858e-4 m^2
When I print the computed area for this outlet boundary with the current computeParallelArea() routine on different mesh resolutions I get the following values:
17k cells, A=0.00135
52k cells, A=0.00139
118k cells, A=0.00140
This PR revamps this computation using new methods in the BoundaryCondition class since we may want to use for more than just outlets. With this update, here are the resulting area computations:
17k cells, A=0.00067
52k cells, A=0.00069
118k cells, A=0.0007
These look to be converging to the exact value as expected with finer mesh representations.
I queried the value of the computed surface area that was coming out of the
computeParallelArea()function for an outlet BC. As I understand it, this should compute the aggregate area over all outlet boundary elements (they could be shared across multiple processors, so there is an accumulation). However, the result does not match the known geometric area for an example torch mesh.For example, I considered the case with a cylindrical outlet of diameter=0.03m which yields an area of
A=7.06858e-4 m^2When I print the computed area for this outlet boundary with the current
computeParallelArea()routine on different mesh resolutions I get the following values:This PR revamps this computation using new methods in the
BoundaryConditionclass since we may want to use for more than just outlets. With this update, here are the resulting area computations:These look to be converging to the exact value as expected with finer mesh representations.