Standardized Performance Outputs: Generic Storage & Control by elenya-grant · Pull Request #493 · NatLabRockies/H2Integrate

elenya-grant · 2026-02-03T16:25:30Z

Standardized Performance Outputs: Generic Storage & Control

This PR is a follow-on to PR #463 and should not be merged in until after #463 is.

This PR updates the generic storage performance models and the control strategies so storage models have the same outputs as converters. There are 3 storage performance models:

h2integrate/storage/battery/pysam_battery.py: This was updated in PR Standardize performance model outputs #463
h2integrate/storage/simple_generic_storage.py: basically did nothing
h2integrate/storage/simple_storage_auto_sizing.py: calculates storage capacity and charge rate needed to meet a demand.

To be consistent with the pysam_battery model, the generic storage performance models needed to output the standardized outputs (like capacity factor, rated production, etc) but these generic performance models did very minimal calculations and did not output commodity_out, most calculations were done in the controllers, not the performance models.

Basically, the control strategies have been updated to output commodity_set_point instead of commodity_out. commodity_set_point is what the controller tells the performance model is the "target" commodity_out. Since the performance model may not be able to achieve the commodity_set_point (due to a variety of possible differences in the control model and the performance model, like losses), the performance model output commodity_out may not equal the commodity_set_point. The commodity_set_point is the input to the storage performance models, which now output commodity_out, annual_commodity_production, capacity_factor, etc. The computations now done in some of the storage performance models may be somewhat duplicative of the performance of some controllers, but this ensures that the storage controllers are compatible with any storage performance model.

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:

These TODOs are only if PR #407 gets merged in before this one is ready. Otherwise, a separate PR will include these TODOs after #407 is merged.

Change commodity_name to commodity for the generic storage performance models and control strategies
Change commodity_units to commodity_rate_units for the generic storage performance models and control strategies

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

Thoughts on naming convention, specifically the use of commodity_set_point?
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 has been updated to describe the changes made in this PR

Section 3: Related Issues

This partially resolves some of Issue #486, and would resolve a step in Issue #485

New issue made: #498

Section 4: Impacted Areas of the Software

Section 4.1: New Files

N/A

Section 4.2: Modified Files

h2integrate/storage/simple_generic_storage.py: added commodity_set_point as an input, updated compute() method to better reflect performance of a "pass through" type storage component (this storage model has no inputs related to capacity, which is why the compute() method basically now acts like a pass-through component)
h2integrate/storage/simple_storage_auto_sizing.py: added commodity_set_point as an input, updated compute() method to better reflect simple performance of a storage component
h2integrate/control/control_strategies/demand_openloop_controller.py: changed output variable name commodity_out to commodity_set_point
h2integrate/control/control_strategies/passthrough_openloop_controller.py: changed output variable name commodity_out to commodity_set_point
h2integrate/postprocess/test/test_sql_timeseries_to_csv.py: updated subtest value, see justification in Section 6
pytest examples/test/test_all_examples.py::test_ammonia_synloop_example: added subtest for annual ammonia production and updated 3 subtest values that changed, see justification in Section 6.

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

h2integrate/postprocess/test/test_sql_timeseries_to_csv.py::test_save_csv_all_results: subtest for number of columns increased from 35 to 36 because of the new output commodity_set_point.
pytest examples/test/test_all_examples.py::test_ammonia_synloop_example: subtests for ammonia OpEx, total adjusted OpEx for ammonia finance subgroup, and the LCOA failed, the test values decreased.
- The OpEx values decreased because the variable OpEx portion of the OpEx in the ammonia synloop decreased. These costs are multipliers of the annual ammonia production. The variable opex is equal to cat_opex + h2o_opex - o2_opex, all of these are multipliers of the annual ammonia produced. All these opex values increased, but the o2_opex increased much more than the increase in cat_opex and h2o_opex combined, meaning a net reduction in OpEx.
- The annual ammonia production increased from 364,095 t/year to 406,333 t/year.
- The max_hydrogen_capacity of the ammonia_synloop model is 10589.36 kg/h, this value has not changed.
- The maximum hydrogen_in to the ammonia_synloop model decreased from 12549 kg/h to 9306 kg/h. This indicates that now more hydrogen is being used to make ammonia rather than being "curtailed". The total hydrogen consumed is the same as before (meaning the total hydrogen_in is the same), but the hydrogen_out of the ammonia model decreased (likely because more hydrogen is being used)
- Previously, the limiting factor on ammonia production was primarily the ammonia plant capacity
  - capacity limited: 4863 hrs
  - hydrogen limited: 3716 hrs
  - nitrogen limited: 181
