This PR adds the unit-conversion capability to WATTS:

• params can now accept dictionary where the value, the current_unit, and the new_unit of a parameter are specified.
• new_unit is optional. If not specified, S.I. units will be used.
• Changes are also made to MOOSE and OpenMC plugins to automatically convert the units of a parameter to S.I and CGS, respectively. With the changes, there is no need to define the same parameter twice in different units to accommodate for the different units requirements in SAM/MOOSE and OpenMC.

A plugin to execute RELAP5-3D with WATTS. Several things to highlight:

• The default run_proc() does not work with RELAP5. Seems like it's because of the extra argument of 'stdout' to subprocess.Popen(). As a work around, I explicitly use subprocess.Popen() in the plugin to run the executable.
• This version of RELAP5-3D does not generate a CSV file. Instead, it generates a text file with a specific formatting. The text file needs to be converted to csv before the results can be extracted by the plugin. Other (newer) versions of RELAP5-3D is able to generate output csv files directly. The text-to-csv conversion in the plugin may need to be updated or removed in the future.
• I also updated the documentation, added an example, and updated the test case for the new plugin.

This PR generalizes the TemplatePlugin class (now called PluginGeneric) such that you can use it to build a plugin for an arbitrary code by specifying the executable and command-line arguments. This changes the structure of the other classes such that they don't need to define the execute_command property, instead passing it directly to the __init__ method of PluginGeneric.

With this new functionality, I've also expanded on our documentation to include:

