Improved Support for Multi-speed Fans #9746

lgu1234 · 2022-11-18T18:59:30Z

Pull request overview

Allow multiple supply air flow ratio to be added to the ZoneHVAC:WaterToAirHeatPump and ZoneHVAC:TerminalUnit:VariableRefrigerantFlow objects. In simulation, for each time step, the fan air flow shall cycle between adjacent speeds based on the cooling / heating capacity (or coordinate with the cooling / heating coil stage for variable speed water to air coils).

NOTE: ENHANCEMENTS MUST FOLLOW A SUBMISSION PROCESS INCLUDING A FEATURE PROPOSAL AND DESIGN DOCUMENT PRIOR TO SUBMITTING CODE

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.

mjwitte · 2022-11-30T18:34:27Z

design/FY2023/NFP_MultispeedFans.md

+
+<span style="color:red">
+
+An alternative way is to use the existing object of UnitarySystemPerformance:Multispeed. Since this object is not used only for UnitarySystem, the name of the object may be changed.


@lgu1234 I would support changing the existing object name rather than making a new object. Of course, that will require a transition rule for the existing field in AirloopHVAC:UnitarySystem.

mjwitte · 2022-11-30T18:35:44Z

design/FY2023/NFP_MultispeedFans.md

+       \memo operating speed. This object is primarily used for ZoneHVAC:WaterToAirHeatPump and 
+       \memo ZoneHVAC:TerminalUnit:VariableRefrigerantFlow objects to allow operation at 
+       \memo different fan flow rates.
+       \extensible:2 - repeat last two fields, remembering to remove ; from "inner" fields.


@rraustad If this object is truly extensible, then the fields for Number of Speeds for Heating/Cooling should not have \maximum declared in the IDD.

mjwitte · 2022-11-30T18:39:16Z

design/FY2023/NFP_MultispeedFans.md

+       \note Used only for Multi speed coils
+       \note Enter the next highest operating supply air flow ratio during heating
+       \note operation or specify autosize. This value is the ratio of air flow
+       \note at this speed to the maximum air flow rate.


These notes don't need to be repeated for every speed.

lgu1234 · 2022-12-01T01:28:09Z

@mjwitte @Myoldmopar @rraustad @EnergyArchmage

Based on discussion in the conference call today, I revised the NFP by adding a section to show differences between between UnitarySystemPerformance:Multispeed and Fan:SystemModel for review.

The Fan:SystemModel does not have No Load Supply Air Flow Rate Ratio, and different fan flow ratios between heating and cooling.

Justification
No Load Supply Air Flow Rate Ratio
As long as the No Load Supply Air Flow Rate is designed in the parent object correctly, there is no need to have this field.

Different fan flow ratios between heating and cooling
The real system has only a single supply fan.

Please let me know your comments via E-mail.

Thanks.

nrel-bot-3 · 2022-12-29T00:20:38Z

@lgu1234 @Myoldmopar it has been 28 days since this pull request was last updated.

mjwitte · 2023-01-04T20:48:39Z

@lgu1234 Using the speeds in Fan:SystemModel to inform the parent object is desirable, because it avoids duplicate input. But it would introduce a new paradigm.

My understanding is that none of the current parent objects mine this information from the fan. The parent objects decide on a flow rate and tell the fan where it's operating. Then the fan calculates it's power use based on interpolating between the speeds. @rraustad is that correct?

Since ZoneHVAC:WaterToAirHeatPump is actually using the UnitarySystem code, the most expedient approach seems to be to use UnitarySystemPerformance:Multispeed for this one. It should require minimal new code.

If UnitarySystem does not currently throw any warnings for inconsistent flow fractions between UnitarySystemPerformance:Multispeed and the Fan:SystemModel object, then I would suggest adding these checks as part of this PR.

For ZoneHVAC:TerminalUnit:VariableRefrigerantFlow it would then make sense to keep the same approach and use UnitarySystemPerformance:Multispeed.

Another alternative is to support both methods: If UnitarySystemPerformance:Multispeed is specified, then use it. If not, check the fan inputs and use those.

@rraustad @EnergyArchmage ?

