Update Naming Convention in Open-Loop Converter Control Strategies by elenya-grant · Pull Request #631 · NatLabRockies/H2Integrate

elenya-grant · 2026-03-26T21:29:43Z

Update Naming Convention in Open-Loop Converter Control Strategies

NOTE: The intention of this PR is a step in resolving Issue #521. Eventually, the unmet demand and unused commodity calculations done in storage models would instead be done with the use of these demand components (see the follow-on PR, #666). Please keep this in mind when reviewing the new outputs of these models (please see this comment on how that is expected to change)

Update output naming convention in "open-loop converter control strategies" to align with the naming convention of the storage performance models.

f"{commodity}_unmet_demand" -> f"unmet_{commodity}_demand_out"
f"{commodity}_unused_commodity" -> f"unused_{commodity}_out"
Removed output f"total_{commodity}_unmet_demand"
Updated so that these inherit from the PerformanceModelBaseClass

Update as of 04/06/2026:

The above changes motivated a larger discussion around these "open-loop converter control strategies" and how they're actually used/what they were intended for. Some additional context on why these were originally put as "control strategies" is listed in Section 5. But - my motivating philosophy to renaming these classes and moving the files is that these components are not used as controllers and are instead ways of representing some generic demand signal. I think a common push-back on this idea is that demand should come from a converter component, but in some cases, we care more about the demand being met than what the demand is "turned into". For example (a common use-case), defining the energy demand of a data center is important so we can design a system to meet that demand and calculate the cost of energy to meet that demand. We are not trying to calculate the cost of the output from the data center, we only care about the inputs. These demand components are used to define a demand, subtract some initial amount from that demand, and output the remaining and excess demand. The unmet demand from the demand component can then be passed to some converter technology as the demand (example 23 is a good reflection of this). These models are primarily used to calculate demand metrics, not define a control strategy.

I propose the following renaming (already done):

ConverterOpenLoopControlBase -> DemandComponentBase
DemandOpenLoopConverterController -> GenericDemandComponent
FlexibleDemandOpenLoopConverterController -> FlexibleDemandComponent
openloop_controller_base.py -> demand_base.py
demand_openloop_converter_controller.py -> generic_demand.py
flexible_demand_openloop_controller.py -> flexible_demand.py

Other changes:

added compute_outputs() method to the baseclass, which simplified the compute() methods of the two demand components that inherit it
re-classified the demand component as a performance model instead of a control strategy

Questions for reviewers are outlined in Section 2. This is ready for a draft review.

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:

Remove commented out code
update doc pages

Type of Reviewer Feedback Requested (on Draft PR)

Previous feedback - no longer accepting responses

Would it make sense to add the outputs of the PerformanceModelBaseclass to these models? These models are more like ways to represent a generic end-use (or reference signal) rather than actual control strategies. So-if they represent an end-use and we may want to calculate the LCO of the end-use demand, then we'd need these to calculate/output rated commodity capacity and capacity factor.
- I've integrated this for now - would love feedback on how some of the outputs are calculated.
What should commodity_set_point mean with respect to converter controllers? Right now, it's the total commodity out to meet demand (equivalent to commodity_out from storage performance models). I almost think this should be removed as an output and use commodity_out instead. If these are ever being used "as a controller" then it's probably the unmet demand that's being passed to some converter as the demand profile.
- I plan to remove commodity_set_point as an output.
Since the converter openloop control strategies are more like ways to represent an end-use, should these models be moved from control/control_strategies/converters to a different folder (such as):
- transporters/
- transporters/demand/
- converters/end_use/
- demand/ (this is what I went with)
- end_use/
Thoughts on proposed class re-naming:
- ConverterOpenLoopControlBase -> OpenLoopDemandComponentBase OR DemandComponentBase
- DemandOpenLoopConverterController -> GenericDemandComponent
- FlexibleDemandOpenLoopConverterController -> FlexibleDemandComponent
Thoughts on file renaming:
- openloop_controller_base.py -> demand_base.py
- demand_openloop_converter_controller.py -> generic_demand.py
- flexible_demand_openloop_controller.py -> flexible_demand.py

BELOW IS FEEDBACK THAT IS NEWLY REQUESTED

Any feedback on the output calculations (such as capacity factor) for the demand components?

Section 3: General PR Checklist

Section 3: Related Issues

Does not resolve but related to Issue Reconsider storage performance model outputs #521
Created Issue Update/Expand docs for demand components #667 as a reminder to update the doc pages in the future.

Section 4: Impacted Areas of the Software