- Now, the limiting factor on ammonia production is always hydrogen. This is because the hydrogen output is more constant because it comes from the hydrogen storage output rather than the pass-through controller output. The pass through controller hydrogen set point is equal to the hydrogen produced from the electrolyzer. Aka - beforehand the hydrogen into the ammonia model was equal to the hydrogen out of the electrolyzer. Now that the hydrogen storage auto-sizing performance model actually represents the smoothing effect that the hydrogen storage has on the hydrogen production profile, the hydrogen into the ammonia synloop has less variability and is more constant, making hydrogen the limiting factor more often which means more hydrogen is consumed because when hydrogen is not the limiting factor, hydrogen is curtailed.
- The test values would not likely have changed if we used the "generic_storage_model" as the performance model since this acts like the pass-through controller. This would make the hydrogen into the ammonia model the same as before (equal to the hydrogen out of the electrolyzer model). But - we would have to set the storage capacity and charge rate so that the hydrogen storage cost is the same as before.
- Overall, the LCOA decreased because the OpEx costs decreased and the ammonia production increased.

Section 7 (Optional): New Model Checklist

…puts

…ART into converter_baseclass

…ents

…seclass_storage

johnjasa

Thanks for this, Elenya! I think it's a great step in standardizing some of these storage and control models -- there's a lot of complex interactions here.

I've left some comments and pushed up minor changes. The comments are mostly questions to provoke introspection into the approaches used here or minor suggestions for clarity, nothing too major.

johnjasa · 2026-02-05T17:37:52Z

h2integrate/storage/simple_generic_storage.py

+        # Estimate the rated commodity production as the maximum value from the commodity_set_point
+        outputs[f"rated_{self.commodity}_production"] = inputs[f"{self.commodity}_set_point"].max()


Is this the best way of getting the rated production? If the set point never reaches the actual maximum of the system, is this a problem and could lead to confusing metrics? Legitimately asking, mostly about the generality of this and if it works well in all cases.

Idk a better way - but this is just a pass-through component. In this case, it'd be better for this to be done in the DemandOpenLoopStorageController instead, but then we wouldn't be consistent about whether these outputs are standardized in performance models vs control strategies which would lead to errors if someone used a controller with the standard outputs with a storage model that has the standard outputs. I think issue #498 explains this though.

I don't think we should determine rated production this way. I think both the storage and the controller need to require the technology rated production like we do with other systems. For storage, the charge and discharge rates and the rated storage capacity should be given at a minimum I think now that we are using the set_point paradigm, even for the generic pass-through component.

Does this mean you want the SimpleGenericStorage then to have inputs for charge rate and capacity?

johnjasa · 2026-02-05T17:38:15Z

h2integrate/storage/simple_generic_storage.py

+        # Calculate the total and annual commodity produced
+        outputs[f"total_{self.commodity}_produced"] = outputs[f"{self.commodity}_out"].sum()
+        outputs[f"annual_{self.commodity}_produced"] = outputs[
+            f"total_{self.commodity}_produced"
+        ] * (1 / self.fraction_of_year_simulated)
+
+        # Calculate the maximum commodity production over the simulation
+        max_production = (
+            inputs[f"{self.commodity}_set_point"].max() * self.n_timesteps * (self.dt / 3600)
+        )
+
+        outputs["capacity_factor"] = outputs[f"total_{self.commodity}_produced"] / max_production