lgu1234 · 2023-01-09T18:30:23Z

@mjwitte Thanks for your comments. I updated NFP based on your comments and uploaded it a while ago. Since I have not received any more comments from @rraustad and @EnergyArchmage, I assume they agree with your comments. Here is a summary of the NFP update:

The object of UnitarySystemPerformance:Multispeed will be used in this new feature for both ZoneHVAC:WaterToAirHeatPump and ZoneHVAC:TerminalUnit:VariableRefrigerantFlow.

Warnings will be issued if UnitarySystem does not currently throw any warnings for inconsistent flow fractions between UnitarySystemPerformance:Multispeed and the Fan:SystemModel object, but speed fractions from UnitarySystemPerformance:Multispeed will be used.

The alternative method will be included if I have time left: If UnitarySystemPerformance:Multispeed is specified, then use it. If not, check the fan inputs and use those.

I am going to start design document.

Myoldmopar · 2023-02-09T15:41:15Z

I am making my pass through the PR list, and I assume based on the status here that this is going in 23.2, so marking it as such. If it's intended for 23.1 let me know!

lgu1234 · 2023-02-13T18:24:48Z

@Myoldmopar I plan to complete it for the fall release due to family emergency.

rraustad · 2023-03-19T18:02:16Z

My understanding is that none of the current parent objects mine this information from the fan. The parent objects decide on > a flow rate and tell the fan where it's operating. Then the fan calculates it's power use based on interpolating between the
speeds. @rraustad is that correct?

@mjwitte there is a fan flow variable in UnitarySystem but for the max flow and not related to speeds.

if (this->m_FanExists) {
    if (this->m_FanType_Num == DataHVACGlobals::FanType_SystemModelObject) {
        this->m_ActualFanVolFlowRate = state.dataHVACFan->fanObjs[this->m_FanIndex]->designAirVolFlowRate;
    } else {
        this->m_ActualFanVolFlowRate = Fans::GetFanDesignVolumeFlowRate(
            state, blankString, blankString, state.dataUnitarySystems->initUnitarySystemsErrorsFound, this->m_FanIndex);
    }
}

nrel-bot-3 · 2023-04-17T00:19:41Z

@lgu1234 @Myoldmopar it has been 28 days since this pull request was last updated.

nrel-bot-2c · 2023-04-29T00:22:14Z

@lgu1234 it has been 12 days since this pull request was last updated.

nrel-bot-2 · 2023-05-06T00:15:27Z

@lgu1234 it has been 7 days since this pull request was last updated.

rraustad · 2023-05-10T19:09:58Z

src/EnergyPlus/UnitarySystem.hh

@@ -486,6 +486,7 @@ namespace UnitarySystems {
        bool m_ZoneCompFlag = true;
        std::string m_AvailManagerListName;
        int m_EquipCompNum = 0; // 1-based index of this parent type for specific equipment type processing
+        bool reportVariablesAreSetup = false;


Where is this new variable used? I can't find it anywhere.

@rraustad No need to use this variable. Remove it.

rraustad · 2023-05-10T19:16:09Z

src/EnergyPlus/UnitarySystem.cc

+                this->m_HeatingAuxElecConsumption += this->m_AncillaryOffPower * (1.0 - this->m_PartLoadFrac) * ReportingConstant;
+            }
+            elecHeatingPower = state.dataHVACGlobal->DXElecHeatingPower;
+        } break;


These 2 cases look the same. Why were they split out?

@rraustad I am going to combine both.

rraustad · 2023-05-10T19:18:11Z

src/EnergyPlus/UnitarySystem.cc

