Space Sizing and HVAC Part 4 #10566

mjwitte · 2024-06-17T20:32:40Z

Pull request overview

Fixes Extend Spaces to HVAC #8928
Fixes Extend Spaces to Sizing #8927
Add Zone sizing option for coincident (current method) or non-coincident Space loads.
Add new space sizing (spsz) output file, similar to zone sizing (zsz) output.
Add new SpaceHVAC:ZoneReturnMixer object to mix return air from one or more spaces to a zone return node.
Add Space return air flow calculations.
Builds on several previous PRs:
Transition
Unit tests - see Fix Zone Mixing with Spaces and Space Part 4 Followup #10669
Regression tests

ToDoList for post 24.2-I/O Freeze

Look for other ToDo items from this and prior PRs
Refactor zone equip config return node arrays into a struct

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

Reviewer

This will not be exhaustively relevant to every PR.

amirroth · 2024-06-17T21:39:15Z

Yassssss king! 👑

rraustad · 2024-06-18T02:39:54Z

design/FY2024/NFP-Space Sizing and HVAC-Part4.md

+
+  * Refine existing Space-level HVAC simulation.
+
+  * Extend space HVAC to support more special objects (e.g. ZoneThermalChimney, if budget allows).


A reasonable improvement for spaces. Shouldn't the new field Type of Space Sum to Use include an option to revert back to zone sizing (e.g., None)? and be the default? I guess I'm not clear on what trigger allows spaces, instead of zones, to size zone equipment, and what zone equipment is targeted here.

My thought was that the coincident option would use the current zone (lumped spaces) result.

I should highlight here that the same thermostat setting is applied to the zone and its spaces. So, it's not possible in this plan to have a space within a zone set to a different temperature, for example.

OK, and hopefully sum of space coincident sizing adds up to what zone sizing shows within some small tolerance. I don't see why it wouldn't but you never know (space wall loads?, diffs in window solar gains? etc., but I guess there should still be a similar space sum).

Simple question: If you can sum space loads to currently give a zone load with existing code, with known space fractions of all loads, and that answer is accurate, what benefit would it be to perform sizing on spaces? Wouldn't the space sum just be a sum of the original fractions used to create a zone load? I almost get the non-coincident part but the coincident part seems to mean no space sizing is necessary (i.e., skip it). And it even seems the non-coincident sizing is just a sum of a different time in a series of data, which then would also mean no space sizing is necessary. If coincident gives the same answer as zone sizing then non-coincident just sums data from different times from that same time series data of zone sizing that is fractionally allocated to spaces. So my question is "what is meant by space sizing"? What heat balance will be performed? is it a sum of some fractions of space allocations, or is it an actual heat balance on a space? Which would then be just a subset of zone sizing with known fractions. I'm trying to think of a benefit here but not coming up with a good answer.

Lights, A1 , \field Name A2 , \field Zone or ZoneList or Space or SpaceList Name

Space sizing is an actual heat balance on each space. Currently zone sizing is an actual heat balance on each zone (as a whole) although some of the components for the zone heat balance are sums across the spaces (even when space heat balance is off). e.g. internal gains.

For the coincident zone sizing, I was planning to just use the current lumped zone results rather than combine the space-level results into that. But I should at least check that calculating it from space results would give the same answer. It should be the same since the spaces are all using the same thermostat setpoint. Hmmm, but what if one space is floating while others are calling for cooling, or worse yet, what if one space needs heat and another needs cooling? But conceptually, the zone sizing should be the lumped result when choosing coincident space sums.

I was running 5ZoneAirCooledWithSpacesHVAC last night in 24.1 and looking at results to try to get a better feel for space sizing. I see 5ZoneAirCooledWithSpacesHVACZsz.csv (and Ssz) but no 5ZoneAirCooledWithSpacesHVACSpsz for spaces so I could not see how the space temps reported during the peak time. The space temps during sizing should be at or very near the Tstat temp but if not doing latent sizing w may be very different. Adding latent sizing proved changing zone w didn't change sizing results much. I'm not sure but I wonder if the zone sizing results and the different space fractions of all loads could hold all the info needed for summing/reporting space loads. If space temps are actually different, as I expect they would be, then the heat balance is needed during the simulation but I wonder about sizing. Probably won't save much execution speed so not worth the effort. I just wanted to think through that thought a little while talking about spaces.