Tagging @jaredthomas68 and @genevievestarke for special attention to this math to make sure it matches what you expect.

The capacity factor should be based on rated production in the denominator, not max production. Rated production should be a user input to the system (see previous comment).

Capacity factors for storage systems (at least batteries), as far as I understand, are typically based on the nameplate discharge rate of the system.

cp = total_product_discharged_in_time_period / (name_plate_discharge_rate*time_period_duration) # of course make sure units make sense

Of course, the above leads to some fairly low capacity factors, like about 0.167 for a 4 hour battery discharged daily as discussed in the ATB

@jaredthomas68 - the SimpleGenericStorage has no inputs related to nameplate discharge rate or anything. That information is only available in the DemandOpenLoopStorageController. This is captured in Issue #498.

johnjasa · 2026-02-05T17:39:45Z

h2integrate/storage/simple_storage_auto_sizing.py


-        commodity_production = inputs[f"{commodity_name}_in"]
+        # The commodity_set_point is the production set by the controller
+        commodity_production = inputs[f"{self.commodity}_set_point"]


Given that this might not match the actual production, would desired_commodity_production (or another similar name) be more apt?

johnjasa · 2026-02-05T17:44:57Z

h2integrate/storage/simple_storage_auto_sizing.py

+        self.commodity = self.config.commodity_name
+        self.commodity_rate_units = self.config.commodity_units
+        self.commodity_amount_units = f"({self.commodity_rate_units})*h"


Move this to initialize to match other components?

the tech config is not accessbile at the initialize(). I get this error:
RuntimeError: StorageAutoSizingModel: Option 'tech_config' is required but has not been set.

johnjasa · 2026-02-05T17:45:09Z

h2integrate/storage/simple_generic_storage.py

+        self.commodity = self.config.commodity_name
+        self.commodity_rate_units = self.config.commodity_units
+        self.commodity_amount_units = f"({self.commodity_rate_units})*h"


Move to initialize to match other components?

the tech config is not accessbile at the initialize(). I get this error:
RuntimeError: StorageAutoSizingModel: Option 'tech_config' is required but has not been set.

johnjasa · 2026-02-05T17:45:48Z

h2integrate/storage/simple_generic_storage.py

+    Note: this storage performance model is intended to be used with the
+    `DemandOpenLoopStorageController` controller.


Can it be used with other controllers? Maybe this (or whatever is appropriate)

Suggested change

Note: this storage performance model is intended to be used with the

`DemandOpenLoopStorageController` controller.

Note: this storage performance model is intended to be used with the

`DemandOpenLoopStorageController` controller and has not been tested

with other controllers, but may work.

I don't think it will work with other controllers at all yet, but I would be fine with something close to @johnjasa 's suggestion:

Suggested change

Note: this storage performance model is intended to be used with the

`DemandOpenLoopStorageController` controller.

Note: this storage performance model is intended to be used with the

`DemandOpenLoopStorageController` controller and has not been tested

with other controllers.

johnjasa · 2026-02-05T17:48:09Z

h2integrate/storage/simple_storage_auto_sizing.py

+        # Step 2: Simulate the storage performance based on the sizes calculated
+
+        # Initialize output arrays of charge and discharge
+        discharge_storage = np.zeros(self.n_timesteps)
+        charge_storage = np.zeros(self.n_timesteps)
+        output_array = np.zeros(self.n_timesteps)
+
+        # Initialize state-of-charge value as the soc at t=0
+        soc = deepcopy(commodity_storage_soc[0])
+
+        # Simulate a basic storage component
+        for t, demand_t in enumerate(commodity_demand):
+            input_flow = commodity_production[t]
+            available_charge = float(commodity_storage_capacity_kg - soc)
+            available_discharge = float(soc)
+
+            # If demand is greater than the input, discharge storage
+            if demand_t > input_flow:
+                # Discharge storage to meet demand.
+                discharge_needed = demand_t - input_flow
+                discharge = min(discharge_needed, available_discharge, storage_max_fill_rate)
+                # Update SOC
+                soc -= discharge
+
+                discharge_storage[t] = discharge
+                output_array[t] = input_flow + discharge
+
+            # If input is greater than the demand, charge storage
+            else:
+                # Charge storage with unused input
+                unused_input = input_flow - demand_t
+                charge = min(unused_input, available_charge, storage_max_fill_rate)
+                # Update SOC
+                soc += charge
+
+                charge_storage[t] = charge
+                output_array[t] = demand_t