Moved all the files from h2integrate/control/control_strategies/converters/ to h2integrate/demand/

Section 4.1: New Files

h2integrate/control/test/test_converter_control_strategies.py: new test file for the tests of the DemandOpenLoopConverterController and FlexibleDemandOpenLoopConverterController that previously existed in h2integrate/control/test/test_openloop_controllers.py. This has been moved to h2integrate/demand/test/

Section 4.2: Modified Files

h2integrate/control/control_strategies/converters/demand_openloop_converter_controller.py
- DemandOpenLoopConverterController: renamed outputs, added performance model outputs
h2integrate/control/control_strategies/converters/flexible_demand_openloop_controller.py
- FlexibleDemandOpenLoopConverterController: renamed outputs, added performance model outputs
h2integrate/control/control_strategies/converters/openloop_controller_base.py
- ConverterOpenLoopControlBase: removed total_commodity_unmet_demand from output, updated output naming as outlined in Section 1.

Section 5: Additional Supporting Information

These control strategies were developed during the natural-gas for data-center work. When I initially made what is now the DemandOpenLoopConverterController - I called it a "generic demand component". This was brought into H2I shortly after the DemandOpenLoopStorageController, which, at the time, did similar calculations for unmet demand, excess commodity production, etc. Since the generic demand component had such similarities to the outputs of the DemandOpenLoopStorageController - it was decided to define this as a "converter control strategy".

However, since the work on refactoring the storage dispatch and storage performance models (Issue #564, which most relevantly included PR #566, #498, and #612), the storage controllers no longer output the excess commodity produced or unmet demand, these are done in the storage performance models.

At this stage, there is no similar usage between the DemandOpenLoopStorageController and the DemandOpenLoopStorageController. Therefore, I think that its time to refactor the names of these demand components so that they can be used to resolve Issue #521 and be defined based on their primary usage, which is to calculate demand-related metrics rather than function as a controller.

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

…verter_ol_sync

kbrunik · 2026-03-31T19:14:18Z

"Would it make sense to add the outputs of the PerformanceModelBaseclass to these models?" I think this would be great! and makes them more flexible/similar to other performance models.

genevievestarke

I like having this component inherit the PerformanceModelBaseclass! I think the ultimate goal is to make this its own component and do all the demand-based calculations here. This would move enable these calculations for converter systems, but also move them out of the storage performance models, which will help untangle the system/storage question.
For the second point (and third point), I think that this should be reclassified as a transporter, so that it can output unmet demand (and not a set point). This makes sense to me because it would be used for storage and converters, and it is more of an analysis component (like a combiner) than a control component.

genevievestarke · 2026-04-01T19:55:03Z

h2integrate/demand/generic_demand.py

+        outputs[f"unmet_{self.commodity}_demand_out"] = np.where(
+            remaining_demand > 0, remaining_demand, 0
+        )
+        outputs[f"unused_{self.commodity}_out"] = np.where(
            remaining_demand < 0, -1 * remaining_demand, 0
        )

        # Calculate actual output based on demand met and curtailment


Is this shared between demand_openloop_converter and flexible_demand_openloop_converter? Could we move these to the base class?

No - the demand and flexible demand openloop "controllers" both shared the baseclass ConverterOpenLoopControlBase

oh sorry - totally misunderstood your question. I think that these calculations could be moved to a method in the baseclass

I agree with including set_point, but most of the below calculations don't make sense to me in a controller. I could see it making sense to have a simple converter or end_use component that goes along with the simplistic controller here.

johnjasa · 2026-04-01T20:52:00Z

Would it make sense to add the outputs of the PerformanceModelBaseclass to these models? These models are more like ways to represent a generic end-use (or reference signal) rather than actual control strategies. So-if they represent an end-use and we may want to calculate the LCO of the end-use demand, then we'd need these to calculate/output rated commodity capacity and capacity factor.
I've integrated this for now - would love feedback on how some of the outputs are calculated.

Big fan!

What should commodity_set_point mean with respect to converter controllers? Right now, it's the total commodity out to meet demand (equivalent to commodity_out from storage performance models)

You asking this question made me dig deeper into how I'm viewing these classes, and I realized I might have some potentially conflicting viewpoints. Mainly, this isn't a converter in the way that I initially envisioned them. Specifically, it's not actually converting a commodity, but more tracking it. So I appreciate your question, but I think I agree with @genevievestarke that set_point makes less intuitive sense to me than it could.

That being said, I like the current definition of commodity_set_point being the total commodity to meet demand.

Since the converter openloop control strategies are more like ways to represent an end-use, should these models be moved from control/control_strategies/converters to a different folder (such as):
transporters/
transporters/demand/
converters/end_use/

Would it make sense to add a new folder/category? Something like end_uses at the same level as transporters and converters? I ask that because this is essentially a new area that we might have multiple components joining soon. I was previously thinking things like this would fall under converters (e.g. view a data center as converting electricity into compute) but I'm not necessarily convinced by that organization.

If helpful, I'm happy to chat through this more on a call!

elenya-grant · 2026-04-02T19:44:28Z

@johnjasa @genevievestarke - thanks for the feedback! Quick question:

I almost think commodity_set_point should be removed as an output and we could use commodity_out instead. If these are ever being used "as a controller" then its probably the unmet demand that's being passed to some converter as the demand profile. What are yalls thoughts about that option?

jaredthomas68

I'm not sure I fully understand your plan. As I see it, these components are a mix of control and performance and the two elements should be separated more clearly, not integrated more closely.

I do find the idea of end_use components interesting. I had previously been seeing those as converter that take in resources and output money, or something along those line, but since we are using finance models throughout, the money side is already handled and the end use starts to make more sense to me.

jaredthomas68 · 2026-04-03T18:12:08Z

h2integrate/demand/generic_demand.py

+        outputs[f"unmet_{self.commodity}_demand_out"] = np.where(
+            remaining_demand > 0, remaining_demand, 0
+        )
+        outputs[f"unused_{self.commodity}_out"] = np.where(
            remaining_demand < 0, -1 * remaining_demand, 0
        )

        # Calculate actual output based on demand met and curtailment


I agree with including set_point, but most of the below calculations don't make sense to me in a controller. I could see it making sense to have a simple converter or end_use component that goes along with the simplistic controller here.

…GreenHEART into dispatch/converter_ol_sync

genevievestarke

I agree with making these demand components!
I like DemandComponentBase option for naming. Otherwise, I agree with all the naming suggestions!

genevievestarke · 2026-04-07T15:34:59Z

h2integrate/demand/generic_demand.py

            remaining_demand < 0, -1 * remaining_demand, 0
        )

        # Calculate actual output based on demand met and curtailment
