search

openmc-dev / fes-sdr-project

Repository for FES Shutdown Dose Rate Workflows project
7 stars 0 forks source link

Unstructured Mesh Tracking #1

Open paulromano opened 1 year ago

paulromano commented 1 year ago

The Cell object currently stores a NeighborList, but that probably ought to be pushed down to the CSGCell class since it is not used for the DAGCell objects or the future MeshCell objects. Same consideration might also apply for the translation_ and rotation_ elements?

pshriwise commented 1 year ago

Some updates on the current status of this work.

Note: this post may update from time to time as we continue with this work.

Supported Element Types

This work currently targets only linear tetrahedral element types, but our aim is to support additional element types in the future with aid from the libMesh team.

Cell Creation

As it stands, a Cell object is created for each element in the mesh. It is one of the first operations performed during creation of the MeshUniverse class. There are certainly memory usage concerns with this approach and it is likely something we will revisit in the future.

Metadata

Material Assignments

Materials are set using names assigned to mesh blocks. Similar to the way we use material assignments with DAGMC, the assignment can refer to a material either by name or by ID. A match by name will be attempted first, then a match by ID. If no name provided on a mesh block, it is considered to be a void region. A mesh block is also considered to be a void region if the name is explicitly "vacuum" or "void".

Once a material assignment is identified, all of the cells in the corresponding block are assigned to that material.

Boundary Conditions

Boundary conditions are specified as names on sidesets and, if present, they must be one of "reflective", "white", "transmission", or "vacuum" (one of the supported surface boundary types in OpenMC). If no name is specified on a sideset, it is assumed to be a transmissive boundary condition.

Particle data

Right now, the mesh universe and index is tracked by re-using the lattice_bin parameter in particle_data.h. Because a particle cannot exist in both a lattice and mesh universe at the same level of the geometry, it should be safe to do so.

Its name has been updated to lattice_or_mesh_bin and the particle data accessors mesh_index() and lattice_index() have been added to the particle_data class to avoid confusion when using this data member in different contexts throughout the code.

Mesh Index and next cell

When a particle is located in a MeshUniverse, the current cell (element) is tracked using the LocalCoord object as is normally done.

The next mesh cell is stored as the mesh_index() (probably better named as next_mesh_index()). This is set during the Particle::event_advance call to avoid doing another ray tracing operation at the point in time where we cross an element boundary.