-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidate speed-dependent coil load ratio input parameters into a single parameter. #10369
base: develop
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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
…nergyPlus 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. |
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.