Comprehensive way to manage ReSolve configuration parameters

[pelesh]

ReSolve includes several different linear solvers and supports three hardware backends. There is a large number of parameters in ReSolve to select specific solution strategy and to tune its performance. Many of the parameters are specific to a specific solver type or hardware backend or both. We need a hierarchical method to allow user to configure ReSolve easily without sifting through dozens of (often cryptically described) parameters. Most of these parameters need to be set at runtime.

This issue is to start discussion how to handle this most effectively.

The issue originally raised by @kswirydo in #86 (comment)_

[pelesh]

Another part of this discussion is how to implement interface to ReSolve's select-from-the-list options. Currently we are just passing strings as this is quick'n'dirty way to set those options and get everything running. Perhaps a better way is to expose those lists to users in a form of enums. This will require some thinking about the scope in which these enums will live.

See how we handled similar issue in #12.

Also suggested by @kswirydo in #86 (comment)_

[stonecoldhughes]

has this utility been tested for all input conditions? Is there logic to detect and report ill-formed combinations of options?

Config options are often represented naturally with a hierarchical data format, and this allows them to be saved for later use. Does that capability exist with this parser? If not, is it desirable?

https://github.com/nlohmann/json is a single header file, so it could be added to the repo once and never bothered with again.

https://github.com/nlohmann/json can parse JSON from a file or the command line directly via stdin if file I/O is undesirable.

Thousands of users have helped refine json.hpp, it is extremely robust and extensively tested.

[stonecoldhughes]

For compile-time options, it looks like CMakePresets is being used, which is definitely the best way to organize repeatable build configurations with CMake

[cameronrutherford]

has this utility been tested for all input conditions? Is there logic to detect and report ill-formed combinations of options?

Config options are often represented naturally with a hierarchical data format, and this allows them to be saved for later use. Does that capability exist with this parser? If not, is it desirable?

https://github.com/nlohmann/json is a single header file, so it could be added to the repo once and never bothered with again.

https://github.com/nlohmann/json can parse JSON from a file or the command line directly via stdin if file I/O is undesirable.

Thousands of users have helped refine json.hpp, it is extremely robust and extensively tested.

Storing Re::Solve runtime options as JSON seems like a reasonable enough option to me.

We have used TOML files for another project to some success for storing arrays of test cases with sane defaults. Doing this in JSON might be a little harder.

Maybe we can do a mix of TOML for testing, and JSON for runtime options?

[stonecoldhughes]

Lots of content online indicates that JSON is not the best choice for configuration:

https://revelry.co/insights/development/json-configuration-file-format/
https://medium.com/trabe/stop-using-json-config-files-ab9bc55d82fa

TOML and YAML seem like better options for configurations than JSON!

[stonecoldhughes]

@cameronrutherford would you please link the TOML parsing code from the other project you mentioned, if you get a chance? I imagine it could be used in this project with minor repurposing, or at the very least a helpful reference. This looks a promising library for TOML parsing: https://marzer.github.io/tomlplusplus/index.html. @pelesh one way to begin this would be to identify one of the unit/system tests that requires some configuration, represent the configuration as TOML, then modify the test to consume a TOML file.

[cameronrutherford]

@cameronrutherford would you please link the TOML parsing code from the other project you mentioned, if you get a chance? I imagine it could be used in this project with minor repurposing, or at the very least a helpful reference. This looks a promising library for TOML parsing: https://marzer.github.io/tomlplusplus/index.html. @pelesh one way to begin this would be to identify one of the unit/system tests that requires some configuration, represent the configuration as TOML, then modify the test to consume a TOML file.

ExaGO is the reference project... Let me know if you need more clarifications:

• https://github.com/ToruNiina/toml11/tree/main - this is the TOML parsing library that we use
• https://github.com/pnnl/ExaGO/blob/develop/tests/functionality/toml_utils.h - this is the utility header file that we have that helps us navigate the toml files. Admittedly it's a little hard to read, and the original author has left the project...
• https://github.com/pnnl/ExaGO/tree/develop/tests/functionality/pflow - our simplest high level application that we test. selfcheck.cpp is the main file for running, and then some example TOML files are in that folder

Let me know if you need more clarification ◡̈