Remove system-level outputs from storage and replace with demand component (follow-on to 631) by elenya-grant · Pull Request #666 · NatLabRockies/H2Integrate

elenya-grant · 2026-04-10T17:00:00Z

Remove system-level outputs from storage and replace with demand component (follow-on to 631)

There has been a blurry line distinguishing system-level calculations and calculations done in storage performance models. This PR builds on PR #631 to resolve Issue #521. The storage performance outputs that depend on demand have been removed and the usage of demand components in the examples is more common. The outputs removed from storage performance models are:

unmet_{commodity}_demand_out: demand that has not been met
unused_{commodity}_out: production that exceeds the demand
storage_{commodity}_out: charge/discharge profile

The outputs with different calculations in the storage performance models are:

{commodity}_out: this used to be the combined commodity out from storage and whatever was input to storage, minus any production that exceeds the demand. This is now what storage_{commodity}_out used to be
capacity_factor: used to be the based on the combined commodity out, now it based on the sum of the charge/discharge profile

This PR helps to better distinguish the differences between individual storage performance models and "system-level" performance calculations. This PR also enables the ability for the storage demand to be distinct from the overall demand. For example, if we wanted to use a battery to try to just keep an electrolyzer system on (at 10% power), then the demand profile to the battery would be 10% of the electrolyzer capacity, whereas the demand for the demand component would be equal to the electrolyzer capacity.

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:

Get PR Update Naming Convention in Open-Loop Converter Control Strategies #631 merged in
Update storage_baseclass.py so that demand is only an input if using feedback control (not doing just yet)
make figures to show what's happening in demand components for different use-cases
- these figures have been added to docs/demand/demand_components.md
add test to test_all_examples for example 13
update or add doc page for example 13 in controller docs

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

Other feedback:

Section 3: General PR Checklist

Section 3: Related Issues

This would resolve Issue #521

Section 4: Impacted Areas of the Software

Section 4.1: New Files

examples/13_dispatch_for_electrolyzer/: new example that highlights setting the storage demand as a different value than the demand component.
resource_files/wind/30.6617_-101.7096_2013_wtk_v2_60min_utc_tz.csv: wind resource file for example 23
docs/demand/demand_demo.md: new doc page for Example 13 that highlights use of demand components.
docs/technology_models/storage_models_index.md: new doc page describing the inputs and output calculations of the storage performance models.

Section 4.2: Modified Files

h2integrate/core/h2integrate_model.py
- create_finance_model(): Updated logic so that any model without a cost model does not have to be included in the technologies list for a finance group. Was previously hard-coded so that only combiners didn't have to be included in the technologies list.
h2integrate/storage/storage_baseclass.py: modified StoragePerformanceBase
- setup(): removed outputs related to demand
- run_storage(): removed calculations of outputs related to demand. Updated calculation of capacity factor.
examples/test/test_all_examples.py::test_ng_demand_example: new test for Example 23
examples/test/test_all_examples.py::::test_electrolyzer_demand: new test for Example 13

Examples that were updated

Examples that had added combiners to combine storage outputs with the input to storage: 01, 02, 03/co2_hydrogenation_doc, 09/doc, 09/oae, 30
Examples that had added combiners and load demand components: 12, 16, 24, 30
Examples that had storage models as commodity streams (required additional combiner(s) and a new load demand component): 14, 18, 19, 29

Tests that were updated

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

h2integrate/core/test/test_framework.py::test_system_order
h2integrate/core/test/test_framework.py::test_technology_connections

Section 7 (Optional): New Model Checklist

…verter_ol_sync

…GreenHEART into dispatch/converter_ol_sync

…verter_ol_sync

…trategy

…GreenHEART into dispatch/converter_ol_sync

…eam in finances

…ance subgroup

bayc · 2026-04-13T19:37:21Z

@elenya-grant Trying to look through this, and wondering if you can put together a diagram or figure showing the inputs/outputs of the current system and proposed solution? Would help a lot to see what the differences are.

