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
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.mdfile should concisely document the purpose of each directory.SphericalShellis the directory for the first problem with a single spherical shellWC_Layersis the directory for a second problem with multiple nested spherical shells, originally only 2If there are common files across different problems, then a directory can be made to house those, and appropriately described in a the
Readme.mdProblem 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.mdfile 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 theReadme.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.
argparseto get values that affect the simulationmodel, typicallygeometry,materials,settings(includingsource) andtallies, by calling a function for each.Subtasks:
Readme.mdfile to document the purpose of each directoryReadme.mdto each directory to outline the directory purpose and file structure