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<<<{"href": "../../syntax/Mesh/index.html"}>>>]
   [cartesian]
     type = CartesianMeshGenerator<<<{"description": "This CartesianMeshGenerator creates a non-uniform Cartesian mesh.", "href": "../meshgenerators/CartesianMeshGenerator.html"}>>>
     dim<<<{"description": "The dimension of the mesh to be generated"}>>> = 3
     dx<<<{"description": "Intervals in the X direction"}>>> = '0.55 0.9 0.55'
     dy<<<{"description": "Intervals in the Y direction (required when dim>1 otherwise ignored)"}>>> = '0.55 0.9 0.55'
     dz<<<{"description": "Intervals in the Z direction (required when dim>2 otherwise ignored)"}>>> = '0.75 0.0001 0.25'
     subdomain_id<<<{"description": "Block IDs (default to all zero)"}>>> = '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<<<{"description": "MeshGenerator that creates a sideset composed of the nodes located between two or more subdomains.", "href": "../meshgenerators/SideSetsBetweenSubdomainsGenerator.html"}>>>
     input<<<{"description": "The mesh we want to modify"}>>> = cartesian
     primary_block<<<{"description": "The primary set of blocks for which to draw a sideset between"}>>> = 1
     paired_block<<<{"description": "The paired set of blocks for which to draw a sideset between"}>>> = 0
     new_boundary<<<{"description": "The list of boundary names to create on the supplied subdomain"}>>> = 'obstacle'
   []
[]

[UserObjects<<<{"href": "../../syntax/UserObjects/index.html"}>>>]
  [view_factor_study]
    type = ViewFactorRayStudy<<<{"description": "This ray study is used to compute view factors in cavities with obstruction. It sends out rays from surfaces bounding the radiation cavity into a set of directions determined by an angular quadrature. The rays are tracked and view factors are computed by determining the surface where the ray dies.", "href": "ViewFactorRayStudy.html"}>>>
    execute_on<<<{"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."}>>> = initial
    boundary<<<{"description": "The list of boundaries where view factors are desired"}>>> = 'left right top bottom front back obstacle'
    face_order<<<{"description": "The face quadrature rule order"}>>> = FOURTH
    polar_quad_order<<<{"description": "Order of the polar quadrature [polar angle is between ray and normal]. Must be even."}>>> = 12
    azimuthal_quad_order<<<{"description": "Order of the azimuthal quadrature per quadrant [azimuthal angle is measured in a plane perpendicular to the normal]."}>>> = 4
    warn_subdomain_hmax<<<{"description": "Whether or not to warn if the approximated hmax (constant on subdomain) varies significantly for an element"}>>> = false
  []

  [view_factor]
    type = RayTracingViewFactor<<<{"description": "Computes view factors for arbitrary geometries using raytracing.", "href": "RayTracingViewFactor.html"}>>>
    boundary<<<{"description": "The list of boundary IDs from the mesh where this object applies"}>>> = 'left right top bottom front back obstacle'
    execute_on<<<{"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."}>>> = INITIAL
    ray_study_name<<<{"description": "Name of the view factor ray study UO."}>>> = view_factor_study
  []
[]

[RayBCs<<<{"href": "../../syntax/RayBCs/index.html"}>>>/viewfactor]
  type = ViewFactorRayBC<<<{"description": "This ray boundary condition is applied on all sidesets bounding a radiation cavity except symmetry sidesets. It kills rays that hit the sideset and scores the ray for computation of view factors.", "href": "../raybcs/ViewFactorRayBC.html"}>>>
  boundary<<<{"description": "The list of boundary IDs from the mesh where this object applies"}>>> = '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<<<{"href": "../../syntax/Postprocessors/index.html"}>>>]
  [front_back]
    type = ViewFactorPP<<<{"description": "This postprocessor allows to extract view factors from ViewFactor userobjects.", "href": "../postprocessors/ViewFactorPP.html"}>>>
    from_boundary<<<{"description": "The boundary from which to compute the view factor."}>>> = front
    to_boundary<<<{"description": "The boundary from which to compute the view factor."}>>> = back
    view_factor_object_name<<<{"description": "Name of the ViewFactor userobjects."}>>> = view_factor
  []
[]

[Problem<<<{"href": "../../syntax/Problem/index.html"}>>>]
  solve = false
[]

[Executioner<<<{"href": "../../syntax/Executioner/index.html"}>>>]
  type = Steady
[]

[Outputs<<<{"href": "../../syntax/Outputs/index.html"}>>>]
  csv<<<{"description": "Output the scalar variable and postprocessors to a *.csv file using the default CSV output."}>>> = true
[]
(moose/modules/heat_transfer/test/tests/view_factors/view_factor_obstructed.i)

Input Parameters

  • boundaryThe list of boundary IDs from the mesh where this object applies

    C++ Type:std::vector<BoundaryName>

    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

    Controllable:No

    Description:Name of the view factor ray study UO.

Required Parameters

  • normalize_view_factorTrueDetermines if view factors are normalized to sum to one (consistent with their definition).

    Default:True

    C++ Type:bool

    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

    Controllable:No

    Description:Flag to print information about computed view factors.

  • 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

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

  • 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

    Options:NONE, INITIAL, LINEAR, NONLINEAR_CONVERGENCE, NONLINEAR, POSTCHECK, TIMESTEP_END, TIMESTEP_BEGIN, MULTIAPP_FIXED_POINT_END, MULTIAPP_FIXED_POINT_BEGIN, FINAL, CUSTOM

    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.

  • 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

    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

    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

    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

    Controllable:No

    Description:Forces the UserObject to be executed in PREIC during initial setup

Execution Scheduling Parameters

  • control_tagsAdds user-defined labels for accessing object parameters via control logic.

    C++ Type:std::vector<std::string>

    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

    Controllable:Yes

    Description:Set the enabled status of the MooseObject.

  • 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

    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.

Advanced Parameters

  • 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

    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.

Material Property Retrieval Parameters