Thanks for adding the plots! That definitely helps me understand what the code is doing, which is moving the difference calculations out of the storage model. I think these outputs were originally developed with converters in mind as well and trying to apply the same set of inputs/outputs across technologies to be able to easily know how much of a commodity was consumed and how much, if any, demand is left unmet after sequentially working through each component.

My understanding now is that the difference calculations are being moved to demand components, and agree with @kbrunik that it would be helpful to see this built out in an example, so supportive of that! This would help me understand any other impacts to the dispatch/control flow and demand passing through converters as well.

genevievestarke

Overall, I think this looks really good! Great progress on this, @elenya-grant ! I have a few comments, and I'd like to look at the final docs pages when they're ready, as well :)

examples/13_dispatch_for_electrolyzer/plant_config.yaml

genevievestarke · 2026-04-13T22:15:36Z

examples/13_dispatch_for_electrolyzer/run_dispatch_for_electrolyzer.py

+
+electrolyzer_capacity_MW = 60
+h2i.prob.set_val("battery.electricity_demand", 0.1 * electrolyzer_capacity_MW, units="MW")
+h2i.prob.set_val("elec_load_demand.electricity_demand", electrolyzer_capacity_MW, units="MW")


Ooooh, nice, I really like this example!

h2integrate/demand/flexible_demand.py

genevievestarke · 2026-04-13T22:20:53Z

h2integrate/storage/storage_baseclass.py

        # Performance model outputs
        outputs[f"rated_{self.commodity}_production"] = discharge_rate
-        outputs[f"total_{self.commodity}_produced"] = np.sum(total_commodity_out)
+        outputs[f"total_{self.commodity}_produced"] = np.sum(storage_commodity_out)


I think this should be based just on the sum of storage discharge (otherwise you'll get a very small number).

for sure! I hear you - the benefit of this method is that, suppose we have something a system that has technology connections that look like this:

technology_interconnections: # combine the generation and input it to the battery - [wind, gen_combiner, electricity, cable] - [pv, gen_combiner, electricity, cable] - [gen_combiner, battery, electricity, cable] # combine the battery output with the wind and solar generation - [battery, elec_combiner, electricity, cable] - [gen_combiner, elec_combiner, electricity, cable]

Then, it's nice because it follows the same logic as the converters and the following two things are equal:

tot_electricity_out = model.prob.get_val("battery.total_electricity_produced") + model.prob.get_val("wind.total_electricity_produced") + model.prob.get_val("wind.total_electricity_produced") assert tot_electricity_out == model.prob.get_val("elec_combiner.electricity_out").sum()

I'd be interested to hear what other folks think.

I think this gets to Jared's comment in #521 to have "outputs of commodity flows mutually exclusive and collectively exhaustive" and it's nice to have the storage not output values from other components.

I see your reasoning @elenya-grant and I think it works for your use case. My concern is that the capacity factor is based on the total commodity production, but a storage systems capacity factor is calculated based only on discharge and divided by possible discharged continuously. If we make sure the capacity factor calculation is being handled correctly, then I think I'm ok with the positive and negative included in the sum. We will need to be very clear about its meaning in docs and doc strings. I am still concerned about the misleading name "produced" when the sum includes commodity used.

Okay - so I think the main question is whether aggregated outputs from the storage models (annual_commodity_produced, total_commodity_produced, and capacity_factor) should be based on either 1) charge and discharge profile or 2) just the discharge profile.

My main concern is with the capacity factor, since that's passed to combiners and is a metric used in finance calculations. I don't have strong feelings about annual_commodity_produced and total_commodity_produced, since those are more useful as "summary outputs" and not used in downstream models.

If storage model outputs are based on the charge and discharge profile - then this is similar to how converter outputs are calculated wrt the commodity_out profile (nice). But - if the battery charges more than discharges, then we would have negative values (could cause problems). If the outputs are negative though - then I think produced makes sense in the name.

