- boundaryThe list of boundary IDs from the mesh where this object applies
C++ Type:std::vector<BoundaryName>
Unit:(no unit assumed)
Controllable:No
Description:The list of boundary IDs from the mesh where this object applies
- ray_study_nameName of the view factor ray study UO.
C++ Type:UserObjectName
Unit:(no unit assumed)
Controllable:No
Description:Name of the view factor ray study UO.
RayTracingViewFactor
Computes view factors for arbitrary geometries using raytracing.
Description
RayTracingViewFactor uses the ray tracing module to compute view factors for general cavities. RayTracingViewFactor does not require the faces of the cavity to be planar and it allows obstruction. Obstruction refers to the situation of boundary a's line of sight to boundary b being obstructed by boundary c, where a, b, and c are boundaries participating in the radiative heat exchange. RayTracingViewFactor follows the general concept of radiative heat transfer geometries in MOOSE. A set of boundaries is in radiative heat transfer through a cavity filled with a transparent medium; the boundaries completely enclose the cavity so energy cannot leave the cavity by radiation.
For MOOSE's raytracing to work, the cavity must be meshed. The view factors are computed by essentially computing the integrals in UnobstructedPlanarViewFactor. The difference from UnobstructedPlanarViewFactor is that the raytracer follows the ray drawn from starting to ending quadrature points and determines if the ray collides with any of the boundaries participating in the radiative heat transfer before it reaches the ending quadrature point. The view factor integrals are only incremented by the contribution associated with the starting/ending quadrature point if no collision with any boundary occurred.
The RayTracingViewFactor requires a ViewFactorRayStudy for computing the view factors. The user should read the corresponding documentation.
Important Convention on Boundaries and Normals
Boundaries (or synonymously sidesets) are a collection of element faces. An element face in MOOSE is identified by the element id and a local face id. As a consequence, a face belongs to a particular element because it's simply one of the element's faces. For element faces on the domain boundary it is clear which element they belong to because there is no other element across the face. However, for internal faces the question which of the two neighboring elements an element face belongs to is important. An example helps to clarify. Let's assume that element e1 and e2 are neighbors and that they are adjacent across an element face that have the local indices s1 and s2 in elements e1 and e2, respectively. Element face (e1, s1) belongs to element e1, while element face (e2, s2) belongs to element e2. This is important when applying boundary conditions on boundaries that are not domain boundaries. Let's say element e1 belongs to block b1 and element e2 belongs to block b2 and we want to apply boundary conditions for the heat equation solved on block b1. In this case, the boundary that we apply boundary conditions for the heat equation must be composed of element faces belonging to b1. Going back to our two neighboring example elements, the face (e1,s1) must be added to the boundary because it belongs to element e1 which belongs to block b1 which defines the temperature. If the user tries to impose the boundary condition on element face (e2,s1) MOOSE will segfault. This distinction between internal and external boundaries is important to understand how to define boundaries around radiation cavities.
Boundaries enclosing a cavity are either external or internal boundaries. External boundaries do not have a neighbor on the other side of the face, while internal boundaries have valid elements on both sides of it. For external boundaries, the sideset must belong to one of the cavity blocks simply because there are no elements on the other side of the sideset.
However, for internal sidesets the cavity boundary must belong to the element right outside of the cavity. If element face (e1, s1) is just outside of the cavity and (e2, s2) is immediately on the other side inside of the cavity, then (e1, s1) should be used to construct the sideset. The reason is that internal sidesets will usually solve coupled heat conduction problems on the block just outside the cavity and boundary conditions for the temperature defined on this block must be imposed on the heat conduction/cavity interface.
The SideSetsBetweenSubdomainsGenerator mesh generator can be used for setting up cavity boundaries. In this mesh generator, the sidesets will belong to the "primary" side. Returning to the example, if "primary_block" is b1 and "paired_block" is b2, then (e1,s1) will be the element faces used in the new sideset. Specifically, the "primary_block" are the blocks around the cavity, while "paired_block" are the blocks inside the cavity.
Example Input syntax
[Mesh]
[cartesian]
type = CartesianMeshGenerator
dim = 3
dx = '0.55 0.9 0.55'
dy = '0.55 0.9 0.55'
dz = '0.75 0.0001 0.25'
subdomain_id = '0 0 0
0 0 0
0 0 0
0 0 0
0 1 0
0 0 0
0 0 0
0 0 0
0 0 0'
[]
[side_set_around_obstruction]
type = SideSetsBetweenSubdomainsGenerator
input = cartesian
primary_block = 1
paired_block = 0
new_boundary = 'obstacle'
[]
[]
[UserObjects]
[view_factor_study]
type = ViewFactorRayStudy
execute_on = initial
boundary = 'left right top bottom front back obstacle'
face_order = FOURTH
polar_quad_order = 12
azimuthal_quad_order = 4
warn_subdomain_hmax = false
[]
[view_factor]
type = RayTracingViewFactor
boundary = 'left right top bottom front back obstacle'
execute_on = INITIAL
ray_study_name = view_factor_study
[]
[]
[RayBCs/viewfactor]
type = ViewFactorRayBC
boundary = 'left right top bottom front back obstacle'
[]
# Reference solution for front -> back view factor
# is 0.282833. This result is derived from analytical
# view factors from:
# front -> orthogonal sides around front [left right top bottom]
# front -> obstacle
# front -> everywhere must be sum to 1
#
[Postprocessors]
[front_back]
type = ViewFactorPP
from_boundary = front
to_boundary = back
view_factor_object_name = view_factor
[]
[]
[Problem]
solve = false
[]
[Executioner]
type = Steady
[]
[Outputs]
csv = true
[]
Input Parameters
- execute_onTIMESTEP_ENDThe list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html.
Default:TIMESTEP_END
C++ Type:ExecFlagEnum
Unit:(no unit assumed)
Controllable:No
Description:The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html.
- normalize_view_factorTrueDetermines if view factors are normalized to sum to one (consistent with their definition).
Default:True
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Determines if view factors are normalized to sum to one (consistent with their definition).
- print_view_factor_infoFalseFlag to print information about computed view factors.
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Flag to print information about computed view factors.
- prop_getter_suffixAn optional suffix parameter that can be appended to any attempt to retrieve/get material properties. The suffix will be prepended with a '_' character.
C++ Type:MaterialPropertyName
Unit:(no unit assumed)
Controllable:No
Description:An optional suffix parameter that can be appended to any attempt to retrieve/get material properties. The suffix will be prepended with a '_' character.
- use_interpolated_stateFalseFor the old and older state use projected material properties interpolated at the quadrature points. To set up projection use the ProjectedStatefulMaterialStorageAction.
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:For the old and older state use projected material properties interpolated at the quadrature points. To set up projection use the ProjectedStatefulMaterialStorageAction.
- view_factor_tol1.79769e+308Tolerance for checking view factors. Default is to allow everything.
Default:1.79769e+308
C++ Type:double
Unit:(no unit assumed)
Controllable:No
Description:Tolerance for checking view factors. Default is to allow everything.
Optional Parameters
- allow_duplicate_execution_on_initialFalseIn the case where this UserObject is depended upon by an initial condition, allow it to be executed twice during the initial setup (once before the IC and again after mesh adaptivity (if applicable).
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:In the case where this UserObject is depended upon by an initial condition, allow it to be executed twice during the initial setup (once before the IC and again after mesh adaptivity (if applicable).
- control_tagsAdds user-defined labels for accessing object parameters via control logic.
C++ Type:std::vector<std::string>
Unit:(no unit assumed)
Controllable:No
Description:Adds user-defined labels for accessing object parameters via control logic.
- enableTrueSet the enabled status of the MooseObject.
Default:True
C++ Type:bool
Unit:(no unit assumed)
Controllable:Yes
Description:Set the enabled status of the MooseObject.
- execution_order_group0Execution order groups are executed in increasing order (e.g., the lowest number is executed first). Note that negative group numbers may be used to execute groups before the default (0) group. Please refer to the user object documentation for ordering of user object execution within a group.
Default:0
C++ Type:int
Unit:(no unit assumed)
Controllable:No
Description:Execution order groups are executed in increasing order (e.g., the lowest number is executed first). Note that negative group numbers may be used to execute groups before the default (0) group. Please refer to the user object documentation for ordering of user object execution within a group.
- force_postauxFalseForces the UserObject to be executed in POSTAUX
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Forces the UserObject to be executed in POSTAUX
- force_preauxFalseForces the UserObject to be executed in PREAUX
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Forces the UserObject to be executed in PREAUX
- force_preicFalseForces the UserObject to be executed in PREIC during initial setup
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Forces the UserObject to be executed in PREIC during initial setup
- use_displaced_meshFalseWhether or not this object should use the displaced mesh for computation. Note that in the case this is true but no displacements are provided in the Mesh block the undisplaced mesh will still be used.
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Whether or not this object should use the displaced mesh for computation. Note that in the case this is true but no displacements are provided in the Mesh block the undisplaced mesh will still be used.