• A section in the developer's guide that discusses how to build a new plugin (closes #65)
• A very simple "hello world" example in the getting started section (closes #62)

@nstauff I'd appreciate if you could test this out on the various examples (PyARC, SAM, SAS, etc.) to make sure they still function as intended.

This PR adds an executable argument to the constructor of all our plugins so that a user can specify an executable at the time the plugin is created. @nstauff ran into an issue where PluginSerpent was complaining that the sss2 executable wasn't found, and the only way to fix it was to make sure that sss2 was found via the PATH environment variable. With this change, one can either 1) explicitly give the absolute path of the executable or 2) give the name of the executable and specify an associated environment variable (e.g., SERPENT_DIR). I'll note that the way the executable is handled is now must more consistent across the different plugin classes.

This PR creates a new plugin for Dakota:

• The logic of the Dakota plugin is similar to the example provided by @nstauff . When Dakota is executed, it runs the Dakota_driver that in turn runs the coupled code (PyArc in the provided example) and facilitates the communication between Dakota and the coupled code.
• The functionalities of the Dakota driver have been moved to a new class known as PluginDakotaDriver. The plugin still relies on Dakota's interfacing library to communicate between Dakota and the coupled code. However, it no longer relies on wasppy to provide input data to or extract results from Dakota.

This PR adds a watts plugin for ABCE. Closes #48. ABCE can be used to model the behavior of firms participating in electricity markets. Specifically, this PR

• Adds a Plugin class, PluginABCE.
• Adds a Results class, ResultsABCE.
• Adds an example case and the configuration file in the examples directory.
• Adds some documentation about ABCE and how to use the eponymous plugin with watts.

At the moment, there are some issues on the ABCE end that prevent the addition of a more complete set of input files. Additionally, the example shown here will likely need to be reassessed as ABCE develops.

Some codes (such as SAS4A) may use templated files in both the main input file and the associated files. We need to provide the option for the user to expend templated supplementary files. Maybe this could be done with extra_inputs_tmpl that would contain the list of extra inputs that would need to be extended.

This PR involves a series updates on MOOSE plugin:

• A generalized MOOSE plugin is added to replace the original SAM specified plugin;
• A simple BISON example is added in addition to the SAM example to demo the new generalized MOOSE plugin;
• Add option to enable multi-processor running of MOOSE apps thru mpiexec -n n_cpu;
• Add option to specify supplementary input files (e.g., exodus mesh file, sub-application input file, XS file, etc.) for MOOSE plugin;
• Add a simple MOOSE MultiApps example.

Some of have observed that WATTS will sometimes hang when writing output (#49). This PR should fix this by using a non-blocking pipe. However, this solution (and in fact our prior code) only works on Unix-based platforms. On Windows, we now revert to using normal subprocess.run instead of our special version. This means that, unfortunately, if you're on Windows, using the show_stdout and show_stderr arguments won't work (they rely on tee_stdout and tee_stderr which in turn implicitly rely on our implementation of run).

I don't have WATTS installed anywhere on a Windows environment so I'm hoping someone can check whether this actually works there (@samgdotson?).

This PR is a continuation of #42 and makes the following changes:

• Each plugin now consistently uses an attribute .executable instead of different names (moose_exec, pyarc_exec, etc.). This makes it easier for the user, who only needs to learn one way of dealing with executables.
• A lot of the run/postrun logic was consolidated into the TemplatePlugin class. In simple cases, a new plugin only needs to define an execute_command property and the TemplatePlugin.run method should work seamlessly.

@nstauff I'd appreciate if you could try this out with some of the non-OpenMC plugins that are not currently tested in CI. I tried out the PyARC and SAS examples and they seem to work but it would be good to test the others as well.

I'm over from JOSS looking at this repo to make sure everything checks out. I've looked over the docs quickly and everything looks really clean and understandable. I need to get the tests running on my laptop and I'm running into some issues that I'm hoping to get help with.

I've installed watts from source, and when I run pytest tests I get the following (relevant snippet):

ImportError while importing test module '/tmp/watts/tests/test_plugin_openmc.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.8/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests/test_plugin_openmc.py:7: in <module>
    import openmc
E   ModuleNotFoundError: No module named 'openmc'

I'm using conda, so I followed the install instructions here https://docs.openmc.org/en/stable/quickinstall.html and installed from mamba, and even still I get the same error. I've checked with python3 -c "import openmc; print(openmc.__version__)" to confirm that openmc is indeed installed. Any advice on this is much appreciated.

Linking [https://github.com/openjournals/joss-reviews/issues/4735]

Description

This MR allows WATTS to be run with NEAMS Workbench

Fixes # (84)

Checklist:

• [x ] My code follows the style guidelines
• [x ] I have performed a self-review of my own code
• [x ] I have made corresponding changes to the documentation (if applicable)
• [x ] I have added tests that prove my fix is effective or that my feature works (if applicable)
• [x ] I have updated the CHANGELOG.md file (if applicable)
• [x ] I have successfully run examples that may be affected by my changes

Description

Add ACCERT plugin and include one example of ACCERT in example folder

Fixes #27

Checklist:

• [x] My code follows the style guidelines
• [x] I have performed a self-review of my own code
• [ ] I have made corresponding changes to the documentation (if applicable)
• [ ] I have added tests that prove my fix is effective or that my feature works (if applicable)
• [ ] I have updated the CHANGELOG.md file (if applicable)
• [ ] I have successfully run examples that may be affected by my changes

When a plugin is executed, it runs in a temporary directory that the user is generally unaware of. In some cases, it would be desirable to explicitly specify a path where the execution happens. Right now, the only control that one has is that you can change the TMPDIR environment variable, which will give a different base directory for where temporary files/directories are created.

Currently the RELAP5 plugin converts the plotfl text file into a CSV file and stores the selected data. This process could be problematic for large cases as the conversion process is time and memory consuming.

With the improvement, the plotfl file will no longer need to be converted to CSV. Instead, it will be read directly using PyPost which is a Python library from SNAP that can directly read the plotfl file. The new approach is significantly more efficient and is particularly suitable for large simulation cases.

Given that access to SNAP is restricted, the current plotfl-to-CSV conversion approach will NOT be removed for users without access to SNAP (or PyPost).

Currently, the setup.cfg file specifies watts as "OS Independent." However, there are at least two issues preventing Windows from supporting watts:

1. The select.select([p.stdout, p.stderr]) call breaks because select.select cannot work with streams on windows. The workaround for this is a non-blocking pipe which is addressed by @paulromano branch nonblocking-pipe (which was originally motivated by #49).
2. The fcntl is not supported by windows. There may be some substitutes. This appears integral to @paulromano's aforementioned non-blocking pipe.

This issue can be closed when the developers decide to either

• [ ] add support for windows machines
• [ ] indicate which operating systems are required