If storage model outputs are based only on the discharge profile - then we'd always have positive outputs, but we couldn't sum these together with the converter technologies like I mentioned above. Aka - it'd require special treatment of converter technologies.

Regardless of what we decide, I will update the doc page for the storage performance models to detail how these calculations are done.

Larger question that I think would help us figure out what direction to go in. How would you calculate the capacity factor of a wind+battery system?

wind_aep = sum(wind_generation) wind_cf = wind_aep/(wind_capacity*8760) # Like below? hybrid_cf = sum(wind_generation)/(8760*(wind_capacity + battery_discharge_rate))

I think it is important to keep standard procedures. I also think we can just take the positive part of the commodity out for all techs and divide by their nameplate capacity and then the capacity factor calculation will be the same for all technologies.

cf = sum(positive(commodity out)/(rate unit rating * hours in year)

From the NLR ATB:

"Capacity Factor

The cost and performance of the battery systems are based on an assumption of approximately one cycle per day. Therefore, a 4-hour device has an expected capacity factor of 16.7% (4/24 = 0.167), and a 2-hour device has an expected capacity factor of 8.3% (2/24 = 0.083). Degradation is a function of the usage rate of the model, and systems might need to be replaced at some point during the analysis period. We use the capacity factor for a 4-hour device as the default value for ATB because 4-hour durations are anticipated to be more typical in the utility-scale market.

The hybrid capacity factor is an important question. I do want to avoid having our own internal definition of capacity factor, but I also see the utility of @elenya-grant's proposal for using positive and negative in the CF calc

I added standard_capacity_factor as an output that uses the equation @jaredthomas68 proposed. This is documented in the new storage doc page docs/technology_models/storage_models_index.md. Please let me know your thoughts.

genevievestarke · 2026-04-13T22:23:19Z

h2integrate/control/test/test_openloop_controllers.py

 )


+def calculate_combined_outputs(storage_charge_discharge, commodity_in, commodity_demand):


I think this makes sense to keep the tests the same, but maybe as a future PR we can think about whether we need to calculate all of these for the controller tests. (Or just test these for the controllers by themselves)

I agree - it was only necessary because most of the subtests were on these variables that are now calculated in demand components - but I agree.

calculate_combined_outputs may be better placed in tools.py or similar instead of copying it around to various scripts. I also hesitate to base so many tests on a function, but it would be rather clunky to store values for all of these.

I agree with @genevievestarke that we should remove tests on values not calculated by these components any more, but in a future PR.

It could have been my fault in the merge too, sorry if this isn't used any more

I think that maybe we revisit this in a future PR. the options are:

update the tests to test different outputs (don't test the unmet demand, excess commodity, etc)

keep the tests as-is and move the calculate_combined_outputs to conftest.py?

update the tests to use a demand component for the calculations instead of calculate_combined_outptus

Decided we're going to do the first option in a future PR. made Issue #676

… feedback control

kbrunik

Thanks @elenya-grant! I think this PR helps continue to clarify/separate "storage" models from non-storage/more generic things like the controls logic and the demand. I like that none of the actual calculations/test values changed in this PR just mostly reorganizing and adding some sweeeeet docs. I have a few non-blocking comments but I'd love if you'd take a look and respond to them before merging.

docs/control/controller_demonstrations.md

kbrunik · 2026-04-14T01:59:43Z

docs/demand/figures/flex_demand_fig.png

Looking at this figure, the red is really hard to see even for a color seeing person. I realize this isn't a new addition in this PR but do we have to code to maybe change to color and that wouldn't be too hard? If the answer is no then don't do it.

I don't remember where the code is that I had to make this figure initially - so - I can try to re-make it but it'd take 30min+

docs/demand/demand_components.md

kbrunik · 2026-04-14T02:02:57Z

docs/demand/figures/demand_calcs.png

are the added figures color-blind friendly?

I'm not sure...could you suggest some colors that you'd like instead?

Noted in Issue #667

kbrunik · 2026-04-14T02:03:22Z

docs/demand/demand_components.md

I think these figures really help illustrate what the calculations are doing :) thank you!