+                        ((state.dataUnitarySystems->unitarySys[sysNum].m_HeatingCoilType_Num == DataHVACGlobals::Coil_HeatingWaterToAirHPSimple ||
+                          state.dataUnitarySystems->unitarySys[sysNum].m_HeatingCoilType_Num ==
+                              DataHVACGlobals::Coil_HeatingWaterToAirHPVSEquationFit) &&
+                         state.dataUnitarySystems->unitarySys[sysNum].m_NumOfSpeedHeating > 1)) {


Can't you simply use:

if (this->m_MultiSpeedCoolingCoil || this->m_MultiSpeedHeatingCoil)

@rraustad It may not be simplified, because these output variables are used only for Coil_Cooling/heatingWaterToAirHPSimple and Coil_Cooling/heatingWaterToAirHPVSEquationFit object. m_MultiSpeedCoolingCoil and m_MultiSpeedHeatingCoil many cover other air source coils also.

rraustad · 2023-05-10T19:51:10Z

src/EnergyPlus/HVACFan.cc

+    Real64 FanSystem::AirMassFlowRateAtSpeed(int const SpeedNum)
+    {
+        return m_massFlowAtSpeed[SpeedNum];
+    }


If m_numSpeeds and m_massFlowAtSpeed were public you wouldn't need these new functions.

I don't have any problems to make these two members as public. I am going to wait a couple of days.

Myoldmopar · 2023-06-29T20:50:16Z

@lgu1234 it looks like the last time this got good results. Some diffs, but every file passing except the one debug case. That one was failing on all branches, and unrelated to your work. If you want a fully clean build, you can pull develop in one more time, but it's not necessary now. I'll look it over right now. It looks like the diffs have been scrutinized and are basically just order changes, not really significant diffs. And the design was discussed multiple times, so I don't think I need any other review input here. But of course if you want to also provide final thoughts, they would of course be welcome @mjwitte @rraustad.

Myoldmopar

@lgu1234 I made a few comments on here. Some are suggestions, some are a little more. Let me know what you think and we'll see about getting this wrapped up.

Myoldmopar · 2023-06-29T20:50:42Z

idd/Energy+.idd.in

+   A22; \field Design Specification Multispeed Object Name
+        \type object-list
+        \object-list UnitarySystemPerformaceNames
+        \note Enter the name of the performance specification object used to describe the multispeed coil or fan.


Two optional fields, no transition 👍

Myoldmopar · 2023-06-29T20:50:57Z

idd/Energy+.idd.in

+  A21; \field Design Specification Multispeed Object Name
+       \type object-list
+       \object-list UnitarySystemPerformaceNames
+       \note Enter the name of the performance specification object used to describe the multispeed coil or fan.


Two optional fields, no transition 👍

Myoldmopar · 2023-06-29T20:52:57Z

idd/Energy+.idd.in

+   A22; \field Design Specification Multispeed Object Name
+        \type object-list
+        \object-list UnitarySystemPerformaceNames
+        \note Enter the name of the performance specification object used to describe the multispeed coil or fan.


The wording here is a little funny, but maybe there's precedent:

\note Enter the name of the performance specification objec

The phrase "Enter the name of..." sounds like it's one of the many interactive text-based games I probably don't still play in 2023. If there is any other change to make, I'd prefer to at least take out the word "Enter". @mjwitte any thoughts on this one?

Myoldmopar · 2023-06-29T20:54:14Z

src/EnergyPlus/HVACFan.cc

@@ -351,11 +351,11 @@ namespace HVACFan {

    FanSystem::FanSystem(EnergyPlusData &state, std::string const &objectName)
        : availSchedIndex(0), inletNodeNum(0), outletNodeNum(0), designAirVolFlowRate(0.0), speedControl(SpeedControlMethod::NotSet), deltaPress(0.0),
-          designElecPower(0.0), powerModFuncFlowFractionCurveIndex(0), AirLoopNum(0), AirPathFlag(false), fanIsSecondaryDriver(false),
+          designElecPower(0.0), powerModFuncFlowFractionCurveIndex(0), AirLoopNum(0), AirPathFlag(false), m_numSpeeds(0), fanIsSecondaryDriver(false),


This is fine, but I would request that any future time you are adding or modifying class member variables, just initialize them on the class declaration itself, and don't perpetuate these long initializer lists.

@Myoldmopar I can do it to initialize class member variables. In order to be consistent with existing structure, I prefer to make any changes later after the new feature is merged. Thanks.

Myoldmopar · 2023-06-29T20:55:07Z

src/EnergyPlus/HVACFan.hh

@@ -140,6 +140,8 @@ namespace HVACFan {
        int powerModFuncFlowFractionCurveIndex; // pointer to performance curve or table
        int AirLoopNum;                         // AirLoop number
        bool AirPathFlag;                       // Yes, this fan is a part of airpath
+        int m_numSpeeds;                        // input for how many speed levels for discrete fan
+        std::vector<Real64> m_massFlowAtSpeed;


A regular vector, always nice to see standard types. The size of this isn't known at compile time, is it? (If so, we should make it a fixed size std::array...)

@Myoldmopar Unfortunately, the size of vector is unknown at compile time. A fixed size of array may not be used.

Myoldmopar · 2023-06-29T20:59:35Z

src/EnergyPlus/WaterToAirHeatPumpSimple.cc

@@ -3888,7 +3888,8 @@ namespace WaterToAirHeatPumpSimple {
            state.dataWaterToAirHeatPumpSimple->GetCoilsInputFlag = false;
        }

-        if (CoilType == "COIL:COOLING:WATERTOAIRHEATPUMP:EQUATIONFIT" || CoilType == "COIL:HEATING:WATERTOAIRHEATPUMP:EQUATIONFIT") {
+        if (UtilityRoutines::SameString(CoilType, "COIL:COOLING:WATERTOAIRHEATPUMP:EQUATIONFIT") ||


Hmmmm seems like a missed opportunity to refactor this function. I don't think we need to be passing a string in for the coil type. Unless I'm missing something, I think it should be one of the equipment type enum values. But this function is likely used in a bunch of spots, so I will just pause on this one, and we can clean it up later. I just ........ well, I need to check how frequently this function is used during the simulation. @mjwitte do you have an idea?

@Myoldmopar OK. I am going to pause for the time being.

I would say leave this for now, but open a new refactoring task to clean up both ``WaterToAirHeatPumpSimple::GetCoilAirFlowRate and VariableSpeedCoils::GetCoilAirFlowRateVariableSpeed.

a. The coil type strings should be enums. The calling functions should already know the coil type enum by the time this is called.
b. The coil name can be replaced with coil index. Again, the calling functions should already know this.
c. I think the check for getinput can be removed from these and just test for a valid coil index and a valid type enum and throw an error.
@rraustad Would you agree?

Yes I agree. DataHVACGlobals has a CoilType enum and coilTypeNamesUC array that can be used for that. If the coil name is needed for something it can be looked up. Regarding getting rid of getInput in these mining functions, I'm not sure of that at this point. The calling function would need to use the index on this call and that might be a little more work to cover all parent objects. If the index is known the data could be read directly from the state struct and the mining functions are no longer needed, except for getIndex. We are definitily moving in this direction.

See this type of refactor where the mining functions were removed in this commit.

Good, I don't even have to make these types of comments anymore! I can move on to better and more pedantic comments about the use of this->m_X.

@mjwitte @rraustad @amirroth I leave it as is for future refactory.

Myoldmopar · 2023-06-29T21:21:59Z

src/EnergyPlus/UnitarySystem.cc

+                                       double(NumOfSpeed)));
+                            ShowContinueError(state, format("... The number of heating coil speeds in the {} will be used.", MultispeedType));
+                        }
+                    }


I wonder how nice this would look as a switch/case block instead of nested IFs.

lgu1234 · 2023-07-06T14:26:33Z

@Myoldmopar I made a switch/case block instead of nested IFs.

…nto MultispeedFans

lgu1234 · 2023-07-06T21:53:55Z

@Myoldmopar I addressed the comments and uploaded the change in Github. It is ready for further review.

Thanks.

amirroth · 2023-07-17T22:21:15Z

src/EnergyPlus/HVACVariableRefrigerantFlow.cc

@@ -4471,6 +4472,94 @@ void GetVRFInputData(EnergyPlusData &state, bool &ErrorsFound)
            }
        }

