Repo overhaul and code design

[gonuke]

This repository has become a little scattered and hard to navigate. This is also tied to some design questions in the included code. This issue will discuss an overall layout as well as some code design issues that should help restore some order. Some of the repo is already relatively compliant with this guidance already, and it may not constitute much effort to modify it.

High-level layout

This repo represents a sandbox/playground for exploring different activation problems and comparing between tools. As such, each different activation problem should have its own directory structure to separate it from others. All files for each of those problems should be within its directory, with possible sub-directories, as appropriate. A Readme.md file should concisely document the purpose of each directory.

• SphericalShell is the directory for the first problem with a single spherical shell
• WC_Layers is the directory for a second problem with multiple nested spherical shells, originally only 2

If there are common files across different problems, then a directory can be made to house those, and appropriately described in a the Readme.md

Problem directory layout

For each problem, it is useful to create an orderly directory structure so that when new people review it or want to learn from it, it is clear what it contains. Each directory should have a Readme.md file that documents the problem and is kept up to date as things change. That file should provide a concise description of the directory's contents and the role of each file in solving a problem. Results should only be included in the repo if they constitute a reference set of results, either for implementing continuous integration (CI) or as a tutorial for new users. If they are included, they should be in a separate sub-directory and described in the Readme.md.

Code design

Consideration should be given for some flexibility of the problem, without turning each problem into an epic software development project. Some of the purpose of this is to develop best practices and design experience.

• there should be one script to build an OpenMC model and a different script to process the output
• each script should have a main function that may use argparse to get values that affect the simulation
• if the input becomes extensive enough, it should be imported with via YAML
• for the script that builds an OpenMC model, the main function should assemble different elements of an OpenMC model, typically geometry, materials, settings (including source) and tallies, by calling a function for each.
• some thought should be given to making those functions flexible for exploring variations in the case without going overboard
• for the script that processes output, the main function should call different functions to read the data, process the data, produce output based on the processed data

Subtasks:

• all files that are for a specific problem should be moved out of the main directory and into a relevant problem directory
• add/update Readme.md file to document the purpose of each directory
• add a Readme.md to each directory to outline the directory purpose and file structure
• remove results or move to a sub-directory and document them as a reference
• refactor each script to have the appropriate structure