This issue request better documentation about the penalty attribute in the DipatchModel class in osier/models/dispatch.py.

The current docstring in the class says that a user may need to tune this. I think this needs to expanded some in a theory section of documentation. The expanded discussion should include topics such as:

• What would be an instance when a user would need to tune the parameter
• What are effects of increasing or decreasing the parameter

Although this is a small part of the code that probably won't be adjusted much, I think that calling it out in the docstring brings up some of these questions. Especially since this parameter was introduced to prevent unrealistic behavior in the models.

This issue can be closed when osier has coverage as an optional dependency (or required?) and a .coveragerc file exists to specify coverage options.

• coverage dependency
• coveragerc

This issue can be resolved when a new release of osier is released to pypi. Depends on #46

Users should be able to write their own constraints for the dispatch model used in the genetic algorithm.

Currently, the DispatchModel handles units for the net demand parameter, badly. For example,

import numpy as np
net_dem = np.ones(24)

assumes that net_dem is in units of MWh.
However, users can currently specify a time_delta for the DispatchModel (required for ramping constraints) which leads to the following issue.

from osier import DispatchModel
from unyt import minute
model = DispatchModel(technology_list, net_demand=net_dem, time_delta=5*minute)

This model is now infeasible because all of the technologies (assuming default settings) have a capacity in MW -- the issue seems to be because _validate_quantity converts all time units to HOURS.

Additionally, the generation limit constraint assumes that the time delta is 1 hour...

This PR can be closed when a basic dispatch model is added to osier with appropriate tests.

This issue can be closed when a pull request is made that includes a

• technology base class
• tests for base class
• documentation for base class

This issue can be closed when there is a changelog to document the versions of osier

This issue can be closed when technology objects have a __repr__ method that allows pretty printing a technology.

This issue can be closed when a PR that removes the step Install most recent unyt from the github CI workflow is merged. This step makes it possible to use the new features I added to unyt but does not reflect the typical user's experience.

Fixing this issue depends on the release of a new version of unyt.

Here's what I know, last week (2/20/2024) I could run an osier.CapacityExpansion problem just fine and the output would look something like this

Working configurations

==========================================================
n_gen  |  n_eval  | n_nds  |      eps      |   indicator  
==========================================================
     1 |       10 |      1 |             - |             -
     2 |       20 |      1 |  0.000000E+00 |             f
     3 |       30 |      1 |  0.000000E+00 |             f
     4 |       40 |      1 |  0.000000E+00 |             f
     5 |       50 |      1 |  0.000000E+00 |             f

Now, the problem still runs but the output is a lot less pretty

Broken configurations

==========================================================
n_gen  |  n_eval  | n_nds  |      eps      |   indicator  
==========================================================
     1 |       10 |      1 |             - |             -
ERROR: evaluating object as numeric value: x[NaturalGas_Conv,0]
        (object: <class 'pyomo.core.base.var._GeneralVarData'>)
    No value for uninitialized NumericValue object x[NaturalGas_Conv,0]
ERROR: evaluating object as numeric value: x[NaturalGas_Conv,0]
        (object: <class 'pyomo.core.base.var._GeneralVarData'>)
    No value for uninitialized NumericValue object x[NaturalGas_Conv,0]
ERROR: evaluating object as numeric value: x[NaturalGas_Conv,0]
        (object: <class 'pyomo.core.base.var._GeneralVarData'>)
     2 |       20 |      1 |  0.000000E+00 |             f
ERROR: evaluating object as numeric value: x[NaturalGas_Conv,0]
        (object: <class 'pyomo.core.base.var._GeneralVarData'>)
    No value for uninitialized NumericValue object x[NaturalGas_Conv,0]
ERROR: evaluating object as numeric value: x[NaturalGas_Conv,0]
        (object: <class 'pyomo.core.base.var._GeneralVarData'>)
    No value for uninitialized NumericValue object x[NaturalGas_Conv,0]
ERROR: evaluating object as numeric value: x[NaturalGas_Conv,0]
        (object: <class 'pyomo.core.base.var._GeneralVarData'>)
     3 |       30 |      1 |  0.000000E+00 |             f
ERROR: evaluating object as numeric value: x[NaturalGas_Conv,0]
        (object: <class 'pyomo.core.base.var._GeneralVarData'>)
    No value for uninitialized NumericValue object x[NaturalGas_Conv,0]
     4 |       40 |      1 |  0.000000E+00 |             f
     5 |       50 |      1 |  0.000000E+00 |             f

What I have tried

