2018-07-16 17:14 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002759OpenFOAM[All Projects] Bugpublic2018-01-04 09:17
Reporterjaydeep 
Assigned Towill 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionnot fixable 
Product Versiondev 
Target VersionFixed in Version 
Summary0002759: fvDOM with wedge patch gives inaccurate heat flux calculation
DescriptionI tried a validation problem with fvDOM on axisymmetric case. The example case is attached.

Radiative analytical heat flux from "hot" wall comes out to 260.9 kW/m2.

Axisymmetric test case under-predicts the heat flux (15% error) (wedge patch).

I tried alternate approach with symmetry patches and semi-circular model with extrusion model "sector" instead of "wedge". With this approach I get values closer to analytical (about 2% error).

This problem exacerbates with higher model complexity. For more complex problems I'm observing this deviation > 25%.

I am not sure what could be a fix but I suspect the solution might lie in how fvDOM deals with wedge patches:
fvDOM uses strategy based on nSolutionD as,
if (nSolutionD == 2) ...
if (nSolutionD == 3) ...

from polyMesh::nsolutionD, for wedge type geometry, nSolutionD is returned as 3. Hence the radiation problem is treated as 3D - requiring both nTheta and nPhi in fvDOM. As a ramification of this - solver crashes if you set nTheta =0. The wedge patch does not participate in radiation, yet, fvDOM solves for transport across them since nTheta !=0; leading to loss of rays??

Hence, in the validation case attached, there could be some ray loss? I am not sure if I am putting it in right words.
Steps To Reproduce./Allrun
TagschtMultiRegionSimpleFoam, fvDOM, Heat transfer, radiation
Attached Files
  • zip file icon case.zip (12,745 bytes) 2017-11-14 22:06

-Relationships
+Relationships

-Notes

~0009196

will (manager)

The result you are getting is close to the analytic solution for infinite flat plates. The error, as you calculate it will be small when the cylinders are close to the same size, and will tend to 100% as the inner cylinder becomes small.

The missing behaviour is a transformation of the ray variable across the coupled patches; i.e., when a ray leaves one side, it enters again from the other side, with it's direction modified to account for the transformation between the patches.

With fvDOM, this would mean coupling between the variables that represent the different ray directions. There are a number of problems with this. The first is that there is really no structure for this sort of coupling. Something would have to be implemented. The level of coupling is also very high. A ray may cross the mesh many times, particularly if the wedge angle is small, changing variable each time. Explicit treatment of this coupling would therefore be extremely slow to converge. Lastly, the number of fvDOM directions required would probably be prohibitively high. The discretisation of the radiative directions would need be done so that there is a variable available to couple to. For a 2-degree mesh, that means 2-degree increments. It's possible that an interpolation procedure between the directions could be devised to lessen the cost and matching requirements, but that would further complicate the coupling implementation and would only get you so far before accuracy suffered.

As a result of these issues, it has been concluded that fvDOM isn't feasible on wedge meshes (or cyclics for that matter). Even if the necessary coupling could be implemented, the cost of running (i.e., the number of variables) would scale inversely with the wedge angle, to the point that there may be no advantage over the full 3D case.
+Notes

-Issue History
Date Modified Username Field Change
2017-11-14 22:06 jaydeep New Issue
2017-11-14 22:06 jaydeep File Added: case.zip
2017-11-14 22:06 jaydeep Tag Attached: chtMultiRegionSimpleFoam
2017-11-14 22:06 jaydeep Tag Attached: Heat transfer
2017-11-14 22:06 jaydeep Tag Attached: radiation
2017-11-14 22:06 jaydeep Tag Attached: fvDOM
2017-11-28 23:13 wyldckat Product Version => dev
2018-01-04 09:17 will Assigned To => will
2018-01-04 09:17 will Status new => closed
2018-01-04 09:17 will Resolution open => not fixable
2018-01-04 09:17 will Note Added: 0009196
+Issue History