256 config parser

[dwfncar]

Initial PR for a revised implementation of the CAMP config file parser,
camp_config.hpp is intended to replace solver_config.hpp at some point.

Main change is the simultaneous parsing of species and reactions, merged into a config object list
with the JSON read from a CAMP file list in config.json.

Need to consolidate these changes with those from #317

[dwfncar]

@K20shores @mattldawson @boulderdaze

• Parser refactor is for now named camp_config.hpp. All the new code that needs review is through the definition of ParseObjectArray (line 311). Everything else is copied from solver_config.hpp (with the additions of lines 920 - 922, an object is_null check in ValidateSchema).
• Complete process unit test suite is running OK with new parser.
• Can simply rename camp_config.hpp to solver_config.hpp when ready to switch to this new version (can delete _camp_config unit tests). To do this all examples that use solver_config.hpp will need a CAMP config.json with a camp-list of [species.json, reaections.json, ...]. I am aware of two tutorial _with_config examples, the kpp_to_micm example, and Jiwon's new command line tool that will need this. Do we want to do this as a part of this PR? Or make a follow-on task?

[K20shores]

@K20shores @mattldawson @boulderdaze

• Parser refactor is for now named camp_config.hpp. All the new code that needs review is through the definition of ParseObjectArray (line 311). Everything else is copied from solver_config.hpp (with the additions of lines 920 - 922, an object is_null check in ValidateSchema).
• Complete process unit test suite is running OK with new parser.
• Can simply rename camp_config.hpp to solver_config.hpp when ready to switch to this new version (can delete _camp_config unit tests). To do this all examples that use solver_config.hpp will need a CAMP config.json with a camp-list of [species.json, reaections.json, ...]. I am aware of two tutorial _with_config examples, the kpp_to_micm example, and Jiwon's new command line tool that will need this. Do we want to do this as a part of this PR? Or make a follow-on task?

@dwfncar we can go ahead and delete the old parser with this PR. We don't need to try to maintain backwards compatibility. We can make that a separate PR if you wish, but I would prefer that this is done all at once.

[mattldawson]

@K20shores @mattldawson @boulderdaze

• Parser refactor is for now named camp_config.hpp. All the new code that needs review is through the definition of ParseObjectArray (line 311). Everything else is copied from solver_config.hpp (with the additions of lines 920 - 922, an object is_null check in ValidateSchema).
• Complete process unit test suite is running OK with new parser.
• Can simply rename camp_config.hpp to solver_config.hpp when ready to switch to this new version (can delete _camp_config unit tests). To do this all examples that use solver_config.hpp will need a CAMP config.json with a camp-list of [species.json, reaections.json, ...]. I am aware of two tutorial _with_config examples, the kpp_to_micm example, and Jiwon's new command line tool that will need this. Do we want to do this as a part of this PR? Or make a follow-on task?

@dwfncar we can go ahead and delete the old parser with this PR. We don't need to try to maintain backwards compatibility. We can make that a separate PR if you wish, but I would prefer that this is done all at once.

I agree - it will make this easier to review if the parser can viewed as a diff instead of a separate file. As long as the tests pass I don't think we need to maintain two separate config parsers. We've marked all the version 3.x.x revisions of MICM as part of a refactor and warned people not to expect backwards compatibility across minor versions.

[boulderdaze]

@K20shores @mattldawson @boulderdaze

• Parser refactor is for now named camp_config.hpp. All the new code that needs review is through the definition of ParseObjectArray (line 311). Everything else is copied from solver_config.hpp (with the additions of lines 920 - 922, an object is_null check in ValidateSchema).
• Complete process unit test suite is running OK with new parser.
• Can simply rename camp_config.hpp to solver_config.hpp when ready to switch to this new version (can delete _camp_config unit tests). To do this all examples that use solver_config.hpp will need a CAMP config.json with a camp-list of [species.json, reaections.json, ...]. I am aware of two tutorial _with_config examples, the kpp_to_micm example, and Jiwon's new command line tool that will need this. Do we want to do this as a part of this PR? Or make a follow-on task?

@dwfncar we can go ahead and delete the old parser with this PR. We don't need to try to maintain backwards compatibility. We can make that a separate PR if you wish, but I would prefer that this is done all at once.

I agree - it will make this easier to review if the parser can viewed as a diff instead of a separate file. As long as the tests pass I don't think we need to maintain two separate config parsers. We've marked all the version 3.x.x revisions of MICM as part of a refactor and warned people not to expect backwards compatibility across minor versions.

Yes, I agree with Kyle and Matt. I can update a driver example when the changes made for camp config are merged into main

[dwfncar]

Split ParseObjectArray into ParseSpeciesArray and ParseMechanismArray, with all objects (from all config files in the CAMP file list) sorted into to arrays based on type. CHEM_SPEC and RELATIVE_TOLERANCE types are sent to ParseSpeciesArray, all others to ParseMechanismArray. This is similar to what the original parser did.

@K20shores @mattldawson @boulderdaze New parser now renamed to the original solver_config.
It requires a path to the top level CAMP file, e.g. <config_dir>/my_camp_config_file.json that has a camp-list such as [foo.json, bar.json, ...], or the path can point to a directory <config_dir>, in which case the top level config file will be assumed to be <config_dir>/config.json. All files in the camp-list must reside in <config_dir>.