Add per-year pricing support for Grid and Feedstock cost models by johnjasa · Pull Request #700 · NatLabRockies/H2Integrate

johnjasa · 2026-04-24T01:40:54Z

Add per-year pricing support for Grid and Feedstock cost models

Adds the ability to specify electricity_buy_price, electricity_sell_price (Grid), and price (Feedstock) as arrays of length plant_life for per-year pricing. Previously only scalar or per-timestep (length n_timesteps) arrays were supported.

A shared determine_price_mode() utility function handles validation and mode detection for reuse across models. When n_timesteps == plant_life, the per-year interpretation takes priority with a UserWarning.

Section 1: Type of Contribution

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:

Step 1
Step 2

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

Other feedback:

Section 3: General PR Checklist

Section 4: Related Issues

Resolves #660

Section 5: Impacted Areas of the Software

Section 5.1: New Files

None.

Section 5.2: Modified Files

h2integrate/core/utilities.py
- determine_price_mode: New utility function to classify price arrays as scalar, per-timestep, or per-year.
h2integrate/converters/grid/grid.py
- GridCostModel.setup: Refactored to use determine_price_mode for buy/sell price validation.
- GridCostModel.compute: Updated VarOpEx calculation to produce per-year array for per-year pricing.
h2integrate/core/feedstocks.py
- FeedstockCostModel.setup: Refactored to use determine_price_mode for price validation.
- FeedstockCostModel.compute: Updated VarOpEx calculation to produce per-year array for per-year pricing.
docs/technology_models/grid.md
- Updated input table and added Price Input Modes section.
docs/technology_models/feedstocks.md
- Updated price parameter docs and tip box.
h2integrate/converters/grid/test/test_grid.py
- Added 6 tests for per-year buy/sell pricing, invalid lengths, ambiguity warning, and non-hourly dt.
h2integrate/core/test/test_feedstocks.py
- Added 3 tests for per-year pricing, invalid lengths, and ambiguity warning.

Section 6: Additional Supporting Information

Section 7: Test Results, if applicable

elenya-grant

I gave some minor suggestions but nothing that was blocking! I did have a question on whether the grid cost model is properly set-up to handle non-yearly simulations that I'd like your take on!

I think you added a lot of great tests for the grid and feedstock model! I'm curious why didn't you add any tests to h2integrate/core/test/test_utilities.py that specifically only test the determine_price_mode function?

elenya-grant · 2026-04-24T15:38:01Z

-            varopex += np.sum((self.dt / 3600) * electricity_out * buy_price)
+            if self._buy_price_mode == "per_year":
+                # Per-year price: total energy * price per year
+                total_energy_bought = np.sum(electricity_out) * (self.dt / 3600)


Nonblocking: What if instead of always using electricity_sold and electricity_out as inputs to the cost model - what if the inputs were based on the _buy_price_mode? This would perhaps require adding more outputs to the grid performance model. But - it could be something like:

if self._buy_price_mode == "per_year" self.add_input("annual_electricity_out", val=0.0, shape=plant_life, units="kW*h/yr") else: self.add_input("electricity_out", val=0.0, shape=n_timesteps, units="kW") if self._sell_price_mode == "per_year" self.add_input("annual_electricity_sold", val=0.0, shape=plant_life, units="kW*h/yr") # this would have to be added as an output to the grid performance model else: self.add_input("electricity_sold", val=0.0, shape=n_timesteps, units="kW")

Thanks for drafting up how this could look! It's slightly unclear to me what the value-add would be here. The amount of electricity bought or sold doesn't vary year-to-year, so the annual_electricity_out and annual_electricity_sold arrays would have the same value repeated across the plant_life. Is your suggestion more to reduce the size of the arrays used in the calculations? I'm probably missing something!

The annual_electricity_out is flexible to varying dt and different simulation lengths (output units are kW*h/yr). electricity_out and electricity_sold are output in rate units (kW) and not adjusted based on time-step or simulation length. My suggestion is so that the cost model doesn't have to do the adjustments for dt and n_timesteps when it could be done by the performance model.

I just implemented this! We're on a call. Could you please take a look and tell me if it's close to what you want?

elenya-grant · 2026-04-24T15:49:04Z

+    total_energy = np.sum(electricity_out) * (dt / 3600)
+    expected_varopex = total_energy * np.array(buy_prices)
+
+    varopex = prob.get_val("grid.VarOpEx", units="USD/year")


I think I'm concerned because the simulation is only 24 timesteps but I'm not sure if the units make sense for the VarOpEx. For an hourly simulation of 24 timesteps. The total energy is units of kW*d (kW*h*24), then multiplied by buy price cost of USD/kW*h does not result in units of USD/year. Right? I don't think the grid cost model (and perhaps the grid performance model too) is flexible to shorter simulation times.

The VarOpEx costs in the ProFAST finance models are divided by the total production of the commodity to get the variable O&M cost value in units of USD/commodity_amount_units (commodity_amount_units is for the commodity defined for the finance model). I have to think on this a bit more though...

