View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002759||OpenFOAM||[All Projects] Bug||public||2017-11-14 22:06||2018-01-04 09:17|
|Fixed in Version|
|Summary||0002759: fvDOM with wedge patch gives inaccurate heat flux calculation|
|Description||I 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|
|Tags||chtMultiRegionSimpleFoam, fvDOM, Heat transfer, radiation|
case.zip (12,745 bytes)
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.
|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|