+        if (!lAlphaFieldBlanks(20) && !lAlphaFieldBlanks(21)) {


auto &vrftu would be helpful here.

@amirroth Done. Thanks.

amirroth · 2023-07-17T22:31:59Z

src/EnergyPlus/UnitarySystem.cc

@@ -3067,6 +3074,27 @@ namespace UnitarySystems {
                this->m_DesignCoolingCapacity = DataSizing::AutoSize;
                if (this->m_HeatingCoilType_Num == DataHVACGlobals::Coil_HeatingWaterToAirHP)
                    EqSizing.DesHeatingLoad = state.dataSize->DataConstantUsedForSizing;
+                // airflow sizing with multispeed fan


I want to make a general comment here. The "scope Hungarian" notation m_ means "member variable". Prepending access with this-> is only necessary in cases where a member variable is shadowed (i.e., has the same name) as a local variable, e.g., this->name = name; where the first name is the member and the second one is the local. Otherwise it is not necessary because C++ assumes that if a variable inside a method is not local then it must be a member. [Note: global variables have lower scope precedence than member variables, but we don't really have these in EnergyPlus anymore except for the various xNamesUC arrays].

Anyways, if all member variables start with m_ and local variables do not, then there is no possibility of name shadowing and therefore no need for this->.

TL;DR this->m_X is redundant from both a compiler and readability standpoint. The m_ tells both the compiler and the reader the same thing, i.e., that this variable is a member of the class that defines the current method. I would eliminate one of them, preferably this-> because it is longer and thus more annoying. Also, it's a keyword so it gets colorized and makes the whole screen of that color.

@amirroth I agree with you. The changes you suggested is beyond this new feature scope. It is better to make the changes in the future factory.

amirroth · 2023-07-17T22:34:07Z

src/EnergyPlus/UnitarySystem.cc

                    for (int i = 1; i <= this->m_NumOfSpeedCooling; ++i) {
                        this->m_CoolMassFlowRate[i] = 0.0;
                        this->m_CoolVolumeFlowRate[i] = 0.0;
                        this->m_MSCoolingSpeedRatio[i] = 1.0;
                    }
+                    if (this->m_CoolingCoilType_Num == DataHVACGlobals::Coil_CoolingWaterToAirHPVSEquationFit) {
+                        std::string MultispeedType = "UnitarySystemPerformance:Multispeed";


I would make a string_view comment here, but there are bigger problems with the fact that Coil_ is not an enumeration so I will restrain myself.

@amirroth I will leave it as is and wait for better solution.

nrel-bot-2b · 2023-08-03T00:10:33Z

@lgu1234 it has been 14 days since this pull request was last updated.

nrel-bot-2 · 2023-08-10T00:14:00Z

@lgu1234 it has been 7 days since this pull request was last updated.

Myoldmopar · 2023-08-16T18:50:16Z

@lgu1234 thanks for resolving conflicts here!! I was thinking I'd end up having to do that. I'll look it over and get it built/tested.

Myoldmopar · 2023-08-16T18:54:06Z

Branch sanity checks look good, no conflicts now, formatting and custom-check both pass, along with doc/cppcheck builds. Local build going now.

Myoldmopar

There's a lot of great stuff in here, and it's been scrutinized enough. I found one documentation warning snuck in, so I fixed that and am doing final testing. Assuming it's all good, I'll push that one tiny fix and get this merged. Thanks @lgu1234

Myoldmopar · 2023-08-16T18:57:05Z

idd/Energy+.idd.in

+   A22; \field Design Specification Multispeed Object Name
+        \type object-list
+        \object-list UnitarySystemPerformaceNames
+        \note Enter the name of the performance specification object used to describe the multispeed coil or fan.


The note actually still appears to say "Enter the name..." But it's fine, and not worth any other commits.

Myoldmopar · 2023-08-16T19:17:33Z

src/EnergyPlus/UnitarySystem.cc

+                case DataHVACGlobals::Coil_HeatingElectric_MultiStage:
+                case DataHVACGlobals::Coil_HeatingGas_MultiStage:
+                case DataHVACGlobals::Coil_HeatingWaterToAirHPSimple:
+                case DataHVACGlobals::Coil_HeatingWaterToAirHPVSEquationFit: {


The switch is so much nicer.

Myoldmopar · 2023-08-16T19:41:24Z

Everything looks great! Text diffs in RDD, etc., but nothing of significance. Table diffs in some files, but it's due to some rows being reordered. This is good to go! Thanks @lgu1234 and reviewers!

Upload a draft NFP

339d44e

lgu1234 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 Nov 18, 2022

mjwitte reviewed Nov 30, 2022

View reviewed changes

Revise NFP based on comments

5e095fb

lgu1234 added 2 commits January 9, 2023 13:22

Update NFP based on comments

ee4cbff

Merge branch 'develop' into MultispeedFans

9206678

lgu1234 added 2 commits January 12, 2023 15:59

Final NFP

52a199a

Merge branch 'develop' into MultispeedFans

1da6891

Myoldmopar added this to the EnergyPlus 23.2 IOFreeze milestone Feb 9, 2023

lgu1234 added 2 commits February 22, 2023 09:18

Upload design document

09e6b25

Merge branch 'develop' into MultispeedFans

c52794b

lgu1234 added 3 commits May 10, 2023 10:41

Initial upload

9ffbd6e

Merge branch 'develop' into MultispeedFans

b5424bd

Clang format

e86f452

rraustad reviewed May 10, 2023

View reviewed changes

Clang format

029f6ba

Merge branch 'develop' into MultispeedFans

fde9769

Myoldmopar reviewed Jun 29, 2023

View reviewed changes

lgu1234 added 5 commits July 6, 2023 10:48

Address comments

9c31b28

Merge branch 'MultispeedFans' of https://github.com/NREL/EnergyPlus i…

dcc69ed

…nto MultispeedFans

Merge branch 'develop' into MultispeedFans

13eb113

CLang format

9c8a271

Merge branch 'develop' into MultispeedFans

47bc2ce

amirroth reviewed Jul 17, 2023

View reviewed changes

lgu1234 added 2 commits July 19, 2023 09:57

Address comments

f44c7fe

Merge branch 'develop' into MultispeedFans

538b5a8

lgu1234 added 4 commits August 16, 2023 09:07

Merge branch 'develop' into MultispeedFans

b03e970

Conflict correction

cfee11b

Merge branch 'develop' into MultispeedFans

5fec7ee

Clang format

36a9e38

Myoldmopar approved these changes Aug 16, 2023

View reviewed changes

Myoldmopar merged commit 46fa50b into develop Aug 16, 2023

Myoldmopar deleted the MultispeedFans branch August 16, 2023 19:41

Myoldmopar mentioned this pull request Aug 16, 2023

Tiny doc fix #10152

Merged

rraustad mentioned this pull request Sep 28, 2023

Fix crash with new Multi-speed Fans for WSHP Zone Equipment #10249

Merged

20 tasks

Myoldmopar mentioned this pull request Nov 16, 2023

Multi-speed Fan for VRF Indoor Terminal Units #8934

Closed

3 tasks


		<span style="color:red">

		An alternative way is to use the existing object of UnitarySystemPerformance:Multispeed. Since this object is not used only for UnitarySystem, the name of the object may be changed.

Improved Support for Multi-speed Fans #9746

Improved Support for Multi-speed Fans #9746

Conversation

lgu1234 commented Nov 18, 2022 • edited Loading

Pull request overview

Pull Request Author

Reviewer

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lgu1234 commented Dec 1, 2022

nrel-bot-3 commented Dec 29, 2022

mjwitte commented Jan 4, 2023

lgu1234 commented Jan 9, 2023

Myoldmopar commented Feb 9, 2023

lgu1234 commented Feb 13, 2023

rraustad commented Mar 19, 2023

nrel-bot-3 commented Apr 17, 2023

nrel-bot-2c commented Apr 29, 2023

nrel-bot-2 commented May 6, 2023

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 Jun 29, 2023

Myoldmopar 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

rraustad Jul 17, 2023 • 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

lgu1234 commented Jul 6, 2023

lgu1234 commented Jul 6, 2023

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

nrel-bot-2b commented Aug 3, 2023

nrel-bot-2 commented Aug 10, 2023

Myoldmopar commented Aug 16, 2023

Myoldmopar commented Aug 16, 2023

Myoldmopar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Myoldmopar commented Aug 16, 2023

lgu1234 commented Nov 18, 2022 •

edited

Loading

rraustad Jul 17, 2023 •

edited

Loading