You're absolutely right about the grid components not being generalized for non-yearly production. I've updated the tests here. This would require a bigger set of changes beyond just this PR and should be done as part of the non-yearly simulation change work.

elenya-grant · 2026-04-24T15:51:20Z

        return config["shared_parameters"]


+def determine_price_mode(price, n_timesteps, plant_life, price_name="price"):


Nice way to put this as a shared utility function - I think this will be helpful for other models in the future!

vijay092

Looking great, John! Just a couple of thoughts:
i) A dictionary format for the sell_price array (e.g. explicitly tagging it as a yearly or daily profile) would be nice. You shouldn't have to infer the type from the array size.
ii) Maybe for later: Is there a straightforward way to pull in price forecasts automatically, to reduce the burden on the user (asking for a friend ;))

vijay092 · 2026-04-28T23:54:19Z

 | `fixed_interconnection_cost`    | scalar                       | $         | One-time fixed cost regardless of size.                                |
 | `electricity_out`               | array[n_timesteps]           | kW        | Electricity flowing out of grid (buying from grid).                    |
-| `electricity_buy_price`         | scalar/array[n_timesteps]    | $/kWh     | Price to buy electricity from grid (optional, time-varying supported). |
+| `electricity_buy_price`         | scalar/array[n_timesteps]/array[plant_life] | $/kWh     | Price to buy electricity from grid (optional; supports scalar, per-timestep, or per-year). |


Could this be expressed as a dictionary instead? e.g. {"dimension": plant_life, "val": [...]}. Would remove any ambiguity for the user.

You're right and I like your suggestion! I've changed it so the buy price and sell price modes are set by the user in the config file to make it clear.

vijay092 · 2026-04-28T23:55:53Z

-
-            else:
-                buy_price_shape = 1
+            self._buy_price_mode, buy_price_shape = determine_price_mode(


If you had the dictionary, you probably don't need this function.

I've removed this in favor of your approach -- thanks for the simplification!

…/H2Integrate into per_year_grid_feedstock

johnjasa · 2026-04-29T16:36:32Z

Looking great, John! Just a couple of thoughts: i) A dictionary format for the sell_price array (e.g. explicitly tagging it as a yearly or daily profile) would be nice. You shouldn't have to infer the type from the array size. ii) Maybe for later: Is there a straightforward way to pull in price forecasts automatically, to reduce the burden on the user (asking for a friend ;))

Great suggestions, thanks Sanjana! I've made the change you suggested so users explicitly say what the buy or sell price is. Then I've made an issue for future work to pull the price forecasts: #716. I will say we haven't historically prioritized grid-integrated systems, so as you continue to think up good features to add in for your work, please bring it up or create an issue!

vijay092

Thanks for incorporating my suggestions, John! Looks great!

Adding more flexible pricing schemes

dc59977

johnjasa requested review from elenya-grant and vijay092 April 24, 2026 01:41

elenya-grant reviewed Apr 24, 2026

View reviewed changes

johnjasa mentioned this pull request Apr 27, 2026

Assess if plant_life and n_timesteps should be set as attributes in the CostModelBaseClass #708

Open

Addressing PR comments

b00cb65

johnjasa requested a review from elenya-grant April 27, 2026 19:21

johnjasa added 4 commits April 27, 2026 13:44

Updated example test values

878217f

Reverting errants changes

7cca483

Merge branch 'develop' into per_year_grid_feedstock

f7777f6

addressing PR feedback

d224ed0

vijay092 reviewed Apr 29, 2026

View reviewed changes

johnjasa added 3 commits April 29, 2026 10:45

Merge branch 'develop' into per_year_grid_feedstock

130f8b0

Changed buy/sell price mode to user-set instead of inferred

db0c634

Merge branch 'per_year_grid_feedstock' of https://github.com/johnjasa…

2823c1a

…/H2Integrate into per_year_grid_feedstock

johnjasa requested a review from vijay092 April 29, 2026 16:36

vijay092 approved these changes Apr 29, 2026

View reviewed changes

		return config["shared_parameters"]


		def determine_price_mode(price, n_timesteps, plant_life, price_name="price"):

Conversation

johnjasa commented Apr 24, 2026

Add per-year pricing support for Grid and Feedstock cost models

Section 1: Type of Contribution

Section 2: Draft PR Checklist

TODO:

Type of Reviewer Feedback Requested (on Draft PR)

Section 3: General PR Checklist

Section 4: Related Issues

Section 5: Impacted Areas of the Software

Section 5.1: New Files

Section 5.2: Modified Files

Section 6: Additional Supporting Information

Section 7: Test Results, if applicable

Uh oh!

elenya-grant left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elenya-grant Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vijay092 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johnjasa commented Apr 29, 2026

Uh oh!

vijay092 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

elenya-grant Apr 28, 2026 •

edited

Loading

vijay092 left a comment •

edited

Loading