kbrunik · 2026-04-14T02:08:30Z

docs/demand/demand_demo.md

+```{code-cell} ipython3
+electrolyzer_capacity_MW = 60
+
+# Set the battery demand equal to the minimum electricity needed to keep the electrolyzer on


Wait, didn't you already set this in the tech_config?

yes - I may have pushed up changes since your comment (the line numbers are confusing me). Before the part where I call set_val() now - I have this line:

If we wanted to change the demand profiles for the battery (battery) or the demand component (elec_load_demand) to be different than the demand profiles specified in the technology config, we can do that using set_val:

commented out the python code in that section but left the note so folks understand.

kbrunik · 2026-04-14T02:10:26Z

docs/demand/demand_demo.md

+```
+
+
+Plot the battery performance:


Sick plot!!!!

docs/demand/demand_demo.md

kbrunik · 2026-04-14T02:17:11Z

resource_files/wind/30.6617_-101.7096_2013_wtk_v2_60min_utc_tz.csv

Was there not an existing wind resource file that worked for this example?

unfortunately no.. I don't like that I had to add it either (it was for example 23, not the new example I added). I can change the location to a location that we already have weather data files for and remove this - I was just trying to not change example 23 too much.

kbrunik · 2026-04-14T02:27:09Z

h2integrate/control/test/test_openloop_controllers.py

 )


+def calculate_combined_outputs(storage_charge_discharge, commodity_in, commodity_demand):


It could have been my fault in the merge too, sorry if this isn't used any more

jaredthomas68

This is looking pretty good. I think it makes operation more transparent to the users and will allow more flexibility ultimately. I do have a few comments/changes. My biggest concern is that the storage capacity factor be calculated correctly.

jaredthomas68 · 2026-04-13T23:37:39Z

docs/demand/demand_demo.md

This is a very nice demo, well done putting this together!

jaredthomas68 · 2026-04-13T23:38:02Z

docs/demand/demand_demo.md

+
+The following example is an expanded form of `examples/13_dispatch_for_electrolyzer`.
+
+The technology interconnections:


I think the user would benefit from an xdsm diagram here.

heard - how do I make that?

We could use the built-in XDSM-maker in H2I, callable via create_xdsm on the H2IntegrateModel object.
Or, we could use pyXDSM manually like I did for this above.
@jaredthomas68, is this in line with what you're thinking? What would you change?

Yes, that is exactly what I was thinking. It would be nice to use the built-in method as part of the example, but all I was asking for is including the figure to visualize the connections.

thanks! I added it in

jaredthomas68 · 2026-04-13T23:44:20Z

docs/demand/demand_demo.md

+ax.set_ylim([0, 70])
+ax.legend(bbox_to_anchor=(1.0, 0.5), loc="center left", borderaxespad=0, framealpha=0.0)
+ax.set_ylabel("Electricity (MW)")
+ax.set_xlabel("Time (hours)")


You did a very nice job with the figures in this page. Clean and clear. Non-blocking suggestion here, but I would like to see the storage SOC and charge and discharge plots directly. I think it would make the storage operation a little more clear.

jaredthomas68 · 2026-04-13T23:47:25Z

examples/03_methanol/co2_hydrogenation_doc/plant_config_co2h.yaml

+  # combine the h2 from the electrolyzer and the h2_storage
+  - [electrolyzer, h2_combiner, hydrogen, pipe]
+  - [h2_storage, h2_combiner, hydrogen, pipe]
+  # connect the h2 supply to the methanol system
+  - [h2_combiner, methanol, hydrogen, pipe]
+  # connect the doc to co2 storage
  - [doc, co2_storage, co2, pipe]
-  - [co2_storage, methanol, co2, pipe]
+  # combine the co2 from the doc and the co2_storage
+  - [doc, co2_combiner, co2, pipe]
+  - [co2_storage, co2_combiner, co2, pipe]
+  # connect the co2 supply to the methanol system
+  - [co2_combiner, methanol, co2, pipe]


