Update README.md

comprehensive instructions

README.md

@@ -1,8 +1,6 @@
 # GITR 
 Global Impurity Transport Code
 
-[![Build GITR](https://github.com/ORNL-Fusion/GITR/actions/workflows/cmake.yml/badge.svg)](https://github.com/ORNL-Fusion/GITR/actions/workflows/cmake.yml)
-
 ### Note for legacy GITR users:
 For reference, please visit the archived copy of the GITR project - [GITR_legacy](https://github.com/ORNL-Fusion/GITR_legacy)
 
@@ -25,18 +23,62 @@ fields and profiles of the background.
 
 ![Operator Loop and Equation of Motion](images/GITR_integration.png)
 
+# Installing GITR
+
+GITR is a C++ code that must be compiled on the target platform before it can be run. It can be configured to take advantage of CPU or GPU
+parallelism if they are available.
+
+There are 2 options for installation:
+
+1. Container-based installation (recommended)
+2. Bare-metal installation (discouraged)
+
+**Note: Users are highly encouraged not to attempt a bare-metal installation unless a container installation is impossible. 
+Steps for a bare-metal installation are unique to every platform, and vary depending on software versions throughout
+a long stack of system dependencies**
+
+## Container Installation Options
+
+Container images can be built on any device using the Docker Engine and Dockerfile image specifications in the repo. 
+Alternatively, pre-configured images can be pulled from the package registry in this repo and run immediately using Singularity, Podman, Docker,
+or any other OCI-compilant container service.
+
+Two types of containers exist:
+
+1. Interactive development containers - GITR source code on host is volume mapped into a interactive container environment with all of GITR's dependencies.
+   Inside this environment, the user can modify files, compile artifacts, configure hardware usage, and run problems. This is for developers who with to modify GITR.
+   These containers can be built on the target systems or pulled pre-built from the package registry.
+
+2. Noninteractive run-only containers - GITR binaries are pre-compiled within a non-interactive container image. It is not possible to modify or rebuild GITR in this image.
+   This is for users who wish to run GITR on problems, but have no need to modify GITR.
+
+## Building Containers
+
+### container_0 instructions
+
+### container_1 instructions
+
+## Pulling Pre-built containers
+
+### container_0 instructions
+### container_1 instructions
+
+## Running Containers:
+
+### interactive container instructions
+### noninteractive container instructions
+
+## Running GITR in containers:
+
+### interactive container instructions
+### noninteractive container instructions
+
+## Bare Metal Installation Instructions
+
+*Note: content below being migrated into sections above*
+
+
 
-## Directory Layout
-```
-. Top Level: Top level build system file **CMakeLists.txt**, LICENSE file, README.md (this file)
-├── CMake           ---> build system files
-├── images          ---> repo visuals for websites and presentations
-├── examples        ---> contains a post-processing example script
-├── include         ---> C++ header files
-├── src             ---> C++ source files
-├── test_include    ---> C++ unit test header files
-└── test_src        ---> C++ unit test source files
-```
 ## Docker Build (local container, no CUDA)
 
 This is a straightforward option for compiling GITR. This build is recommended for using GITR on a local device. 
@@ -351,64 +393,6 @@ A list of the required options and a brief description of each is provided:
 The default configuration options in GITR are compatible with the input deck in:
 [GITR_CPC_example](https://github.com/ORNL-Fusion/GITR-CPC-Example).
 
-## Testing
-
-Navigate to the user-created build directory and run:
-
-> ctest
-
-### Adding a test:
-
-1. Navigate to `CMake/define_test_components.cmake`.
-
-2. Pick a name for the test and add it to
-   the CMake variable `gpu_test_targets`
-   if it can optionally use the GPU. Otherwise put it in
-   `cpu_test_targets`.
-
-3. Create the actual unit test file - it must be named **exactly** the name you picked with .cpp
-   at the end, and in the directory `GITR/test_src`. You must include:
-
-> \#include "test\_utils.hpp"
-
-4. Link any libraries your test needs. Do this in `GITR/CMake/crosslink_components.cmake`.
-
-### Adding a data file accessible to the unit tests:
-1. Include this file in your test file:
-
-> \#include "test\_data\_filepath.hpp"
-
-   It contains preprocessor definitions for filepaths. This file is automatically generated by
-   the build system. To use a data file in the tests, you will need to instruct the build system
-   to create a new entry in that header file.
-
-2. Copy your test file into `GITR/test_data/`.
-
-3. Add the following lines anywhere after the macro definition in 
-   `GITR/CMake/configure_test_data.cmake`:
-
-> generate\_testing\_file( "test\_data/your\_test\_file.extension" )
-> set( YOUR\_PREPROCESSOR\_DEFINE\_NAME ${destination\_path})
-
-4. Navigate to `GITR/CMake/define_define_test_components.cmake`. Add a line:
-
-> \#cmakedefine YOUR\_PREPROCESSOR\_DEFINE\_NAME "${YOUR\_PREPROCESSOR\_DEFINE\_NAME}"
-
-## Bugs/Issues
-
-Create a new issue under GitHub's Issues tab.
-
-## Forum
-
-Search the GitHub discussions tab for existing threads or start a new one.
-
-## Contribute
-
-Fork this repository, branch off of *dev*, and open a merge request into *dev*.
-
-## Release Notes
-
-Navigate to `GITR/docs/release_notes.md`
 
 ## System Dependencies: