HVAC Enumerations #10499

amirroth · 2024-05-09T15:57:36Z

This is a small-ish PR that converts most of the remaining constexpr ints in the HVAC module (the artist formerly known as DataHVACGlobals) to enumerations. The one holdover is CoilType which will be more complex to tackle because it is implicated in several partially-overlapping quasi-enumerations. This change affected a good number of function APIs, especially via the FanOp enumeration, and spotlighted a number of instances of brittle code and potential bugs.

Making availability status into an enumeration required unifying SystemAvailabiltyManager and PlantAvailabilityManager to eliminate a circular dependency between the two. I took this opportunity to do some cleanup on the SystemAvailabilityManager module, although stopped short of a fan-style class-hierarchy refactor. Maybe later. In the meantime, I renamed the new joint module Avail. You're welcome.

I folded in two other minor clean-ups. First, there was some improper use of passing scalars (int and Real64) by const reference. Only objects should be passed this way. Passing an object by const reference prevents the function from making a local copy of the object. But for a scalar, making a local copy of the variable has the same cost as grabbing the reference, but it also has the downside of adding another pointer to the mix and potentially disabling some compiler optimizations as a result (compilers hate pointers) and there is an example of this in code.

Second, there is an epJSON field-map pattern that goes like this:

if (objFields.find('x') != objFields.end()) 
    thisObj.field = objFields.at('x').get<Real64>();

This idiom is doing a find twice because at itself does a find. A better idiom is:

if (auto it = objField.find('x'); it != objFields.end())
    thisObj.field = it.value().get<Real64>();

I will annotate some of the other changes in the code walkthrough.

CI is green except for CustomCheck and clang-format. The CustomCheck complaint should be silenced, but I don't know how to do that.

amirroth

Walk through.

amirroth · 2024-05-09T16:01:52Z

src/EnergyPlus/AirflowNetwork/src/Solver.cpp

            allocated(m_state.dataAirSystemsData->PrimaryAirSystems)) {
            hybrid_ventilation_control();
        }