I am a little concerned with the amount of connections needed here, but I don't think it can be helped if we are going to move demand outside of storage, which I do see value in.

jaredthomas68 · 2026-04-13T23:58:46Z

h2integrate/control/test/test_openloop_controllers.py

 )


+def calculate_combined_outputs(storage_charge_discharge, commodity_in, commodity_demand):


calculate_combined_outputs may be better placed in tools.py or similar instead of copying it around to various scripts. I also hesitate to base so many tests on a function, but it would be rather clunky to store values for all of these.

jaredthomas68 · 2026-04-14T00:00:18Z

h2integrate/control/test/test_openloop_controllers.py

 )


+def calculate_combined_outputs(storage_charge_discharge, commodity_in, commodity_demand):


I agree with @genevievestarke that we should remove tests on values not calculated by these components any more, but in a future PR.

jaredthomas68 · 2026-04-14T15:13:52Z

h2integrate/storage/simple_storage_auto_sizing.py

+        if isinstance(self.demand_profile, list | np.ndarray):
+            user_input_dmd = True if sum(self.demand_profile) > 0 else False
+        else:
+            user_input_dmd = True if self.demand_profile > 0 else False
+


np.sum works on scalars and array-like. Also, the comment was confusing to me. Also, what if
user defines a negative profile?

Suggested change

if isinstance(self.demand_profile, list | np.ndarray):

user_input_dmd = True if sum(self.demand_profile) > 0 else False

else:

user_input_dmd = True if self.demand_profile > 0 else False

# Check for user-define demand profile

user_input_dmd = True if np.sum(self.demand_profile) > 0 else False

Thanks on the suggestion - I will push up that change shortly (also with an updated comment).

The question of a negative demand profile is interesting - that is something that we don't have a way of handling for any converter model that can take demand as an input or in the demand components. I think that we should discuss how we'd want to handle that and make a separate PR with whatever route seems best.

jaredthomas68 · 2026-04-14T15:25:11Z

h2integrate/storage/storage_baseclass.py

        # Performance model outputs
        outputs[f"rated_{self.commodity}_production"] = discharge_rate
-        outputs[f"total_{self.commodity}_produced"] = np.sum(total_commodity_out)
+        outputs[f"total_{self.commodity}_produced"] = np.sum(storage_commodity_out)


I see your reasoning @elenya-grant and I think it works for your use case. My concern is that the capacity factor is based on the total commodity production, but a storage systems capacity factor is calculated based only on discharge and divided by possible discharged continuously. If we make sure the capacity factor calculation is being handled correctly, then I think I'm ok with the positive and negative included in the sum. We will need to be very clear about its meaning in docs and doc strings. I am still concerned about the misleading name "produced" when the sum includes commodity used.

…GreenHEART into storage/standalone_outputs

…ferences

elenya-grant and others added 27 commits March 26, 2026 15:17

renamed outputs in converter openloop controllers

1b9f88d

updated tests and examples with updated naming

2b3d0c1

Merge remote-tracking branch 'h2i_upstream/develop' into dispatch/con…

2af6329

…verter_ol_sync

Merge branch 'develop' into dispatch/converter_ol_sync

c59a20e

added performance model outputs to the converter control strategies

eab6d09

udpated plant configs in test_openloop_controllers.py

1e54ed2

Merge branch 'develop' into dispatch/converter_ol_sync

1852db4

moved converter control strategies to separate file

b1b62c9

Merge branch 'dispatch/converter_ol_sync' of github.com:elenya-grant/…

a97292c

…GreenHEART into dispatch/converter_ol_sync

moved converter control strategies to demand folder

2d6b0c5

updated import paths for demand components

0e6b3e8

removed commodity_set_point as output

2986dff

Merge remote-tracking branch 'h2i_upstream/develop' into dispatch/con…

1f71c9d

…verter_ol_sync

renamed demand files

9672ecc

