Check for extraneous or mis-categorized input parameters

[elenya-grant]

Check for extraneous or mis-categorized input parameters

This PR introduces a route to resolving Issue #251. In this PR - the user-provided technology configuration is compared against the config attributes of the models that make up that technology after the open-mdao problem has been setup. This is only checked for technologies that have a defined control strategy or dispatch rule set (more than just a cost model and/or a performance model). This is because these are the only cases where models should be using a strict=False when creating the config attribute (currently, this basically only applies to storage cost, performance, and control models). Ideally, all converter models should, at this time, be using a strict=True when creating their configuration classes, and therefore should not need to be checked after the fact.

This will throw an error if the user-provided technology configuration has:

• extra inputs that are not used by any of the models
• inputs that are put in "shared_parameters" but are only used by a single model (i.e., a performance parameter is put under shared parameters)
• something is a shared parameter but is not under shared_parameters

The general methodology/idea is to:

1. Check if a technology has a defined control strategy or dispatch rule set, if so, continue to step 2
2. Get the config attribute of each model for that technology
3. Find the parameters that are shared across all the configs from Step 2 and build the shared_parameters section
4. Check the dictionary built from Step 2 and 3 against the user-provided dictionary. Throw errors if user provided any extraneous inputs or put parameter(s) under the "wrong" parameter section

Section 1: Type of Contribution

• Feature Enhancement
  • Framework
  • New Model
  • Updated Model
  • Tools/Utilities
  • Other (please describe):
• Bug Fix
• Documentation Update
• CI Changes
• Other (please describe):

Section 2: Draft PR Checklist

• Open draft PR
• Describe the feature that will be added
• Fill out TODO list steps
• Describe requested feedback from reviewers on draft PR
• Complete Section 7: New Model Checklist (if applicable)

TODO:

• Update inline comments/doc string based on any reviewer feedback to make methodology more clear
• Step 2

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

Other feedback:

Section 3: General PR Checklist

• PR description thoroughly describes the new feature, bug fix, etc.
• Added tests for new functionality or bug fixes
• Tests pass (If not, and this is expected, please elaborate in the Section 6: Test Results)
• Documentation
  • Docstrings are up-to-date
  • Related docs/ files are up-to-date, or added when necessary
  • Documentation has been rebuilt successfully
  • Examples have been updated (if applicable)
• CHANGELOG.md
  • At least one complete sentence has been provided to describe the changes made in this PR
  • After the above, a hyperlink has been provided to the PR using the following format:
    "A complete thought. [PR XYZ]((https://github.com/NatLabRockies/H2Integrate/pull/XYZ)", where
    XYZ should be replaced with the actual number.

Section 3: Related Issues

This is intended to resolve, or at least mostly resolve Issue #251

Section 4: Impacted Areas of the Software

Section 4.1: New Files

• path/to/file.extension
  • method1: What and why something was changed in one sentence or less.

Section 4.2: Modified Files

• h2integrate/core/dict_utils.py
  • check_inputs(): new method that checks for extra or mis-categorized inputs
• h2integrate/core/h2integrate_model.py:
  • setup(): added call to check_inputs function
• h2integrate/core/test/test_utilities.py
  • test_check_inputs(): tests that the check_inputs method works as expected
  • create_om_problem(): new method that is used in test_check_inputs
• h2integrate/core/test/inputs/no_duplicates.yaml: added demand_profile under the battery performance parameters so that the battery model can be instantiated properly

Examples that need fixed tech configs:

• 01_onshore_steel_mn: updated combiner, battery, h2_storage
• 02_texas_ammonia: updated combiner, battery, h2_storage
• 12_ammonia_synloop: updated combiner, battery, h2_storage
• 18_pyomo_heuristic_dispatch: updated battery
• 30_pyomo_optimized_dispatch: updated battery
• 09_co2/direct_ocean_capture: updated hopp, combiner, and battery
• 09_co2/ocean_alkalinity_enhancement: updated battery
• [ ]

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

• Model Structure:
  • Follows established naming conventions outlined in docs/developer_guide/coding_guidelines.md
  • Used attrs class to define the Config to load in attributes for the model
    • If applicable: inherit from BaseConfig or CostModelBaseConfig
  • Added: initialize() method, setup() method, compute() method
    • If applicable: inherit from CostModelBaseClass
• Integration: Model has been properly integrated into H2Integrate
  • Added to supported_models.py
  • If a new commodity_type is added, update create_financial_model in h2integrate_model.py
• Tests: Unit tests have been added for the new model
  • Pytest-style unit tests
  • Unit tests are in a "test" folder within the folder a new model was added to
  • If applicable add integration tests
• Example: If applicable, a working example demonstrating the new model has been created
  • Input file comments
  • Run file comments
  • Example has been tested and runs successfully in test_all_examples.py
• Documentation:
  • Write docstrings using the Google style
  • Model added to the main models list in docs/user_guide/model_overview.md
    • Model documentation page added to the appropriate docs/ section
    • <model_name>.md is added to the _toc.yml