ncsu-ncsg / thor Goto Github PK

Currently it runs anyway if the pnorder is higher than the scattering order and this results in bad calculations.

We currently rely on a cumbersome and non-portable make file to build THOR. We should switch over to CMake to improve portability.

When running the 24 region BeRP SNAP cases the region map echoing did not properly output info..

One of the largest sources of error in THOR is the inability to fully resolve curved geometry. Higher order tets allowing curved geometry may go a long way to improving THOR results.

Consider adding capabilities of input of other cross section formats, such as those generated by OpenMC and SERPENT, as well as those used by MPACT and MCNP.

THOR should be formally profiled (with gprof? valgrind?) to determine where optimizations and enhancements should focus.

Once programmer's manual is made (per issue #21) the code should be made compliant.

JFNK was added by Sebastian to this code, it should be added in the theory manual.

There's no reason THOR shouldn't have 2D capabilities, and such capabilities can be very useful for bench-marking, demonstrations, as well as problems where 2D calculations are appropriate.

MPI runs are not always identical in their results, especially for different numbers of processors. This inconsistency should be investigated.

The page options for memory saving usage are pretty much all broken. Investigate to see if they can be salvaged or should be scrapped and started from scratch.

The SDD method developed by Dylan and Raffi should be added to THOR, it has had some issues with allowing other methods to also work, so we need to go through the method implementation first before adding it.

Most of THOR allows any module that uses another module to access all subroutines/functions. This is bad practice and privacy should be updated to keep local routines and variables local.

Multilevel methods (at least in energy) should be considered for THOR as potential acceleration scheme. Spatial multilevel methods may be difficult due to the unstructured nature of THOR meshes.

These are already computed when doing anisotropic scattering, there has been interest in having them output

THOR currently has a thoroughly robust regression test suite, however it is driven in a rather hacky manner. Upon completion of issue #20, THOR should use ctest to drive its regression tests, and perhaps add additional tests.

Using XS energy data, collapse the fast and the thermal flux for vtk output for visualization

Currently if not enough source values are given in a fixed source problem, it results in a runtime error in the application of those sources. This should be revised to instead throw an error in the source readin portion of the calculation.

Doxygen is a sophisticated program allowing automated documentation of a software, we should consider adding it to THOR.

THOR has mostly only been worked on by one person at a time. If it is to become a more broadly developed and used Open Source project, we should have a better ticketing/merge system in the repository and consider adding a pipeline.

Want to do a dependency creation internally so it does not rely on command line external libraries and can be more self contained for portable installs.

In migrating THOR, some old branches came and old issues were left behind. These should be investigated to see if any changes or suggestions in them have value.

THOR currently has an errmode extrapolation that provides some (often poor) acceleration for some problems. However a more general and robust acceleration scheme/method should be added, potentially DSA (diffusion synthetic acceleration) or NDA (nonlinear diffusion acceleration) should be investigated for unstructured mesh applicability, and added.

A thorough programmer's manual should be created as a guideline for future contributors.

This is when some region numbers are skipped (i.e. we go from region 2 to 5 without 3 or 4)

Add capabilities to read-in/use other mesh formats such as Gmsh and exodus.

Add a license related header to each source file in the main code as well as the pre/post processors.

THOR currently relies on BLAS and LAPACK, but very outdated versions of these libraries, it should be updated to use modern libraries but support backwards compatibility if it can.

THOR currently lacks any unit tests, this should be fixed and most (if not all) subroutines and functions should have unit tests added.

The detector response post-processor currently computes a response based solely on a response function. There may be value in also having capability in computing a response based on XS based reaction rates as well as multiples of those reaction rates.

Currently THOR only supports generating angular quadrature sets. It should allow users to specify their own quadrature if they want, however it should make sure that they are symmetric if they are to be used in adjoint calculations.

Memory scales roughly linearly with number of processors used due to distribution method. Distribution also prevents timing improvements for more than n*4 processors for S$_n$ quadrature orders. A warning should be thrown when using more since it is universally a performance reducer rather than enhancer.

Should give another termination and probably not an error message.

Parallel load distribution was broke and an older (less efficient) style was reverted to. This old style performs poorly for more than 8 processors, the new system should be revisited and see if it can be fixed to allow for better parallel performance.

JFNK seems sometimes wildly inconsistent between problems and may sometimes break in a problem it previously worked in for no perceptible reason.

See if it is viable to compute maximum memory used in run and add it to the output for resource analysis in post run results.

Dr. Ferrer has changes he wished for the Theory manual, go ahead and make those and merge them in.

If we skip some region indices it outputs the data as NAN

Currently region mapping requires that the ordered region ids all be given a map, even if a certain id isn't in the mesh. That is to say, a mesh with regions 1 4 6 and 8 must also include mapping for 3 5 and 8 in the input file. This should not be required.

Will make the theory manual more complete and self contained.