Generating 5ZoneAirCooledWithSpacesHVACSpsz output is on the radar for this round.

This reverts commit a93dc1c.

rraustad · 2024-06-20T01:12:04Z

src/EnergyPlus/DataSizing.hh

+        Combination,
+        NA,
+        Num
+    };


You can probably combine these because Combination and NA is not a choice field in Sizing:Zone Type of Space Sum to Use.

Yeah, I did that originally, but then I didn't like it. Do we have other examples of using just a subset of an enum?

I think the best example is the fans. Not all fan types are allowed in all parents yet there is just one enum.

fanCoil.fanType = static_cast<HVAC::FanType>(getEnumValue(HVAC::fanTypeNamesUC, Alphas(9))); enum class FanType { Invalid = -1, Constant, VAV, OnOff, Exhaust, ComponentModel, SystemModel, Num }; constexpr std::array<std::string_view, (int)FanType::Num> fanTypeNames = { "Fan:ConstantVolume", "Fan:VariableVolume", "Fan:OnOff", "Fan:ZoneExhaust", "Fan:ComponentModel", "Fan:SystemModel"};

Here's an option for working with a subset of an enum:

constexpr std::array<bool, (int)FanType::Num> fanTypeInSubset1 = {true, false, true, true, false, false};

Creating multiple enums and then mappings between them is another option, but it's not a good option in my opinion because enums are disjoint types, a variable can only be of one enum type. Better to have a single enum and then implement subsets using either arrays like this or comparison to explicit subsets in the code.

Here is another thing you can do:

constexpr std::array<FanType, 3> fanTypeSubset1 = {FanType::Constant, FanType::OnOff, FanType::Exhaust};

fanTypeInSubset1

Yes, go on . . .

fanTypeInSubset1

Yes, go on . . .

Then you can use either of the two arrays or explicit comparisons to check whether the enum value you get is in Subset1 or not.

rraustad · 2024-06-20T01:17:40Z

src/EnergyPlus/SimAirServingZones.cc

@@ -6540,7 +6540,7 @@ void UpdateSysSizing(EnergyPlusData &state, Constant::CallIndicator const CallIn
            }


If you did combine the enums as I suggested you would need a default here that did nothing or asserted(false).

Maybe that's what I didn't like about a single enum.

…gHVACPart4

rraustad · 2024-07-18T23:58:00Z

src/EnergyPlus/ZoneEquipmentManager.cc

+        zoneCFS.DesCoolVolFlow += spaceCFS.DesCoolVolFlow;
+        zoneCFS.DesCoolLoad += spaceCFS.DesCoolLoad;
+        zoneCFS.DesCoolMassFlow += spaceCFS.DesCoolMassFlow;
+        zoneCFS.DesCoolLoadNoDOAS += spaceCFS.DesCoolLoadNoDOAS;


For the non-coincident case, why is the zone data getting overwritten by the space data? I understand wanting to average the space data in that case but why overwrite to zone data? If the user selects non-coincident sizing the zone sizing information will be lost. If I had seen this I would be more comfortable:

zoneCFS.spaceDesHeatVolFlow += spaceCFS.DesHeatVolFlow; or zoneSpaceCFS.DesHeatVolFlow += spaceCFS.DesHeatVolFlow;

So for the non-coincident case the data written to eplusout.zsz won't be what it was before. I thought there was going to be 2 independent reports for zone and space sizing and those reports could be compared to see how well space sizing agreed with zone sizing.

This might actually be OK because you could compare eplusout.zsz for the coincident and non-coincident cases and if there were no diffs, or very small diffs, then keeping both separate would not be an issue. If there are big diffs then?