1. I plugged the error into Google, found this post from 2018. I can verify that this problem only occurs when a model is unfeasible. However, that will be the case for many many models tested in osier because that's just how genetic algorithms work so it would be nice to turn off whatever error message is causing this.
2. I checked the verbosity settings -- the verbosity is as high as it can possibly go.

logging.getLogger('pyomo.core').setLevel(verbosity)`   # default = logging.Critical

3. I also tried

import warnings
warnings.filter('ignore')

4. I reinstalled osier in two fresh conda environments. One with Python 3.9 and the other with Python 3.10. I also tested it with Pyomo versions 6.4.1 and 6.7.1 (see above configurations) -- this behavior is only present with the most recent pyomo version, 6.7.1. This pyomo update was released this week which is consistent with the timeline where my code was working fine on Friday and today it is not. Especially since it was previously working on two other machines with more recent versions of pyomo, bet less recent than the current (until I updated them today and now they're broken).
5. I have tried specifying the pyomo version in setup.py under the install_requires parameter, however doing so results in the following error message

Obtaining file:///C:/Users/samgd/Research/osier
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [28 lines of output]
      C:\Users\samgd\anaconda3\envs\pyomo64\lib\site-packages\setuptools\__init__.py:80: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated.
      !!

              ********************************************************************************
              Requirements should be satisfied by a PEP 517 installer.
              If you are using pip, you can try `pip install --use-pep517`.
              ********************************************************************************

      !!
        dist.fetch_build_eggs(dist.setup_requires)
      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "C:\Users\samgd\Research\osier\setup.py", line 113, in <module>
          setup(**opts)
        File "C:\Users\samgd\anaconda3\envs\pyomo64\lib\site-packages\setuptools\__init__.py", line 103, in setup
          return distutils.core.setup(**attrs)
        File "C:\Users\samgd\anaconda3\envs\pyomo64\lib\site-packages\setuptools\_distutils\core.py", line 147, in setup
          _setup_distribution = dist = klass(attrs)
        File "C:\Users\samgd\anaconda3\envs\pyomo64\lib\site-packages\setuptools\dist.py", line 303, in __init__
          _Distribution.__init__(self, dist_attrs)
        File "C:\Users\samgd\anaconda3\envs\pyomo64\lib\site-packages\setuptools\_distutils\dist.py", line 258, in __init__
          getattr(self.metadata, "set_" + key)(val)
        File "C:\Users\samgd\anaconda3\envs\pyomo64\lib\site-packages\setuptools\_distutils\dist.py", line 1255, in set_requires
          distutils.versionpredicate.VersionPredicate(v)
        File "C:\Users\samgd\anaconda3\envs\pyomo64\lib\site-packages\setuptools\_distutils\versionpredicate.py", line 122, in __init__
          raise ValueError("expected parenthesized list: %r" % paren)
      ValueError: expected parenthesized list: '<=6.7.0'
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

What needs to change

This issue can be closed when setup.py specifies a version of pyomo<=6.7.0.

OR

Update the way osier is installed per the line in the error message C:\Users\samgd\anaconda3\envs\pyomo64\lib\site-packages\setuptools\__init__.py:80: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated.

@yardasol would you mind helping with this?

This issue depends on #17.
Currently, the DispatchModel only has the following constraints

• limit generation to capacity
• match supply/demand.

These are the "minimum" physical requirements for an energy system. However, dispatchable technologies, such as nuclear and coal, often have physical limits to their ramping capabilities. Therefore a ThermalTechnology subclass might have a ramp up / ramp down attribute expressed as a percentage of its rated capacity.

Design considerations

• should the ramping parameter be interpreted as a unyt quantity?
• should it remain a simple float?

Initialize build system for treetop. This issue can be closed when treetop has the appropriate structure to build with pip install.

• setup.py file
• treetop directory
• init.py file (in the treetop directory)

Nice example notebooks! i found them in the docs and wanted to have a play with them. I encountered two blockers:

• was expecting to find them in an examples directory near root (not in docs)
• jupyter is not included in the requirements
• required kernel installation (ipython kernel install --user --name=osier)

Note that the latter two (especially the last) are quite specific to people using an env/package manager.

This issue can be closed when relevant files referencing treetop are converted to osier

After releasing v3.0.0, unyt now includes common energy system units such as Wh, mmbtu, and others. Osier currently uses MW*hr instead of MWh (since it previously didn't exist).

This issue may be closed once there is a merged PR that simplifies the units in osier to match this update.

The current names objective_from_capacity and objective_from_energy in osier/equations.py are reasonable, but could be more descriptive based on the conversation around these function names in PR #38.This issue can be closed if/when more descriptive function names are developed.

In the Technology Tutorial page, it states 3 objectives. The second one - "Modify the attributes of a technology object in the current instance" is not included on the page.

This issue can be closed with a PR that adds a section to the Technology Tutorial docs page satisfying learning objective 2.

This issue can be closed when osier is released on pypi!

I think it is a good idea to include an env/package manager such as conda or mamba in the installation instructions.

• This will create more homogenous experience for users on different OS
• You should get less awkward bug reports from less expereinced users

There is an example of a (also energy) project that makes use of mamba here.

Currently, all objectives and constraints in osier require two items, the list of technologies and a solved dispatch model. Some calculations will require tunable parameters. Such as a volatility calculation using weighted_permutation_entropy, for example. Therefore, allowing users to specify the optional parameters at run time with some thing like:

objectives = (func1, functools.partial(func2, m = 7, tau=60))

Where the second objective function func2 has some optional parameters that cannot be set once a simulation begins (except by using functools.partial).

Edit:
To clarify the desired behavior, users should be able to pass a function and it's parameters to osier without explicitly calling functools.partial. E.g.,

from osier import CapacityExpansion

problem = CapacityExpansion(..., objectives=[func1, {func2: {m:7, tau:60}}], ...)

Users would be required to know which parameters they need.

Conversation

@yardasol @ZoeRichter @smpark7 @nsryan2 @munkm

Does this functionality make sense? Which version is clearer? The clarification would add more complexity to the osier.CapacityExpansion object, but it's already so similar to the functools implementation that I'm not sure anymore if the "simplification" makes sense. Looking for thoughts.

This issue can be closed when a pull request is made containing the following

• a basic model class that can run a pymoo problem
• documentation for the class
• basic tests for the class

The class itself should have at least

• metadata for the problem
• pymoo specific parameters (e.g. which algorithm to use, number of generations, population size, etc.)
• ...

This issue can be closed when a PR containing the following sub-classes (all inheriting from osier.Technology) is created

• solar panel
• wind turbine
• natural gas combined cycle
• coal
• nuclear
• hydro

Further, the following requirements should be met

• the default cost technology should be populated using the nrelpy package. osier should not carry any datasets (and the number of "magic numbers" should be minimized).
• a solar panel class should have a method that calculates its own power production based on a GHI time series (for example).
• new class methods should be tested!
• these classes should live in a technologies directory osier/technologies/
• osier.__init__.py should import these new classes automatically.

Failed pip install using latest python.

Details:

Windows (10)
python -m pip install osier pyomo==6.4.1

I tried:

Fixed by back-tracking to 3.10.

BUT please clarify expected supported python versions in installation instructions.

Suggest you also explicitly add version of python to CI.

Following "developer" installation I had failing tests due to missing solver:

git clone [email protected]:arfc/osier.git
cd osier
pip install .
pip install .[doc]
pip install pyomo==6.4.1
pytest

Results in (for example) pyomo.common.errors.ApplicationError: No executable found for solver 'cplex'.

Please move solver installation instructions from "Getting Started" to "Installation".

To allow a smoother onboarding for windows users I suggest adding installation instructions for glpk (eg conda install -c conda-forge glpk). I appreciate this might not be the best solver but it is more easilly accessible which is nice for casual users and will be easier for windows based CI.

This issue can be closed when osier has a module that enables modeling-to-generate-alternatives (MGA) functionality.

The osier test suite has fairly comprehensive tests, however, some share resources and could use some reorganizing.

One of the first things that could be done is create conftest.py file that configures the test session.

• create a conftest.py file in tests/

In the Technology Tutorial page, it states 3 objectives. The third one - "Create your own osier technology" is not included on the page.

This issue can be closed with a PR that adds a section to the Technology Tutorial docs page satisfying learning objective 3.

This issue can be closed once one of the following has happened

1. treetop is determined to be the best name for this tool
2. a better name has been agreed upon (with a subsequent pull request that renames the tool)

This issue can be closed when a pull request is made that includes a unit registry with energy-system-specific units. For example

• grams of CO2
• MWh (kWh, Wh, ...)
• $/MWh

This issue depends on an update from unyt that would enable a currency dimension.

Currently, a "storage" technology in the DispatchModel can charge itself without any external electricity production. This is incorrect.

This issue can be closed when the storage constraints do not allow a battery to charge without excess energy being produced.

This issue can be closed when documentation is added to the repository.

• sphinx documentation
• more detailed readme
• package dependencies added
• contributing file

This issue can be closed when there is a continuous integration check that runs the tests in treetop.