The overall reason for this code logic to be necessary here is unclear to me. Is it because this component is only meant to be used with the passthrough controller, so we need to actually calculate these charge and discharge timeseries somewhere because it's not done in the controller, and that's here?

This is the biggest question I have where chatting about it might be useful (I just messaged you).

If the dispatch logic is needed, perhaps the sizing should be part of the controller instead of the storage model? @jmartin4u

See issue #498. This PR is not intended to fix the discrepancies between the storage control strategies and the storage performance models, but it sure makes those discrepancies more apparent. I agree that this could be refactored in the future but this PR intended to just make consistent outputs from performance models.

jaredthomas68

Heading in the right direction. We need to correct some math and inputs and also discuss what lives where.

jaredthomas68 · 2026-02-06T21:45:41Z

h2integrate/storage/simple_generic_storage.py

+    Note: this storage performance model is intended to be used with the
+    `DemandOpenLoopStorageController` controller.


I don't think it will work with other controllers at all yet, but I would be fine with something close to @johnjasa 's suggestion:

Suggested change

Note: this storage performance model is intended to be used with the

`DemandOpenLoopStorageController` controller.

Note: this storage performance model is intended to be used with the

`DemandOpenLoopStorageController` controller and has not been tested

with other controllers.

jaredthomas68 · 2026-02-06T21:50:53Z

h2integrate/storage/simple_generic_storage.py

+        # Estimate the rated commodity production as the maximum value from the commodity_set_point
+        outputs[f"rated_{self.commodity}_production"] = inputs[f"{self.commodity}_set_point"].max()


I don't think we should determine rated production this way. I think both the storage and the controller need to require the technology rated production like we do with other systems. For storage, the charge and discharge rates and the rated storage capacity should be given at a minimum I think now that we are using the set_point paradigm, even for the generic pass-through component.

jaredthomas68 · 2026-02-06T21:54:35Z

h2integrate/storage/simple_generic_storage.py

+        outputs[f"total_{self.commodity}_produced"] = outputs[f"{self.commodity}_out"].sum()
+        outputs[f"annual_{self.commodity}_produced"] = outputs[
+            f"total_{self.commodity}_produced"
+        ] * (1 / self.fraction_of_year_simulated)


I think just dividing will be more clear

Suggested change

] * (1 / self.fraction_of_year_simulated)

]/self.fraction_of_year_simulated

jaredthomas68 · 2026-02-06T21:57:01Z

h2integrate/storage/simple_generic_storage.py

+        # Calculate the total and annual commodity produced
+        outputs[f"total_{self.commodity}_produced"] = outputs[f"{self.commodity}_out"].sum()
+        outputs[f"annual_{self.commodity}_produced"] = outputs[
+            f"total_{self.commodity}_produced"
+        ] * (1 / self.fraction_of_year_simulated)
+
+        # Calculate the maximum commodity production over the simulation
+        max_production = (
+            inputs[f"{self.commodity}_set_point"].max() * self.n_timesteps * (self.dt / 3600)
+        )
+
+        outputs["capacity_factor"] = outputs[f"total_{self.commodity}_produced"] / max_production


The capacity factor should be based on rated production in the denominator, not max production. Rated production should be a user input to the system (see previous comment).

jaredthomas68 · 2026-02-06T21:58:40Z

h2integrate/storage/simple_generic_storage.py

+        max_production = (
+            inputs[f"{self.commodity}_set_point"].max() * self.n_timesteps * (self.dt / 3600)
+        )


We should calculate the maximum theoretical production based on name-plate capacity based on the user inputs (see comment above), not the actual in the given scenario as is being done here.