-        if (VentilationCtrl == 1 && m_state.dataHVACGlobal->NumHybridVentSysAvailMgrs > 0) {
+        if (ventCtrlStatus == Avail::VentCtrlStatus::Open && m_state.dataAvail->NumHybridVentSysAvailMgrs > 0) {


This was a problem even before the conversion to an enumeration. There was a constexpr int HybridVentCtrl_Open which should have been used instead. Changing to an enumeration forces us to use the symbol instead of the literal.

Question: if NumHybridVentSysAvailMgrs == 0, how can ventCtrlStatus == Avail::VentCtrlStatus::Open ?

Don't look at me, I just search and replace.

amirroth · 2024-05-09T16:03:59Z

src/EnergyPlus/Coils/CoilCoolingDX.cc

@@ -416,7 +416,7 @@ void CoilCoolingDX::oneTimeInit(EnergyPlusData &state)
    SetupOutputVariable(state,
                        "Cooling Coil Dehumidification Mode",
                        Constant::Units::None,
-                        this->dehumidificationMode,
+                        (int &)this->dehumidificationMode,


Have to do this upcast (it's safe) for doing a SetupOutputVariable on enumerations.

amirroth · 2024-05-09T16:06:41Z

src/EnergyPlus/Coils/CoilCoolingDX.cc

        numModes++;
    }
    return numModes;
 }

-int CoilCoolingDX::getOpModeCapFTIndex(bool const useAlternateMode)
+int CoilCoolingDX::getOpModeCapFTIndex(HVAC::CoilMode const mode)


This is an example of brittle code. Using the CoilMode as a bool relies on the fact that Normal is zero. Don't obfuscate. If you are trying to distinguish between Normal mode and the other modes just make that comparison directly.

amirroth · 2024-05-09T16:08:55Z

src/EnergyPlus/DXCoils.cc

@@ -130,10 +130,10 @@ using namespace ScheduleManager;

 void SimDXCoil(EnergyPlusData &state,
               std::string_view CompName,                    // name of the fan coil unit
-               HVAC::CompressorOperation const CompressorOp, // compressor operation; 1=on, 0=off
+               HVAC::CompressorOp const compressorOp, // compressor operation; 1=on, 0=off


Don't use Operation when Op will do. In general, I am confounded by the choice of which names to contract and which not. Anyways.

Why doesn't that logic apply to Compressor? CompOp. I'm trying to think of anything else in HVAC that could be a Comp. HVAC:Component, HVAC:Company, nope, it's a compressor.

Comp is used for Component extensively in the code.

amirroth · 2024-05-09T16:09:38Z

src/EnergyPlus/DXCoils.cc

@@ -502,7 +502,7 @@ void SimDXCoilMultiMode(EnergyPlusData &state,
        S12EvapCondPumpElecPower = 0.0;

        thisDXCoil.DehumidificationMode = DehumidMode;
-        if (DehumidMode > thisDXCoil.NumDehumidModes) {
+        if ((int)DehumidMode > thisDXCoil.NumDehumidModes) {


This is also brittle but I am not going to deal with it now.

amirroth · 2024-05-09T16:28:54Z

src/EnergyPlus/HVACVariableRefrigerantFlow.hh

@@ -72,6 +72,14 @@ struct EnergyPlusData;

 namespace HVACVariableRefrigerantFlow {

+    // Parameters describing variable refrigerant flow terminal unit types
+    enum class TUType


Only used in this module so moved from HVAC to here.

amirroth · 2024-05-09T16:34:20Z

src/EnergyPlus/Photovoltaics.hh

@@ -135,8 +135,8 @@ namespace Photovoltaics {
                Real64 &XX,
                std::function<Real64(EnergyPlusData &state, Real64 const, Real64 const, Real64 const, Real64 const, Real64 const, Real64 const)> FXX,
                std::function<Real64(EnergyPlusData &state, Real64 const, Real64 const, Real64 const, Real64 const, Real64 const)> DER,
-                Real64 const &II, // Autodesk Aliased to XX in some calls
-                Real64 const &VV, // Autodesk Aliased to XX in some calls
+                Real64 const &II, // Autodesk Aliased to XX in some calls, this is absolutely wacky and needs to go


I know that I said that passing scalar parameters by const ref is a bad idea but I am leaving this here for now. The reason is that in some calls of this function the same variable is passed through two parameters, via XX by reference and via VV or II by const reference. The function relies on the fact that when the variable is changed via XX, the change is reflected in VV or II. Because of this possibility, expressions using VV and II cannot be optimized. And they could not be optimized even if the function was never called with the same variable used for multiple reference arguments. This function needs to be rewritten to avoid this behavior.

amirroth · 2024-05-09T16:35:34Z

src/EnergyPlus/StandardRatings.cc

@@ -1481,23 +1481,23 @@ namespace StandardRatings {
    void CalcTwoSpeedDXCoilRating(EnergyPlusData &state,
                                  std::string const &DXCoilName,
                                  std::string const &DXCoilType,
-                                  int const &DXCoilType_Num,
+                                  int const DXCoilType_Num,


Here are the examples of const reference parameters that should be converted to value parameters. I think I made this comment on the PR, but it was ignored.

amirroth · 2024-05-09T16:36:29Z

src/EnergyPlus/StandardRatings.cc

-                                                                  const Real64 &RatedCOP,
-                                                                  const Real64 &EIRFlowModFac,
-                                                                  DataHeatBalance::RefrigCondenserType const &CondenserType)
+                                                                  const int CapFTempCurveIndex,


Good grief.

amirroth · 2024-05-09T16:37:33Z

src/EnergyPlus/UnitarySystem.cc

                    if (Util::SameString(loc_m_SingleModeOp, "Yes")) thisDesignSpec.m_SingleModeFlag = true;
                }

-                if (fields.find("no_load_supply_air_flow_rate_ratio") != fields.end()) { // not required field
-                    thisDesignSpec.noLoadAirFlowRateRatio = fields.at("no_load_supply_air_flow_rate_ratio").get<Real64>();
+                if (auto it = fields.find("no_load_supply_air_flow_rate_ratio"); it != fields.end()) { // not required field


New pattern to replace find('x') followed by at('x').

mjwitte · 2024-05-09T21:12:05Z

src/EnergyPlus/Coils/CoilCoolingDXCurveFitPerformance.hh

-                  int useAlternateMode,
+                  HVAC::CoilMode coilMode,


This needs some followup. coilMode implies this is the current operating mode of the coil, but it is really more like highestAvailableCoilMode. it's just being used to know if CoilCoolingDXCurveFitPerformance::alternateMode and alternateMode2 are defined for this coil.

The actual timestep level operating mode is CoilCoolingDX::dehumidificationMode.

And there are functions like CoilCoolingDX::getNumModes that only returns a value of 1 or 2, not 3. Maybe it's not needed where it's currently used, but it's confusing as-is.

Okay, what is the concrete suggestion?

Change the name of the enumeration from CoilMode to DehumMode?

Change the name of this variable from coilMode to dehumMode?

Change something else?

Some combination of 1, 2, and 3?

I am okay with whatever except for implicitly using an enumeration as a boolean.

So, coilMode is replacing hasAlternateMode How about availableCoilMode or maxAvailCoilMode?

Or just make it int numModes.

Actually, I looked again and in this function coilMode is actually used like the name suggests, there is a case for each one of the modes. So I vote to just leave this as is.

But it is the current mode?

if (state.dataCoilCooingDX->coilCoolingDXs[this->m_CoolingCoilIndex].SubcoolReheatFlag) { OperationMode = DataHVACGlobals::coilSubcoolReheatMode; } else if (this->m_DehumidificationMode == 1) { OperationMode = DataHVACGlobals::coilEnhancedMode; } bool const singleMode = (this->m_SingleMode == 1); state.dataCoilCooingDX->coilCoolingDXs[this->m_CoolingCoilIndex].simulate( state, OperationMode, PartLoadFrac, this->m_CoolingSpeedNum, this->m_CoolingSpeedRatio, this->m_FanOpMode, singleMode);

OK, I agree with @mjwitte. This doesn't change during the simulation.

if (!this->performance.original_input_specs.base_operating_mode_name.empty() && !this->performance.original_input_specs.alternate_operating_mode_name.empty() && !this->performance.original_input_specs.alternate_operating_mode2_name.empty()) { this->SubcoolReheatFlag = true; }

rraustad · 2024-05-10T00:51:57Z

src/EnergyPlus/Autosizing/CoolingCapacitySizing.cc

@@ -488,7 +488,7 @@ Real64 CoolingCapacitySizer::size(EnergyPlusData &state, Real64 _originalValue,
                if (this->autoSizedValue > 0.0) {
                    RatedVolFlowPerRatedTotCap = DesVolFlow / this->autoSizedValue;
                }
-                if (RatedVolFlowPerRatedTotCap < state.dataHVACGlobal->MinRatedVolFlowPerRatedTotCap(state.dataHVACGlobal->DXCT)) {
+                if (RatedVolFlowPerRatedTotCap < HVAC::MinRatedVolFlowPerRatedTotCap[(int)state.dataHVACGlobal->DXCT]) {


Checked and this looks correct.

rraustad · 2024-05-10T01:03:07Z

src/EnergyPlus/Autosizing/CoolingSHRSizing.cc

+                        if (RatedVolFlowPerRatedTotCap > HVAC::MaxRatedVolFlowPerRatedTotCap[(int)state.dataHVACGlobal->DXCT]) {
+                            this->autoSizedValue = 0.389 + 7684.0 * HVAC::MaxRatedVolFlowPerRatedTotCap[(int)state.dataHVACGlobal->DXCT];
+                        } else if (RatedVolFlowPerRatedTotCap < HVAC::MinRatedVolFlowPerRatedTotCap[(int)state.dataHVACGlobal->DXCT]) {
+                            this->autoSizedValue = 0.389 + 7684.0 * HVAC::MinRatedVolFlowPerRatedTotCap[(int)state.dataHVACGlobal->DXCT];
                        } else {
                            this->autoSizedValue = 0.389 + 7684.0 * RatedVolFlowPerRatedTotCap;
                        }


Note: these are identical except for the coefficients. e.g,:

constexpr std::array<Real64, 2> VolFlowPerRatedTotCapCoeff0 = {0.431, 0.389); constexpr std::array<Real64, 2> VolFlowPerRatedTotCapCoeff1 = {6086.0, 7684.0);

rraustad · 2024-05-10T01:09:13Z

src/EnergyPlus/Coils/CoilCoolingDX.cc

@@ -575,15 +575,15 @@ void CoilCoolingDX::oneTimeInit(EnergyPlusData &state)
 int CoilCoolingDX::getNumModes()
 {
    int numModes = 1;
-    if (this->performance.hasAlternateMode) {
+    if (this->performance.coilMode != HVAC::CoilMode::Normal) {
        numModes++;
    }


This looks sound.

if (!input_data.alternate_operating_mode_name.empty() && input_data.alternate_operating_mode2_name.empty()) { this->hasAlternateMode = DataHVACGlobals::coilEnhancedMode; if (!input_data.alternate_operating_mode2_name.empty() && !input_data.alternate_operating_mode_name.empty()) { this->hasAlternateMode = DataHVACGlobals::coilSubcoolReheatMode;

rraustad · 2024-05-10T01:19:13Z

src/EnergyPlus/Coils/CoilCoolingDX.cc


    // set condenser inlet/outlet nodes
    // once condenser inlet is connected to upstream components, will need to revisit
-    condInletNode.MassFlowRate = this->condMassFlowRate(useAlternateMode);
+    condInletNode.MassFlowRate = this->condMassFlowRate(coilMode);


This one hurts my brain. Are there only 2 modes allowed?

Real64 CoilCoolingDX::condMassFlowRate(bool const useAlternateMode) { if (useAlternateMode) { return this->altModeNomSpeed().RatedCondAirMassFlowRate; } else { return this->normModeNomSpeed().RatedCondAirMassFlowRate; } }

That function looks like this now:

Real64 CoilCoolingDX::condMassFlowRate(HVAC::CoilMode const mode) { if (mode != HVAC::CoilMode::Normal) { return this->altModeNomSpeed().RatedCondAirMassFlowRate; } else { return this->normModeNomSpeed().RatedCondAirMassFlowRate; } }

This was an example of using an integer enumeration as a boolean. Tut tut. One advantage of using real enumerations is that they don't implicitly cast to booleans (or to anything else for that matter).

That wasn't my point. There are only 2 choices yet there are three possible modes for subcool. This comment is outside the scope of these changes and I don't even know if my comment is correct. It's just that something looks odd.

That's why we need some followup on this in a separate PR. There's confusion between the former hasAlternateMode which was only used to track if one or both alternate modes were present vs the former useAlternateMode and dehumidificationMode which indicated the current operating mode on each call. Some functions expect 3 variants, but some like CoilCoolingDX::condMassFlowRate only expect two. Maybe that's correct, maybe not. The use of each one will need to be examined.

Well, you can now easily find these four functions as they are the only ones that have HVAC::CoilMode parameters.

rraustad · 2024-05-10T01:29:14Z

src/EnergyPlus/Coils/CoilCoolingDX.cc

@@ -837,7 +837,7 @@ void CoilCoolingDX::simulate(EnergyPlusData &state,
            Real64 dummyPLR = 1.0;
            int dummySpeedNum = 1;
            Real64 dummySpeedRatio = 1.0;
-            int dummyFanOpMode = 1.0;
+            HVAC::FanOp dummyFanOp = HVAC::FanOp::Cycling;


Interesting use of dummy nodes to report out a coil size. Does using the actual coil nodes cause diffs?

I didn't write this code. Just changed from int to enumeration.

rraustad · 2024-05-10T01:31:59Z

src/EnergyPlus/Coils/CoilCoolingDX.hh

-    int getOpModeCapFTIndex(bool useAlternateMode = false);
-    Real64 condMassFlowRate(bool useAlternateMode);
+    int getOpModeCapFTIndex(HVAC::CoilMode mode = HVAC::CoilMode::Normal);
+    Real64 condMassFlowRate(HVAC::CoilMode mode);


This does look better.

rraustad · 2024-05-10T01:38:01Z

src/EnergyPlus/Coils/CoilCoolingDXCurveFitPerformance.cc

            this->alternateMode.size(state);
        }
-        if (this->hasAlternateMode == HVAC::coilSubcoolReheatMode) {
+        if (this->coilMode == HVAC::CoilMode::SubcoolReheat) {
            this->alternateMode.size(state);
            this->alternateMode2.size(state);
        }


So here if hasAlternateMode == coilEnhanceMode call one size function. If coilSubcoolReheatMode call 2 size functions. That just feels odd. I digress.

Breaking news, EnergyPlus is odd!

rraustad · 2024-05-10T02:01:18Z

src/EnergyPlus/Coils/CoilCoolingDXCurveFitSpeed.hh

@@ -164,7 +164,7 @@ struct CoilCoolingDXCurveFitSpeed
                         const DataLoopNode::NodeData &inletNode,
                         DataLoopNode::NodeData &outletNode,
                         Real64 &PLR,
-                         int const fanOpMode,
+                         HVAC::FanOp const fanOp,


Up to here things look OK (and only thru the C's). There are some comments (follow up, thoughts, etc.) but not related to these changes. I would rather see smaller scope of changes cause this is hard to review.

I don't think you really need to review this line by line, do you? Most of the changes are either actual search-and-replace or de facto search and replace like this one.

Basically, I change all of the constexpr ints to their corresponding enumerations using global search-and-replace (using sed if you are curious how). Then I compile. All of the int variables and parameters that those get assigned to show up as errors, I change all of those to the enumerated type and recompile. Then all of the variables and parameters that those things get assigned to show up as errors, and I change those types and recompile. After four of five passes of this, everything settles down.

I guess I could have done this one enumeration at a time and submitted eight PRs, but that felt like a waste of time.

TL;DR sorry. If you want to stop now, it's probably fine. Everything is green.

Myoldmopar · 2024-05-13T15:50:43Z

Alright, now custom check and clang format came back all happy as well as all the Decent builds. I'll take a look in here, but as this shouldn't be making big functional changes, I'll try not to get stuck in the weeds.

Myoldmopar

This is a nice cleanup, thanks @amirroth. I am not 100% sure where the coil mode comments landed, so I'll wait for a final 👍 from @mjwitte / @rraustad on that, or soon I'll dig in deeper to help resolve it if needed.

Myoldmopar · 2024-05-13T16:40:42Z

src/EnergyPlus/CMakeLists.txt

@@ -473,7 +473,6 @@ set(SRC
    Plant/LoopSidePumpInformation.hh
    Plant/MeterData.hh
    Plant/MixerData.hh
-    Plant/PlantAvailManager.hh


Always great to see.

amirroth · 2024-05-13T16:52:00Z

This is a nice cleanup, thanks @amirroth. I am not 100% sure where the coil mode comments landed, so I'll wait for a final 👍 from @mjwitte / @rraustad on that, or soon I'll dig in deeper to help resolve it if needed.

I think we landed on @mjwitte's recommendation, which I will implement and commit now. I can leave some TODO comments too so that these three functions can be revisited later if needed.

…obals2

rraustad · 2024-05-14T13:34:02Z

src/EnergyPlus/Coils/CoilCoolingDXCurveFitPerformance.cc

@@ -219,7 +219,7 @@ void CoilCoolingDXCurveFitPerformance::simulate(EnergyPlus::EnergyPlusData &stat
    this->recoveredEnergyRate = 0.0;
    this->NormalSHR = 0.0;

-    if (useAlternateMode == HVAC::coilSubcoolReheatMode) {
+    if (coilMode == HVAC::CoilMode::SubcoolReheat) {


Why did this compile? should be maxAvailCoilMode? I'm getting confused whether this is max modes or operating mode.

This should be fine here, but I'm not sure the right spots were changed in a096252. I'll review shortly.

Why did this compile? should be maxAvailCoilMode? I'm getting confused whether this is max modes or operating mode.

It compiled because this is a method and there is a member named coilMode (remember, this-> is optional). I think you just found the reason for the diff.

This is one of the reasons why you need to have a different naming convention for local variables and member variables.

mjwitte · 2024-05-15T16:40:14Z

@amirroth @rraustad coilMode is replaced with currentCoilMode (passed in) and 'maxAvailCoilMode`. A little wordy, but should lessen the confusion. Also added some TODO comments for followup. I'm done tweaking things here.

@Myoldmopar CI is all green.

amirroth · 2024-05-15T17:44:24Z

src/EnergyPlus/UnitarySystem.cc

-                                                                                                                            : cobj.get<Real64>();
+                                    (cobj.type() == nlohmann::detail::value_t::string && Util::SameString(cobj.get<std::string>(), "Autosize"))
+                                        ? DataSizing::AutoSize
+                                        : cobj.get<Real64>();


Thanks @mjwitte. Not sure where I got the other pattern.

Also, I feel like I should follow Mr. Lohmann and introduce an aroth namespace into EnergyPlus. That would be a power move.

Myoldmopar · 2024-05-22T17:55:25Z

This is great! I'll do just a sanity build of it with latest develop, but then this can merge in.

Myoldmopar · 2024-05-23T15:00:10Z

Pulled develop in one more time here just for fun and it builds happily and runs all tests happily. Merging this now, thanks @amirroth

amirroth added 15 commits May 1, 2024 21:18

FanOp enumeration

df1ae62

More enumerations

0754861

More enumerations and some json find-at dedup

a76785c

Removing a file that snuck in there

5b6bd62

Remove bad const refs to scalars

b893c8c

More enumerations

551136f

Fix some issues

f9564dc

AvailStatus enumeration

ee906c6

Merge remote-tracking branch 'origin/develop' into HVACGlobals2

75ab122

Merge develop, remove PlantAvailManager.hh

1ffa812

Fix makefile

afa7c57

Fix hybrid vent issue

3f41d92

Merge remote-tracking branch 'origin/develop' into HVACGlobals2

661a199

Merge develop, fix unit compiler error (hopefully)

29520d9

Minor cleanup

afe4640

amirroth commented May 9, 2024

View reviewed changes

amirroth requested review from Myoldmopar, mjwitte and rraustad May 9, 2024 16:39

amirroth self-assigned this May 9, 2024

amirroth added DoNotPublish Includes changes that shouldn't be reported in the changelog Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring labels May 9, 2024

amirroth added this to the EnergyPlus 24.2 milestone May 9, 2024

mjwitte reviewed May 9, 2024

View reviewed changes

rraustad reviewed May 10, 2024

View reviewed changes

Myoldmopar added 3 commits May 12, 2024 19:35

Merge remote-tracking branch 'origin/develop' into HVACGlobals2

12e8e2c

Apply Clang Format

e38e525

Add UnitarySysType to ignore list in enum check script

7f780a8

Myoldmopar reviewed May 13, 2024

View reviewed changes

amirroth added 2 commits May 13, 2024 12:59

Address comments

a096252

Merge branch 'HVACGlobals2' of github.com:NREL/EnergyPlus into HVACGl…

a39dc4d

…obals2

rraustad reviewed May 14, 2024

View reviewed changes

amirroth and others added 4 commits May 14, 2024 10:05

Fix booboo

c6ec3f1

Attempt final answer for coilMode

b224bc2

Fix availManager call

b231ed3

Fix autosize json failure on windows

4473e9c

amirroth commented May 15, 2024

View reviewed changes

Myoldmopar merged commit 77d3641 into develop May 23, 2024
15 checks passed

Myoldmopar deleted the HVACGlobals2 branch May 23, 2024 15:00

HVAC Enumerations #10499

HVAC Enumerations #10499

Conversation

amirroth commented May 9, 2024 • edited

amirroth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amirroth May 10, 2024 • edited

Choose a reason for hiding this comment

rraustad May 10, 2024 • edited

Choose a reason for hiding this comment

rraustad May 10, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Myoldmopar commented May 13, 2024

Myoldmopar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amirroth commented May 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mjwitte commented May 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Myoldmopar commented May 22, 2024

Myoldmopar commented May 23, 2024

amirroth commented May 9, 2024 •

edited

amirroth May 10, 2024 •

edited

rraustad May 10, 2024 •

edited

rraustad May 10, 2024 •

edited