renamed demand classes and configs

7ad7b59

Merge branch 'develop' into dispatch/converter_ol_sync

9ace0ad

renamed demand component to be performance model instead of control s…

8444cdf

…trategy

moved output calculations to shared method in baseclass

2093b81

Merge branch 'dispatch/converter_ol_sync' of github.com:elenya-grant/…

1510bd2

…GreenHEART into dispatch/converter_ol_sync

removed the word controller from docstrings

d116ad8

draft update to docs

7c5b9e5

removed system level calcs from storage and updated most tests

1046419

updated optimal controller tests

65dc07b

updated example 1 and 2

89a4ced

updated examples 1, 2, and 12

5032e41

updated examples with storage but dont use storage as a commodity_str…

24cb283

…eam in finances

updated examples with storage defined as a commodity_stream for a fin…

92d9854

…ance subgroup

elenya-grant requested review from jaredthomas68, johnjasa and kbrunik April 10, 2026 17:00

elenya-grant added 2 commits April 13, 2026 13:34

added test for example 23

738173c

added example for different demand between storage and demand component

eaa17e8

elenya-grant added 4 commits April 13, 2026 14:17

added subtests for example 13

75fa5f5

minor update to controller_demonstrations doc page to use EXAMPLE_DIR

a01b5af

added wind resource file for example 23

5a510aa

added demo for the demand components using example 13

21082b7

elenya-grant requested a review from kbrunik April 13, 2026 22:02

fixed demand_demo.md

9ecd357

genevievestarke reviewed Apr 13, 2026

View reviewed changes

elenya-grant and others added 3 commits April 13, 2026 16:51

made it so demand is only input to battery performance model if using…

6ebd865

… feedback control

typo fix in example 13 plant config

ed710a5

Merge branch 'develop' into storage/standalone_outputs

46116b6

kbrunik approved these changes Apr 14, 2026

View reviewed changes

kbrunik added the ready for review This PR is ready for input from folks label Apr 14, 2026

jaredthomas68 requested changes Apr 14, 2026

View reviewed changes

elenya-grant added 11 commits April 14, 2026 10:34

minor changes to docs and some logic based on feedback

0c9c665

Merge branch 'storage/standalone_outputs' of github.com:elenya-grant/…

6308329

…GreenHEART into storage/standalone_outputs

added battery performance plots to demand demo

6720139

added subtests for example and minor updates based on feedback

34f5a8c

added xdsm to demand_demo doc page

41a177b

added standard_capacity_factor as output from storage

864b124

minor updates to example 13 subtests

ff1b98c

make some subtests more loose because of floating point precision dif…

62347b5

…ferences

added doc page for storage performance models

98047ec

added subtests for capacity factor calcs and minor update to docs

0704c24

minor update to example tests

15e7573

elenya-grant requested review from genevievestarke and jaredthomas68 April 14, 2026 22:15

elenya-grant mentioned this pull request Apr 14, 2026

Update controller tests to not depend on calculate_combined_outputs function #676

Open

		)


		def calculate_combined_outputs(storage_charge_discharge, commodity_in, commodity_demand):


		The following example is an expanded form of `examples/13_dispatch_for_electrolyzer`.

		The technology interconnections:

Conversation

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

Uh oh!

Remove system-level outputs from storage and replace with demand component (follow-on to 631)

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

Examples that were updated

Tests that were updated

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

Uh oh!

bayc commented Apr 13, 2026

Uh oh!

genevievestarke left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

elenya-grant Apr 14, 2026 • edited by johnjasa 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!

elenya-grant Apr 13, 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!

elenya-grant Apr 14, 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!

kbrunik left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

elenya-grant commented Apr 10, 2026 •

edited

Loading

elenya-grant Apr 14, 2026 •

edited by johnjasa

Loading

elenya-grant Apr 13, 2026 •

edited

Loading

elenya-grant Apr 14, 2026 •

edited

Loading

elenya-grant Apr 14, 2026 •

edited

Loading