I see 0 diffs between coincident and non-coincident results of eplusout.zsz. Carry on (I think I got these diffs right). Not sure if this file has a difference in peak time for non-coincident but at least I see 0 diffs. There are many columns shown on the graph not shown in the legend (e.g., column B to column CC). For non-coincident I added this to the end of Sizing:Zone for each zone:

Sizing:Zone, autosize, !- Dedicated Outdoor Air High Setpoint Temperature for Design {C} , , , , , , , , , NonCoincident; !- Type of Space Sum to Use

5ZoneAirCooledWithSpaceHeatBalance-epluszsz.zip

The current logic is this:

Let existing code calculate the space sizing and coincident zone sizing (i.e. lump spaces together for the zone sizing).

If non-coincident sizing is selected for a given zone, then override the zone sizing results based on the sums/averages of spaces in that zone.

However, if the zone only has one space, then skip the override and keep the original results. That's why you didn't seen any diffs in 5ZoneAirCooledWithSpaceHeatBalance (it's only got one space per zone).

Here's the zsz files for 5ZoneAirCooledWithSpacesHVAC. There are differences for zones 3 and 5. Looks like the peaks are not correct, however - the difference in peaks shouldn't be greater than the hourly diffs.
5ZoneAirCooledWithSpacesHVAC-NonCoincident.zip

This logic seems sound. I don't see the problem with non-coincident vs zone sizing as you mentioned. I was worried that overwriting data may cover up an issue but the user can always compare coincident vs non-coincident to verify results.

I still need to figure out what to do with peak date/time. I guess I can scan the non-coincident zone seqs?

But those could have come from different design days for each space, hmm.

…gHVACPart4

mjwitte

Code walkthru - part 1

mjwitte · 2024-08-12T19:19:37Z

idd/Energy+.idd.in

   A2,  \field Zone Name
-        \note Name of zone that is the thermal chimney
+        \note Name of zone that is the thermal chimney.


Because the thermal chimney is a special zone, only accept a zone name here, not a space name.

mjwitte · 2024-08-12T19:20:09Z

idd/Energy+.idd.in

@@ -24889,16 +24894,17 @@ ZoneThermalChimney,
        \minimum 0
        \maximum 1
        \default 0.8
-   A4, \field Zone 1 Name
+   A4,  \field Zone or Space Name 1


But allow the chimney to draw from either a single space or a full zone.

mjwitte · 2024-08-12T19:21:04Z

idd/Energy+.idd.in

@@ -34523,6 +34548,12 @@ Sizing:Zone,
      \note no humidistat is associated with this zone.
      \type alpha
      \units percent
+  A15;\field Type of Space Sum to Use


New field in Sizing:Zone for coincident/nonincident option.

mjwitte · 2024-08-12T19:21:24Z

idd/Energy+.idd.in

@@ -50789,6 +50820,59 @@ SpaceHVAC:ZoneEquipmentMixer,
       \note Matches a SpaceHVAC:EquipmentConnections Exhaust Node Name
       \type node

+SpaceHVAC:ZoneReturnMixer,


New object for space return air modeling.

mjwitte · 2024-08-12T19:22:22Z

idd/Energy+.idd.in

@@ -107248,117 +107332,122 @@ OutputControl:Files,
       \key Yes
       \key No
       \default Yes
-  A9 , \field Output Zone Sizing
+  A9 , \field Output Space Sizing


New output file for space sizing spsz, equivalent to zsz output. This new field inserted in OutputControl:Files triggers a transition rule.

mjwitte · 2024-08-12T19:38:44Z

src/EnergyPlus/DataZoneEquipment.hh

    Array1D<DataZoneEquipment::EquipConfiguration> ZoneEquipConfig;
-    EPVector<DataZoneEquipment::EquipConfiguration> spaceEquipConfig;
+    Array1D<DataZoneEquipment::EquipConfiguration> spaceEquipConfig;


Make this the same type as ZoneEquipConfig so they can be passes as a parameter to a common function.

mjwitte · 2024-08-12T19:40:23Z

src/EnergyPlus/IOFiles.cc

@@ -376,6 +376,9 @@ void IOFiles::OutputControl::getInput(EnergyPlusData &state)
            { // "output_audit"
                audit = boolean_choice(find_input(fields, "output_audit"));
            }
+            { // "output_space_sizing"
+                spsz = boolean_choice(find_input(fields, "output_space_sizing"));


Adding a new output file touched a surprising number of places in the code.

mjwitte · 2024-08-12T19:41:43Z

src/EnergyPlus/ReportCoilSelection.cc

-        } else {
-            c->coilSizingMethodConcurrenceName = "N/A";
-        }
+        c->coilSizingMethodConcurrenceName = DataSizing::CoilSizingConcurrenceNames[(int)c->coilSizingMethodConcurrence];


Just some cleanups for the new enums.

mjwitte · 2024-08-12T19:44:08Z

src/EnergyPlus/SimAirServingZones.cc

+                if (CoolDDNum == 0) {
+                    auto &zoneCFS = state.dataSize->CalcFinalZoneSizing(state.dataSize->TermUnitFinalZoneSizing(TermUnitSizingIndex).ZoneNum);
+                    OutAirTemp += zoneCFS.CoolOutTemp * coolMassFlow / (1.0 + termUnitSizing.InducRat);
+                    OutAirHumRat += zoneCFS.CoolOutHumRat * coolMassFlow / (1.0 + termUnitSizing.InducRat);


For zone sizing that is the non-coincident total of space sizes, there isn't necessarily the same design day across all spaces, so use zone outdoor conditions here instead of design day weather data as below.

mjwitte · 2024-08-12T19:44:46Z

src/EnergyPlus/SizingManager.cc

@@ -240,7 +240,16 @@ void ManageSizing(EnergyPlusData &state)
            state.files.zsz.filePath = state.files.outputZszTxtFilePath;
        }

+        if (state.dataSize->SizingFileColSep == CharComma) {


More code for the new file.

mjwitte

Code walkthru - part 2

mjwitte · 2024-08-12T19:48:49Z

src/EnergyPlus/ZoneEquipmentManager.cc

-void updateZoneSizingEndZoneSizingCalc1(EnergyPlusData &state, DataSizing::ZoneSizingData const &zsCalcSizing)
+void updateZoneSizingEndZoneSizingCalc1(EnergyPlusData &state, int const zoneNum)
+{
+    // Set or override finalzonesizing data for non-coincident sizing


This function is the crux of the non-coincident sizing option. The regular old coincident sizing is always calculated. If the zone is set for non-coincident and has more than one space, then new values are calculated for non-coincident sizing which overwrite the original coincident results.

mjwitte · 2024-08-12T19:50:33Z

src/EnergyPlus/ZoneEquipmentManager.cc

@@ -1956,23 +2304,258 @@ void updateZoneSizingEndZoneSizingCalc1(EnergyPlusData &state, DataSizing::ZoneS
                              "flow calculations");
        }
    }
+    zsCalcSizing.HeatPeakDateHrMin = zsCalcSizing.cHeatDDDate + ' ' + sizingPeakTimeStamp(state, zsCalcSizing.TimeStepNumAtHeatMax);


Moved these to a one-time call.

mjwitte · 2024-08-12T19:51:47Z

src/EnergyPlus/ZoneEquipmentManager.cc

-    // SpaceSizing TODO: There's gotta be a better place to set these timestamps
-    if (timeStepIndex == zsCalcSizing.TimeStepNumAtHeatMax) {
-        zsCalcSizing.HeatPeakDateHrMin = zsCalcSizing.cHeatDDDate + ' ' + format(PeakHrMinFmt, hourPrint, minutes);


Not checking anymore for TimeStepNumA*Max while cycling through all of the timesteps.

mjwitte · 2024-08-12T19:52:34Z

src/EnergyPlus/ZoneEquipmentManager.cc

+    return format(PeakHrMinFmt, hour, minute);
+}
+
+void writeZszSpsz(EnergyPlusData &state,


Shared function to write either zsz or spsz output file.

mjwitte · 2024-08-12T19:53:09Z

src/EnergyPlus/ZoneEquipmentManager.cc

                    }
                }
            }