Also see comment below

jaredthomas68 · 2026-02-06T22:10:31Z

h2integrate/storage/simple_generic_storage.py

+        # Calculate the total and annual commodity produced
+        outputs[f"total_{self.commodity}_produced"] = outputs[f"{self.commodity}_out"].sum()
+        outputs[f"annual_{self.commodity}_produced"] = outputs[
+            f"total_{self.commodity}_produced"
+        ] * (1 / self.fraction_of_year_simulated)
+
+        # Calculate the maximum commodity production over the simulation
+        max_production = (
+            inputs[f"{self.commodity}_set_point"].max() * self.n_timesteps * (self.dt / 3600)
+        )
+
+        outputs["capacity_factor"] = outputs[f"total_{self.commodity}_produced"] / max_production


Capacity factors for storage systems (at least batteries), as far as I understand, are typically based on the nameplate discharge rate of the system.

cp = total_product_discharged_in_time_period / (name_plate_discharge_rate*time_period_duration) # of course make sure units make sense

Of course, the above leads to some fairly low capacity factors, like about 0.167 for a 4 hour battery discharged daily as discussed in the ATB

jaredthomas68 · 2026-02-06T22:19:29Z

h2integrate/storage/simple_storage_auto_sizing.py

+        # Step 2: Simulate the storage performance based on the sizes calculated
+
+        # Initialize output arrays of charge and discharge
+        discharge_storage = np.zeros(self.n_timesteps)
+        charge_storage = np.zeros(self.n_timesteps)
+        output_array = np.zeros(self.n_timesteps)
+
+        # Initialize state-of-charge value as the soc at t=0
+        soc = deepcopy(commodity_storage_soc[0])
+
+        # Simulate a basic storage component
+        for t, demand_t in enumerate(commodity_demand):
+            input_flow = commodity_production[t]
+            available_charge = float(commodity_storage_capacity_kg - soc)
+            available_discharge = float(soc)
+
+            # If demand is greater than the input, discharge storage
+            if demand_t > input_flow:
+                # Discharge storage to meet demand.
+                discharge_needed = demand_t - input_flow
+                discharge = min(discharge_needed, available_discharge, storage_max_fill_rate)
+                # Update SOC
+                soc -= discharge
+
+                discharge_storage[t] = discharge
+                output_array[t] = input_flow + discharge
+
+            # If input is greater than the demand, charge storage
+            else:
+                # Charge storage with unused input
+                unused_input = input_flow - demand_t
+                charge = min(unused_input, available_charge, storage_max_fill_rate)
+                # Update SOC
+                soc += charge
+
+                charge_storage[t] = charge
+                output_array[t] = demand_t


If the dispatch logic is needed, perhaps the sizing should be part of the controller instead of the storage model? @jmartin4u

jaredthomas68 · 2026-02-06T22:21:18Z

examples/test/test_all_examples.py

                model.prob.get_val("finance_subgroup_nh3.total_opex_adjusted")[0], rel=1e-6
            )
-            == 79744581.00552343
+            == 79421959.33317558


I don't think the test values should change for these code changes. Maybe you can convince me though. As I see it all the changes should be more a matter of where calculations are done and what components connect to what rather than changing any actual calculations.

…/GreenHEART into converter_baseclass_storage

elenya-grant and others added 30 commits January 20, 2026 15:27

added draft of performance model baseclass to set outputs

a862e69

updated wind models for standardized outputs

bc6a798

minor cleanup to wind pysam

73edcd0

minor cleanup to floris outputs

d3d5616

updated outputs of hydroplant

3a8ad35

updated solar pv models for standardized outputs

682959e

updated solar resource integration tests with updated solar model out…

0aef02a

…puts

added fraction_of_year_simulated attribute to performance baseclass

8f993d4

updated tests for turbine preprocessing tools

a660e21

fixed variable naming in test_all_examples for wind and solar

1f9788a

started updating electrolyzer model outputs

d1f2387

Merge branch 'develop' into converter_baseclass