-        outputs[f"{commodity}_set_point"] = (
-            inputs[f"{commodity}_in"] - outputs[f"{commodity}_unused_commodity"]
+        outputs[f"{self.commodity}_out"] = (


would commodity_set_point replace this commodity_out variable, or would there be both?

there would only be commodity_out, which is equivalent to the commodity_out definition in the storage performance models.

genevievestarke · 2026-04-07T15:37:34Z

h2integrate/demand/generic_demand.py

+            outputs[f"total_{self.commodity}_produced"] / self.fraction_of_year_simulated
+        )
+
+        outputs["capacity_factor"] = (


I think that there are more useful outputs we can add rather than the capacity factor. I think things based on the demand would be more useful, like total_unmet_demand and total_demand_met, maybe the capacity factor of the demand, and basing them on demand rather than the rated capacity.

Is this necessary because it's inheriting the performance base class?

The capacity factor is the capacity factor of the demand (total_demand_met/total_demand).
I heard you about those outputs - but I don't see what those outputs would be connected to and they could be easily calculated from the timeseries profiles. So - I think we should add those outputs once they're needed.

…verter_ol_sync

…trategy

kbrunik · 2026-04-08T20:20:46Z

docs/control/control_overview.md

 - [`DemandOpenLoopStorageController`](#demand-open-loop-storage-controller)
- [`DemandOpenLoopConverterController`](#demand-open-loop-converter-controller)
- [`FlexibleDemandOpenLoopConverterController`](#flexible-demand-open-loop-converter-controller)
+- [`GenericDemandComponent`](#demand-open-loop-converter-controller)


I think it would make sense to move the GenericDemandComponent and FlexibleDemandComponent out of the controls portion of the docs and maybe adding it to a new folder called demand?

kbrunik · 2026-04-08T20:21:17Z

docs/control/open-loop_controllers.md

@@ -37,7 +37,7 @@ This page documents two core controller types:

 (demand-open-loop-converter-controller)=
 ### Demand Open-Loop Converter Controller


Looks like this heading could be updated to the new naming

kbrunik · 2026-04-08T20:21:58Z

docs/control/open-loop_controllers.md

@@ -57,19 +57,19 @@ The controller is defined within the `tech_config` and requires these inputs.

 ```yaml
 control_strategy:


Does it still live under control_strategy in the tech_config?

not anymore!

I pulled out the "converter control stuff" from the control_overview.md page and put it in a new page (demand_components). I still need to update the model_overview.md page and the language in the demand_components.md file.

kbrunik · 2026-04-08T20:22:29Z

docs/control/open-loop_controllers.md

    demand_profile: [10, 10, 12, 15, 14]
 ```
-For an example of how to use the `DemandOpenLoopConverterController` open-loop control framework, see the following:
+For an example of how to use the `GenericDemandComponent` open-loop control framework, see the following:


I'd just search for the word control and remove it :)

kbrunik · 2026-04-08T20:23:07Z

docs/user_guide/model_overview.md

 - Converter Controllers:
-    - `'DemandOpenLoopConverterController'`: open-loop control; manages resource flow based on demand constraints
-    - `'FlexibleDemandOpenLoopConverterController'`: open-loop control; manages resource flow based on demand and flexibility constraints
+    - `'GenericDemandComponent'`: open-loop control; manages resource flow based on demand constraints


not open-loop controllers?

kbrunik · 2026-04-08T20:26:19Z

h2integrate/demand/demand_base.py

I like how these were moved to a demand folder and renamed. It makes more sense after all of the dispatch refactor. Thanks @elenya-grant :)

kbrunik · 2026-04-08T20:27:56Z

h2integrate/demand/generic_demand.py


-class DemandOpenLoopConverterController(ConverterOpenLoopControlBase):
+class GenericDemandComponent(DemandComponentBase):
    """Open-loop controller for converting input supply into met demand.


can we update docstring to not say controller? and the description of what it computes?

I think I've updated all the doc strings and inline comments!

kbrunik · 2026-04-08T20:29:22Z

h2integrate/demand/generic_demand.py

-                    * ``{commodity}_out``: Actual output delivered.
+                    * ``unmet_{commodity}_demand_out``: Unmet demand.
+                    * ``unused_{commodity}_out``: Curtailed production.
+                    * ``{commodity}_set_point``: Actual output delivered.


You removed commodity_set_point right?

removed it from the doc string!

kbrunik · 2026-04-08T20:32:31Z

h2integrate/demand/generic_demand.py

        # Calculate actual output based on demand met and curtailment
-        outputs[f"{commodity}_set_point"] = (
-            inputs[f"{commodity}_in"] - outputs[f"{commodity}_unused_commodity"]
+        outputs[f"{self.commodity}_out"] = (


It probably would be helpful to add a description of what commodity_out means in the case of the demand to the docs since it's not particularly intuitive.

kbrunik · 2026-04-08T20:57:13Z

h2integrate/demand/generic_demand.py

        # Calculate actual output based on demand met and curtailment
-        outputs[f"{commodity}_set_point"] = (
-            inputs[f"{commodity}_in"] - outputs[f"{commodity}_unused_commodity"]
+        outputs[f"{self.commodity}_out"] = (


I think I'll add a figure to the docs explaining some of these outputs. And a note about how the CF will be less than one and the edge case about how to account for that.

…GreenHEART into dispatch/converter_ol_sync

kbrunik

Just a few nitpicks but I think this looks great! And thank you for creating issue #667. I will tackle that next week

kbrunik · 2026-04-10T20:23:45Z

docs/demand/demand_components.md

+Demand components define rule-based logic for meeting commodity demand profiles without using dynamic system feedback. These components operate independently at each timestep.
+
+This page documents two core controller types:
+1. Demand Open-Loop Converter Controller — meets a fixed demand profile.


Converter Controller? --> Component?

kbrunik · 2026-04-10T20:25:01Z

docs/demand/demand_components.md

+    commodity_units: kg/h
+    demand_profile: [10, 10, 12, 15, 14]
+```
+For an example of how to use the `GenericDemandComponent` open-loop control framework, see the following:


maybe remove "open-loop control framework"?

kbrunik · 2026-04-10T20:25:49Z

docs/demand/demand_components.md

+
+
+#### Configuration
+The flexible demand controller is defined within the `tech_config` with the following parameters:


Remove controller?

kbrunik · 2026-04-10T20:26:37Z

docs/demand/demand_components.md

+
+```yaml
+model_inputs:
+  control_parameters:


performance_parameters?

kbrunik · 2026-04-10T20:29:42Z

h2integrate/demand/flexible_demand.py

-        commodity = self.config.commodity
-        remaining_demand = inputs[f"{commodity}_demand"] - inputs[f"{commodity}_in"]
+
+        # remaining_demand = inputs[f"{self.commodity}_demand"] - inputs[f"{self.commodity}_in"]


Remove commented code?

kbrunik · 2026-04-10T20:32:13Z

h2integrate/demand/flexible_demand.py

-        outputs[f"{commodity}_set_point"] = (
-            inputs[f"{commodity}_in"] - outputs[f"{commodity}_unused_commodity"]
-        )
+        #     flexible_remaining_demand = flexible_demand_profile - inputs[f"{self.commodity}_in"]


Remove commented code? I'm assuming this is commented out because it moved to the base class?

kbrunik · 2026-04-10T20:32:29Z

h2integrate/demand/generic_demand.py

+        outputs = self.calculate_outputs(
+            inputs[f"{self.commodity}_in"], inputs[f"{self.commodity}_demand"], outputs
+        )
+        # remaining_demand = inputs[f"{self.commodity}_demand"] - inputs[f"{self.commodity}_in"]


Moved to the base class so can be removed?

removed all commented out code and updated the docs and doc-strings to remove the word "control"

genevievestarke

Yay!!

…verter_ol_sync

elenya-grant added 2 commits March 26, 2026 15:17

renamed outputs in converter openloop controllers

1b9f88d

updated tests and examples with updated naming

2b3d0c1

elenya-grant requested review from genevievestarke, jaredthomas68, johnjasa and kbrunik March 27, 2026 16:28

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

2af6329

…verter_ol_sync

elenya-grant added ready for review This PR is ready for input from folks dispatch related to dispatch and control labels Mar 27, 2026

Merge branch 'develop' into dispatch/converter_ol_sync

c59a20e

elenya-grant added 2 commits April 1, 2026 11:39

added performance model outputs to the converter control strategies

eab6d09

udpated plant configs in test_openloop_controllers.py

1e54ed2

genevievestarke reviewed Apr 1, 2026

View reviewed changes

johnjasa and others added 2 commits April 1, 2026 15:52

Merge branch 'develop' into dispatch/converter_ol_sync

1852db4

moved converter control strategies to separate file

b1b62c9

jaredthomas68 reviewed Apr 3, 2026

View reviewed changes

elenya-grant added 4 commits April 6, 2026 10:45

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

elenya-grant requested review from genevievestarke and jaredthomas68 April 6, 2026 17:42

genevievestarke reviewed Apr 7, 2026

View reviewed changes

elenya-grant added 3 commits April 7, 2026 16:40

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

1f71c9d

…verter_ol_sync

renamed demand files

9672ecc

renamed demand classes and configs

7ad7b59

elenya-grant marked this pull request as ready for review April 7, 2026 22:49

kbrunik and others added 2 commits April 8, 2026 14:19

Merge branch 'develop' into dispatch/converter_ol_sync

9ace0ad

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

8444cdf

…trategy

kbrunik requested changes Apr 8, 2026

View reviewed changes

elenya-grant added 4 commits April 8, 2026 15:13

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

elenya-grant mentioned this pull request Apr 10, 2026

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

Open

51 tasks

updated demand docs

f8a55fb

elenya-grant mentioned this pull request Apr 10, 2026

Update/Expand docs for demand components #667

Open

elenya-grant added 2 commits April 10, 2026 11:59

updated changelog

1fb531a

merged changelog

d95950d

elenya-grant requested a review from kbrunik April 10, 2026 18:01

kbrunik approved these changes Apr 10, 2026

View reviewed changes

johnjasa and others added 2 commits April 10, 2026 15:41

Merge branch 'develop' into dispatch/converter_ol_sync

8b46552

removed commented out code and other doc updates

8397cb0

elenya-grant enabled auto-merge (squash) April 10, 2026 20:52

genevievestarke approved these changes Apr 10, 2026

View reviewed changes

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

18ed019

…verter_ol_sync

elenya-grant merged commit f5c1fa6 into NatLabRockies:develop Apr 11, 2026
12 checks passed

		@@ -37,7 +37,7 @@ This page documents two core controller types:

		(demand-open-loop-converter-controller)=
		### Demand Open-Loop Converter Controller

		@@ -57,19 +57,19 @@ The controller is defined within the `tech_config` and requires these inputs.

		```yaml
		control_strategy:



		#### Configuration
		The flexible demand controller is defined within the `tech_config` with the following parameters:

Conversation

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

Uh oh!

Update Naming Convention in Open-Loop Converter Control Strategies

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!

kbrunik commented Mar 31, 2026

Uh oh!

genevievestarke 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!

johnjasa commented Apr 1, 2026

Uh oh!

elenya-grant commented Apr 2, 2026

Uh oh!

jaredthomas68 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

genevievestarke 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!

kbrunik left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

elenya-grant commented Mar 26, 2026 •

edited

Loading