You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, OpenMOC has two mesh classes to tally reaction rates with.
process.Mesh (defined in process.py) is only for uniform meshes, and is very easy to use from the Python side. It can be created straight from a Lattice object
openmoc.Mesh (defined in Mesh.cpp) can do non-uniform meshes as well, and is created slightly differently. SWIG bindings make sure it's callable from Python. It is defined on the C++ side, and is faster which can be important for large 3D problems.
In the future, we want to merge these classes or keep only one Mesh class. The process.py class is the one that should go, since the C++ build also needs the capability to tally reaction rates.
The text was updated successfully, but these errors were encountered:
Currently, OpenMOC has two mesh classes to tally reaction rates with.
process.Mesh (defined in process.py) is only for uniform meshes, and is very easy to use from the Python side. It can be created straight from a Lattice object
openmoc.Mesh (defined in Mesh.cpp) can do non-uniform meshes as well, and is created slightly differently. SWIG bindings make sure it's callable from Python. It is defined on the C++ side, and is faster which can be important for large 3D problems.
In the future, we want to merge these classes or keep only one Mesh class. The process.py class is the one that should go, since the C++ build also needs the capability to tally reaction rates.
The text was updated successfully, but these errors were encountered: