Consolidate speed-dependent coil load ratio input parameters into a single parameter. #10369
Conversation
| @@ -788,7 +786,7 @@ void CoilCoolingDX::simulate(EnergyPlusData &state, | |||
| this->wasteHeatEnergyRate = this->performance.wasteHeatRate; | |||
| this->wasteHeatEnergy = this->performance.wasteHeatRate * reportingConstant; | |||
|
|
|||
| this->partLoadRatioReport = PLR; | |||
| this->partLoadRatioReport = speedNum == 1 ? 1.0 : speedRatio; | |||
There was a problem hiding this comment.
What this says is at speed = 1 the coil/compressor does not cycle (i.e., PLR = 1) and at higher speeds PLR is equal to the upper stage cycling ratio. Both of these are incorrect. Background: PLR started as a single-speed compressor cycling variable. Then variable speed coils were added and CyclingRatio and SpeedRatio were introduced. For the variable speed coils the CyclingRatio shows how the compressor cycles at speed = 1, which is the same as what the PLR variable shows for this and other coil types. So PLR and CyclingRatio are synonymous for the VS coil. At speeds > 1, the PLR and CyclingRatio = 1. At the higher speeds the highest compressor stage that is operating can cycle. This operation is shown in SpeedRatio. The CyclingRatio and SpeedRatio variables where added to the new cooling coil model to represent VS coils. Ex, at speed = 2, PLR and CyclingRatio = 1 and SpeedRatio = what the upper stage cycling ratio is. What I have thought about doing in the past is to delete the CyclingRatio variable and replace it with PLR, and leave SpeedRatio alone to represent what it does now. Another way to look at this is PLR represents how long the compressor operates during the time step. SpeedRatio represents the fraction of the time step the upper stage compressor is operating with lower speed compressor(s) operating the entire time step. There is some nuance to consider with the staged Tstat (on/off at specific speed) and Capacity Control Method = discrete/continuous for the new coil model.
There was a problem hiding this comment.
@rraustad thank you so much for the comment. I was trying to back this information out of the code, as my notes from our last conversation were spotty. I'll have another go-around.
…ge-coil-load-ratios
…ge-coil-load-ratios
…ge-coil-load-ratios
|
@tanaya-mankad @Myoldmopar it has been 28 days since this pull request was last updated. |
5 similar comments
|
@tanaya-mankad @Myoldmopar it has been 28 days since this pull request was last updated. |
|
@tanaya-mankad @Myoldmopar it has been 28 days since this pull request was last updated. |
|
@tanaya-mankad @Myoldmopar it has been 28 days since this pull request was last updated. |
|
@tanaya-mankad @Myoldmopar it has been 28 days since this pull request was last updated. |
|
@tanaya-mankad @Myoldmopar it has been 28 days since this pull request was last updated. |
…/EnergyPlus into merge-coil-load-ratios
…ge-coil-load-ratios
…ge-coil-load-ratios
…/EnergyPlus into merge-coil-load-ratios
|
@rraustad I would yield to you on whether you feel this should get reviewed/merged in here as we approach 24.2. If this is something that deserves additional time, I'll just target the next release and move on to other, more pressing, PRs. But if this is an easy win, then I will give it some attention. |
…ge-coil-load-ratios
|
I'm trying to work through the combination of forked repo When GHA kicks off a run in a forked repo, the token it creates only has read access on the base repo. This is intentional, and good for avoiding malicious actors. But it also means that forked PRs cannot comment back onto the PR conversation because that belongs to the base repo. We still want to get an alert for any diffs that appear in the PR, and since we can't comment, I think the next best option is to just have the regression step fail. It will show a failure on the testing list, which will trigger us looking at the CI results, and we'll be able to see right away that it just had regressions. This is sorta what's already in place. If there are no regressions, everything passes happily. If there are regressions, they are reported, uploaded as an artifact, and then the workflow fails so we go investigate. But right now what fails is the "actions/github-script@v7" step, which is confusing. I'd like it to fail on "Run Regressions" step. This workaround is ... fine... but not ideal. Ideally, I could give forked repo GHA runs specifically PR comment access. But I don't see how to do that (open to suggestion...). Now that I understand what's going on, and it's not urgent or going to break anything in the develop branch, I will set aside some other time to fix it up. Development can continue on forked PRs, including this one, and they can merge when ready. |
|
@tanaya-mankad it has been 9 days since this pull request was last updated. |
|
@tanaya-mankad it has been 7 days since this pull request was last updated. |
| if (singleMode) { | ||
| CoilPLR = (this->m_CoolingSpeedNum == 1) | ||
| ? PartLoadRatio | ||
| : 1.0; // singleMode allows cycling, but not part load operation at higher speeds |
There was a problem hiding this comment.
@tanaya-mankad there may be a logic issue here? At line 11551 there are 2 conditionals, CompressorOp::Off && this->m_CoolingSpeedNum > 1. So if CompressorOp::Off and this->m_CoolingSpeedNum == 1 this code will drop to the else where the compressor is On..
There was a problem hiding this comment.
Thanks @rraustad for finding that fallacy! Unfortunately it doesn't seem to affect the result. I'm attaching a couple of comparison plots - the top plot is the Max Absolute Difference, with red showing the difference on the left scale. The bottom plot is the Max Relative Difference, with red pointing to the right scale. The location is always on Jan 1.
(The second png is just zoomed way in.) In case it gives us any more info.
There was a problem hiding this comment.
Which example file is this?
There was a problem hiding this comment.
UnitarySystem_MultiSpeedDX_EconoStaging.idf
The regressions are here (please don't mind the build problems, apparently it's due to this being a branch on the Big Ladder fork.)
There was a problem hiding this comment.
That must be a local test file? since it's not in the repo testfile folder. Can you upload it here so I can run it? In UnitarySystem_MultiSpeedDX I did change Sys 3 to single mode (Sys 2 had the wrong heating coil type) but I'm not sure if that's what changed or the only thing changed in that test file.
There was a problem hiding this comment.
I do see that file. It's not in the list for the regression tool so I thought it was a test file. How are you testing these files locally? I have 2 BigLadder repos for develop and this branch and am trying to run local regressions to see the same results you see.
There was a problem hiding this comment.
I think I figured it out. The BigLadder develop branch is behind NREL develop. When I pulled NREL develop into the BigLadder branch that file showed up.
There was a problem hiding this comment.
Now I see the same thing you see. The question is if this is due to the changes you made. It's so small it's almost not worth looking into, almost.
There was a problem hiding this comment.
Yes, it's tiny! I'd defer to your judgement on whether it's significant. I'm not sure what counts as a "big diff" in regression testing, but 10e-5 relative difference during warmup seems quite difficult to find.
There was a problem hiding this comment.
This example file came from #9987 and is the only file with local diffs. I think these diffs come from a different OA flow rate at the beginning of the simulation, and for all 4 systems in this file, but I can't see why changing the call to the coil model would affect the calculation for economizer PLR. There are no eio diffs and no warmup diffs but diffs in the eso so it is operational.
src/EnergyPlus/UnitarySystem.cc
Outdated
| @@ -15115,7 +15094,7 @@ namespace UnitarySystems { | |||
| } | |||
|
|
|||
| state.dataCoilCooingDX->coilCoolingDXs[this->m_CoolingCoilIndex].simulate( | |||
| state, coilMode, CycRatio, this->m_CoolingSpeedNum, SpeedRatio, this->m_FanOpMode, singleMode, this->CoilSHR); | |||
| state, coilMode, this->m_CoolingSpeedNum, PartLoadFrac, this->m_FanOpMode, singleMode, this->CoilSHR); | |||
There was a problem hiding this comment.
lines 15074 - 15087 are no longer needed (same for 15041 - 15068)
There was a problem hiding this comment.
Thanks; removed.
|
I have tested UnitarySystem_MultiSpeedDX_EconoStaging locally and can't find any reason for these small diffs. As I run through the debugger the answers are identical (2 environments on develop and this branch) up to 8 AM when a load exists. I just can't find a way to break in right before the answer changes to step through to see which code changes the answer. The other example files run without diffs and the unit tests run to completion. It has to be something to do with this OA staging code (because there are no diffs otherwise) but the diffs are so small it's hard to find. |
|
I was having the same problem finding a good breakpoint. I can look a bit more into the OA staging though. |
If you feel we have both done due diligence, Neal and I were thinking that we could log this as an issue with the best information we have available now, and approve this PR in its current state. |
|
@tanaya-mankad it has been 7 days since this pull request was last updated. |
This PR is an attempt to homogenize the ideas of cycling-ratio and speed-ratio into a single speed-dependent parameter.
Incidental changes include updating the const-correctness of both declaration and implementation of simulate() and its dependencies, to prevent accidental changes to const values inside the function.
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.