5db62ae

Merge branch 'converter_baseclass' of github.com:elenya-grant/GreenHE…

f515f5a

…ART into converter_baseclass

minor bugfix to test_sql_timeseries_to_csv for example 2

4227c13

fixed save_case_timeseries_as_csv

ff3de30

update to sql_to_csv function just in case

d84c10a

merged in develop

1169376

added attribute check in PerformanceModelBaseClass

40ae090

typo bugfix in refurb period calc in electrolyzer model

82116bc

added test for solar performance baseclass

08f94ef

merged in develop

7da471c

added solar test to check that all outputs are set in parent class

8df11d0

commented out unused variables in new solar test

5a38e8f

generalized solar unit test so it can be easily used for other compon…

1a51e7b

…ents

updated natural gas plant

3ea3568

started updating co2 models

d02ec1b

updated grid model

e868d82

updated asu model

16a44c5

updated grid tests

d8fda02

updated desal model

c32e752

elenya-grant added 5 commits February 2, 2026 14:54

Merge branch 'converter_baseclass_temp' into converter_baseclass

65b1450

merged in develop

f36cb4d

merged in develop

9a770fd

updated generic storage models and simple controllers

ed4988c

bugfix in simple_storage_autosizing

0cca96d

elenya-grant requested review from genevievestarke and jaredthomas68 February 3, 2026 16:25

elenya-grant added the ready for review This PR is ready for input from folks label Feb 3, 2026

elenya-grant added 6 commits February 3, 2026 10:03

updated test for post-processing timeseries

5d0832a

added subtest for ex 12

0a83daf

updated ex 12 test values

35ab37d

Merge remote-tracking branch 'h2i_upstream/develop' into converter_ba…

16b54d8

…seclass_storage

removed commented out code

6bfdb07

updated changelog

9976fcc

elenya-grant marked this pull request as ready for review February 3, 2026 19:08

elenya-grant requested a review from johnjasa February 3, 2026 19:09

added some comments to generic storage performance models

2ac03d2

elenya-grant mentioned this pull request Feb 3, 2026

Standardize use of controller output commodity_set_point across storage models #498

Open

elenya-grant and others added 2 commits February 3, 2026 14:49

added more inline and docstring comments

6221d3e

Merge branch 'develop' into converter_baseclass_storage

fe991ae

elenya-grant mentioned this pull request Feb 4, 2026

Update ProFAST finance models to use utilization instead of capacity (1 of 3) #485

Open

10 tasks

johnjasa added 2 commits February 5, 2026 11:26

Merge branch 'develop' into converter_baseclass_storage

cbf40b5

Minor refactoring changes for clarity

4804f8b

johnjasa requested changes Feb 5, 2026

View reviewed changes

jaredthomas68 requested changes Feb 6, 2026

View reviewed changes

elenya-grant added 3 commits February 6, 2026 16:01

updated docstring in generic storage

48a20e4

Merge branch 'converter_baseclass_storage' of github.com:elenya-grant…

f80224f

…/GreenHEART into converter_baseclass_storage

updated variable name in simple storage autosizing

078874c

elenya-grant requested review from jaredthomas68 and johnjasa February 6, 2026 23:17

		# Estimate the rated commodity production as the maximum value from the commodity_set_point
		outputs[f"rated_{self.commodity}_production"] = inputs[f"{self.commodity}_set_point"].max()

		Note: this storage performance model is intended to be used with the
		`DemandOpenLoopStorageController` controller.

	] * (1 / self.fraction_of_year_simulated)
	]/self.fraction_of_year_simulated

Conversation

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

Uh oh!

Standardized Performance Outputs: Generic Storage & Control

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 3: Related Issues

Section 4: Impacted Areas of the Software

Section 4.1: New Files

Section 4.2: Modified Files

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

Uh oh!

johnjasa left a comment

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!

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!

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!

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!

jaredthomas68 left a comment

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!

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!

Reviewers

Assignees

Labels

elenya-grant commented Feb 3, 2026 •

edited

Loading