NatLabRockies / NatLabRockies/H2Integrate
Consider revamping how we set parameters and units at the config and framework level
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 26
- Forks
- 44
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 16
Description
Consider revamping how we set parameters and units at the config and framework level
Currently in H2I a lot of the technologies assume you are inputting parameter values with a certain unit in mind. Some technologies are very explicit (e.g. pysam_solar ingesting pv_capacity_kWdc in the config) whereas other parameter names might not include units in the name.
This is probably an unnecessary limitation in the framework, but if we solve this in a general way, I'd want to make sure it's very clear to users and reasonably easy to maintain.
Proposed solution
We've previously discussed the idea of receiving config values in value-unit pairs. I like this idea. Implementing it across all models uniformly would be challenging in a tedious-but-possible way.
We could then loop through the tech_configs and call prob.model.set_val at setup() time for each config value, using the units provided in the config file. We can't do that as-is across all models because not all converters have all config values exposed to OM; that'd be a pretty big framework overhaul idea. But doing it this way removes the need to include val=self.config.<parameter> in all the add_input calls.
Alternatives considered
Additional context
I originally had this thought while reviewing #334.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing setup(), the tech_configs loop, prob.model.set_val, and the converter add_input calls described in the issue. Review how configuration values and units are currently passed across models; done would require an agreed general approach that handles exposed and unexposed config values consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100