-            // SpaceSizing TODO: For now only write zone-level zsz


Moved to new function.

mjwitte · 2024-08-12T19:54:05Z

src/EnergyPlus/ZoneEquipmentManager.cc

@@ -4540,7 +4908,7 @@ void CalcZoneMassBalance(EnergyPlusData &state, bool const FirstHVACIteration)
            }

            Real64 FinalTotalReturnMassFlow = 0;
-            CalcZoneReturnFlows(state, ZoneNum, StdTotalReturnMassFlow, FinalTotalReturnMassFlow);
+            zoneEquipConfig.calcReturnFlows(state, StdTotalReturnMassFlow, FinalTotalReturnMassFlow);


Moved to a method so this can be shared by zoneEquipConfig and spaceEquipConfig.

mjwitte · 2024-08-12T19:54:52Z

src/EnergyPlus/ZoneEquipmentManager.cc

@@ -4726,182 +5094,6 @@ void CalcZoneMassBalance(EnergyPlusData &state, bool const FirstHVACIteration)
    }
 }

-void CalcZoneReturnFlows(EnergyPlusData &state,


Moved to method in DataZoneEquipment

mjwitte · 2024-08-12T19:56:10Z

tst/EnergyPlus/unit/DesiccantDehumidifiers.unit.cc

@@ -2898,7 +2898,7 @@ TEST_F(EnergyPlusFixture, DesiccantDehum_OnOASystemTest)
    auto &finalSysSizing = state->dataSize->FinalSysSizing(1);
    auto &sysSizPeakDDNum = state->dataSize->SysSizPeakDDNum(1);
    EXPECT_ENUM_EQ(finalSysSizing.coolingPeakLoad, DataSizing::PeakLoad::SensibleCooling);
-    EXPECT_EQ(finalSysSizing.SizingOption, DataSizing::NonCoincident);
+    EXPECT_ENUM_EQ(finalSysSizing.SizingOption, DataSizing::SizingConcurrence::NonCoincident);


At this point, all unit test changes are simply updates to work with other codes changes (new enums, new function names, etc.).

…gHVACPart4

mjwitte · 2024-08-19T01:26:52Z

Table diffs are due to new object/fields. e.g.

Otherwise, diffs are expected for 5ZoneAirCooledWithSpacesHVAC.idf because the idf has been changed by adding a SpaceHVAC:ZoneReturnMixer.

For the latest commit, not sure why there are Mac API and integration test failures.

Myoldmopar · 2024-08-19T16:12:47Z

I'm not sure why it had failed before either. I'm lightly concerned as to why. But moving on. This looks clean now outside of needing to resolve the transition md conflict. I'll tackle that and push up the change now. This is also on the glide path so if anyone wants to hold this up, speak up.

Myoldmopar · 2024-08-19T16:27:09Z

Okie dokie, conflict resolved and this is ready to go, I'll let CI do a little bit, but this is about to go in with a flurry of merges.

Myoldmopar · 2024-08-19T17:36:42Z

And now this one. Yet another conflict??

Myoldmopar · 2024-08-19T17:39:21Z

Merged on the web, I'll do a sanity check here now but this will likely merge in a few minutes.

Myoldmopar · 2024-08-19T17:42:14Z

All happy, merging before Decent picks it back up.

Space IV-Initial NFP

8338dcb

mjwitte added NewFeature Includes code to add a new feature to EnergyPlus IDDChange Code changes impact the IDD file (cannot be merged after IO freeze) labels Jun 17, 2024

rraustad reviewed Jun 18, 2024

View reviewed changes

mjwitte added 7 commits June 18, 2024 19:08

sizing Concurrence enum

dd05f9b

Fix and rollback

c8aa4b3

Revert format disagreement

4449ccb

Space IV-New Sizing:Zone coincidence input

62ef539

Space IV-Revert scope creep

a93dc1c

Revert "Space IV-Revert scope creep"

1e66702

This reverts commit a93dc1c.

Space IV-YetAnotherEnum attempt

5ffdf05

rraustad reviewed Jun 20, 2024

View reviewed changes

mjwitte added 12 commits June 21, 2024 13:21

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

925b4ee

…gHVACPart4

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

8419656

…gHVACPart4

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

e14f948

…gHVACPart4

Streamline sizing peak timestamps plus etc

1c11d89

Space IV-Add Spsz output

d68a756

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

1a7ba87

…gHVACPart4

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

23a9057

…gHVACPart4

Space IV-Non-coincident 1

324f1fc

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

855bf74

…gHVACPart4

Space IV-Non-coincident 2

4f6b677

Space IV-Non-coincident 3 repairs

340cc89

Space IV-Non-coincident 4

0c5b4ba

rraustad reviewed Jul 18, 2024

View reviewed changes

mjwitte added 3 commits July 24, 2024 15:13

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

baee11d

…gHVACPart4

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

c5284ee

…gHVACPart4

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

e89f96e

…gHVACPart4

mjwitte added 9 commits August 2, 2024 11:11

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

8152108

…gHVACPart4

Space IV-Final NFP and Design

f1cb19f

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

a710348

…gHVACPart4

Space IV-ZoneRefrigerationDoorMixing

390e393

Space IV-ZoneRefrigerationDoorMixing

8d8fec6

Space IV-ZoneCoolTowerShower

2a966e9

Space IV-ZoneThermalChimney

cebfcb5

Space IV-SpaceHVACZoneReturnMixer

57a62ce

Space IV-SpaceHVACZoneReturnMixer 2

fd2a28f

mjwitte marked this pull request as ready for review August 12, 2024 15:29

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

d531db2

…gHVACPart4

mjwitte commented Aug 12, 2024

View reviewed changes

mjwitte added 6 commits August 12, 2024 15:55

Space IV-Transition etc

58aa2f9

Space IV-Update 5ZoneAirCooledWithSpacesHVAC

3ccf6e5

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

cce4ecd

…gHVACPart4

Space IV-SpaceHVACZoneReturnMixer 3

5e85740

Merge remote-tracking branch 'remotes/origin/develop' into SpaceSizin…

11eb39f

…gHVACPart4

SpaceReturnMixerTest

be14c93

Merge develop, resolve tiny conflict

498a892

Merge branch 'develop' into SpaceSizingHVACPart4

254ccce

Myoldmopar merged commit a59d0b6 into develop Aug 19, 2024
10 checks passed

Myoldmopar deleted the SpaceSizingHVACPart4 branch August 19, 2024 17:42

mjwitte mentioned this pull request Aug 20, 2024

ZoneCrossMixing and ZoneMixing vector error when source is a zone and space heat balance is active #10670

Closed

3 tasks


		* Refine existing Space-level HVAC simulation.

		* Extend space HVAC to support more special objects (e.g. ZoneThermalChimney, if budget allows).

		@@ -6540,7 +6540,7 @@ void UpdateSysSizing(EnergyPlusData &state, Constant::CallIndicator const CallIn
		}

Space Sizing and HVAC Part 4 #10566

Space Sizing and HVAC Part 4 #10566

Conversation

mjwitte commented Jun 17, 2024 • edited Loading

Pull request overview

ToDoList for post 24.2-I/O Freeze

Pull Request Author

Reviewer

amirroth commented Jun 17, 2024

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 Jun 20, 2024 • edited Loading

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

rraustad Jul 19, 2024 • edited Loading

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

mjwitte 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

mjwitte 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

mjwitte commented Aug 19, 2024

Myoldmopar commented Aug 19, 2024

Myoldmopar commented Aug 19, 2024

Myoldmopar commented Aug 19, 2024

Myoldmopar commented Aug 19, 2024

Myoldmopar commented Aug 19, 2024

mjwitte commented Jun 17, 2024 •

edited

Loading

amirroth Jun 20, 2024 •

edited

Loading

rraustad Jul 19, 2024 •

edited

Loading