Config class value updating

Open
  • Is something wrong?
#870 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
backend

Research direction

Start by reviewing PR #865 and the BaseConfig usage described in this issue, then trace model setup() and compute() methods where configuration attributes and OpenMDAO inputs interact. Determine whether the proposed rules should be adopted and identify the affected models; done requires an agreed scope and documented or implemented approach rather than an isolated edit.

Written by the indexing model from the issue text.

Description

framework

This came up in PR #865 with some initial changes to the EIA feedstock cost model (that were reverted).

In most models, configuration classes (classes that inherit BaseConfig) are used to do two things:

  1. Provide initial values for design variables or other openmdao inputs to the model (like capacities, etc). These values are used in the setup() method of the corresponding model class when setting inputs.
  2. Provide other design information or options that are not related to openmdao inputs (like wind farm layout parameters, pysam_options, etc). These may be used in setup() or compute() of the model class.

To date, most openmdao model classes do not modify the attributes of the configuration class once the configuration class has been created in the setup() method. Only the OpenMDAO inputs and outputs are saved to sql files, and data from configuration classes are not (which makes using openmdao inputs/outputs preferable to tracking changes in models than using configuration classes). In optimizations, the setup() method is only called once (so the configuration class is only created once), whereas anything in compute() is called for each loop in a solver (for resolving feedback coupling like in the system level controllers or when running an optimization). As a result, below are preferred methods for setting up model and configuration classes. If this is not the expected or preferred method, please comment your thoughts on this issue and we should have a bigger team discussion about it!

Preferred rules-of-them for setting-up models and configuration classes:

When designing configuration classes and model classes, all functionality/logic that would change based on any of the openmdao inputs should be handled in compute() and not require updating any of the values in the configuration class.

So, configuration classes should have methods that are specific only to the attributes of that configuration class that are not used as initial values for openmdao inputs (perhaps with the exception of the __attrs_post_init__() method. Any methods that depend on openmdao input values should be handled within the openmdao class itself.

If a model has certain "checks" for seeing if something has changed (like in the resource models), this should be done with a separate class attribute (not the config attribute).

Dominant language
Python
Stars
30
Forks
44
Avg merge
3d 12h
Merged PRs (30d)
28

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NatLabRockies/H2Integrate

All issues in NatLabRockies/H2Integrate

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.