ncsu-ncsg / thor Goto Github PK
View Code? Open in Web Editor NEWTHOR is a radiation transport code for unstructured meshes.
License: MIT License
THOR is a radiation transport code for unstructured meshes.
License: MIT License
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.
Should give another termination and probably not an error message.
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.
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.
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.
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.
Currently it runs anyway if the pnorder is higher than the scattering order and this results in bad calculations.
THOR currently lacks any unit tests, this should be fixed and most (if not all) subroutines and functions should have unit tests added.
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.
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.
This is when some region numbers are skipped (i.e. we go from region 2 to 5 without 3 or 4)
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.
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.
JFNK seems sometimes wildly inconsistent between problems and may sometimes break in a problem it previously worked in for no perceptible reason.
Dr. Ferrer has changes he wished for the Theory manual, go ahead and make those and merge them in.
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.
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.
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.
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.
THOR should be formally profiled (with gprof? valgrind?) to determine where optimizations and enhancements should focus.
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.
A thorough programmer's manual should be created as a guideline for future contributors.
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.
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.
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.
JFNK was added by Sebastian to this code, it should be added in the theory manual.
MPI runs are not always identical in their results, especially for different numbers of processors. This inconsistency should be investigated.
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.
Using XS energy data, collapse the fast and the thermal flux for vtk output for visualization
Add a license related header to each source file in the main code as well as the pre/post processors.
Will make the theory manual more complete and self contained.
When running the 24 region BeRP SNAP cases the region map echoing did not properly output info..
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.
If we skip some region indices it outputs the data as NAN
Add capabilities to read-in/use other mesh formats such as Gmsh and exodus.
Once programmer's manual is made (per issue #21) the code should be made compliant.
Doxygen is a sophisticated program allowing automated documentation of a software, we should consider adding it to THOR.
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.
These are already computed when doing anisotropic scattering, there has been interest in having them output
We currently rely on a cumbersome and non-portable make file to build THOR. We should switch over to CMake to improve portability.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.