-
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
Add Vertical (1-D) Solution to Earth Tube Object #10138
Conversation
Initial submission of the new feature proposal for the 1-D (vertical) earth tube enhancement to EnergyPlus.
Changes were made to the NFP to include the comments made during the 5/3/23 technicalities meeting regarding the assumptions made about the earth tube node and contacting an expert on earth tubes from outside the development team.
Changes made to the NFP based on comments/conversation that took place over Slack on 5/11/23.
Modifications as a result of last technicalities call.
First drafts of the documentation in both the IO Ref and Eng Ref. Change of a variable name to better reflect what it actually is. Additions to the IDD.
this doesn't work, but i need to merge in other things
First successful build!
Correction of minor issue
Fixed an issue with a blank solution type. It should now interpret the input when solution type is blank correctly (default back to Basic). There should be no diffs in the ci results (hopefully).
Various minor issues fixed. This now runs but the results are not correct for the vertical solution.
Working code with results that look like one would expect. More testing and then unit tests and docs final edits to come.
Addition of two unit tests and a new regression test. Minor documentation additions and tweaks.
Supporting graphs: |
"Virtual" Walkthrough Notes: |
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.
This is really great, and looks to be in good shape. I had a few comments, so I'll hold from marking it approve/reject right now. Let me know what you think about my comments.
@@ -89,3 +89,4 @@ dist | |||
# if you generate sphinx docs, it builds a dummy version of the schema in the idd folder, just ignore it | |||
/idd/Energy+.schema.epJSON | |||
/idd/Energy+.schema.epJSON.in | |||
design/FY2023/earth_tube_solution_space_diagram.pdf |
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.
Why would this file be ignored? I don't anticipate it changing, so it shouldn't matter much, but I think it should be included.
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.
Ok. I had to go back and look up what was going on here. It's essentially a duplicate file. I created the diagram in MS Powerpoint, saved it as a PDF, then opened in Preview and saved it as a .png to match the file type of other documents. Since it was a duplicate and just a transition file, I didn't think it was worth cluttering the GitHub space. It's essentially the same as the file of the same name with a .png extension. You still want this? I'm ok either way.
@@ -1884,6 +1931,22 @@ \subsubsection{Outputs}\label{zoneearthtube-outputs} | |||
|
|||
This is the humidity ratio of the air entering the zone after passing through the earth tube {[}kgWater/kgDryAir{]}. | |||
|
|||
\paragraph{Earth Tube Node Temperature <X> {[}C{]}}\label{earth-tube-node-temperatures-c} | |||
|
|||
This will generate the internal node temperatures {[}C{]} for the earth tube as a result of the 1-D finite difference model. This is only valid for the 1-D (Vertical) 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.
This will report the internal node temperatures...
Right? I don't think this will trigger the generation of anything.
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.
Yes, correct--it just triggers the reporting. These always get calculated. And before I forget, thanks for reviewing this!
|
||
This will report the theoretical undisturbed ground temperature at the upper boundary for the 1-D finite difference model. This is only valid for the 1-D (Vertical) model. | ||
|
||
\paragraph{Earth Tube Lower Boundary Ground Temperature {[}C{]}}\label{earth-tube-upper-boundary-temperature-c} |
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.
GitHub's doc build is complaining about the multiply defined label here. Need the relabel as -lower-boundary ...
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.
Oh, rats. Copied and pasted and then forgot to update that part of the statement. I'll fix that (hopefully first thing tomorrow).
\note "D" in Equation | ||
\type real | ||
\default 0 | ||
A5, \field Earth Tube Model Type |
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.
Yay for no transition! Right?
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.
Yes, correct. Intentionally done that way. The old model is still the default (notice that the existing earth tube idf in the test suite did not get changed and it runs with no diffs).
\object-list EarthTubeParameterNames | ||
|
||
ZoneEarthtube:Parameters, | ||
\memo Parameters that apply to the vertical model for an earth tube |
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.
Should we do a min-fields here?
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.
Well, I guess that technically everything has a default so if the user just gave a name and ignored the rest it would just take all the defaults? I wasn't sure so I just left that out. I can put it in if you feel like this is important.
@@ -543,6 +631,188 @@ void CheckEarthTubesInZones(EnergyPlusData &state, | |||
} | |||
} | |||
|
|||
void initEarthTubeVertical(EnergyPlusData &state) |
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.
It would be really great if this function did not loop over all the earth tubes. If this could just be a one-time init flag on each earth tube, it would be preferable. I actually don't think it's too much of an effort to change, but I'm open to discussion.
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.
That could be done. The loop over all earth tubes could happen one level up with the continue for a non-vertical model one happening at that point. It would eliminate the need for the multiple "continues" in every loop and would probably eliminate the need for loops in the initEarthTubeVertical subroutine. I'll take a look at this when I make other changes requested above.
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.
Honestly, if it's working, I would just leave it alone. We have a new way to call each plant object "one time". This is nice because then the components can avoid having to constantly check "if one time ... if one time". As such, plant components definitely shouldn't be looping over each plant instance to do one time inits. I am a little foggy it seems, and I wanted to apply that same plant logic here to the earth tubes. But it's not necessary. Just leave this, thanks.
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.
Ok. It is working so I'm also happy to leave it alone.
src/EnergyPlus/EarthTube.cc
Outdated
thisEarthTube.tUndist[nodeNum] = thisEarthTube.calcUndisturbedGroundTemperature(state, thisEarthTube.depthNode[nodeNum]); | ||
} | ||
} | ||
} // ...end of BeginDayFlag block |
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.
Will this get hit multiple times while BeginDayFlag is true? Do you need a second flag like "MyBeginDayFlag" so that it only happens once per day?
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.
I'll double check. I was trying to avoid a duplicate calculation but I may have missed something.
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.
Yeah, this was a problem. I took a page out of the ElectricPowerServiceManager.cc and decided to use "timeElapsed" to avoid duplicate initializations and improper updates. Will be testing this out here shortly.
{ | ||
// Calculate c' for when effectiveness is zero. Will use these values when there is no air flow through the earth tube | ||
// and also use the values in the top portion of the solution (before the earth tube node) since these will not change. | ||
this->cPrime0[0] = this->cCoeff0[0] / this->bCoeff[0]; |
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.
Nice little member method!
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.
Thanks! 😀
src/EnergyPlus/EarthTube.cc
Outdated
bool tempShutDown = false; | ||
// Don't simulate for Basic Solution if the zone is below the minimum temperature limit | ||
if (thisZoneHB.MAT < thisEarthTube.MinTemperature) tempShutDown = true; | ||
// Don't simulate for Basic Solution if the zone is above the maximum temperature limit | ||
if (thisZoneHB.MAT > thisEarthTube.MaxTemperature) tempShutDown = true; |
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.
Can this section just be:
bool tempShutDown = thisZoneHB.MAT > earthTube.MaxTemperature || thisZoneHB.MAT < earthTube.MinTemperature;
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.
Oooo, I guess I hadn't thought about such an assignment being possible and was trying to maintain as much similarity to the old code. But this looks slick (or as the kids say these days "sick"), so I'll implement this also. This "old dog" (me) needs to learn a few new tricks...
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.
Yeah, in Python it could just use an interval comparison 😱
tempShutDown = not (earthTube.MinTemperature < thisZoneHB.MAT < earthTube.MaxTemperature)
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.
I had such grand hopes last school year. My now 16 yo was still doing homeschooling and so we were working through a Python intro course together. Unfortunately I had too much to do to keep up with him. Anyway, that sounds cool!
@@ -85,7 +93,7 @@ namespace EarthTube { | |||
Real64 FanPressure = 0.0; | |||
Real64 FanEfficiency = 0.0; | |||
Real64 FanPower = 0.0; | |||
Real64 GroundTempz1z2t = 0.0; // ground temp between z1 and z2 at time t | |||
Real64 GroundTempt = 0.0; // ground temp at the depth of the earth tube midpoint at time t |
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.
Lead us not to GroundTempt-ation.
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.
🤣🤣🤣...great comment! Yeah, I noticed the "tempt" part and chucked before just deciding that it was at least consistent with what the old name was. Well, maybe it should have been GroundTempzt then...but since it was a single temperature and I wanted that to be very clear.
Modifications to address review comments.
@Myoldmopar Just pushed code mods that will hopefully address the comments you had. Should come back all green unless I missed something. And if I missed a comment, let me know. Thanks! |
Used the wrong term to size vectors. Should fix the issues with Linux debug errors.
Found a problem with one of the loops in the vertical algorithm, resulted from bad job moving stuff around. Xcode was very forgiving, Ubuntu not so much. This should make them both happy.
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.
Thanks for addressing my comments! I'll do a quick build/test now but I assume this will merge shortly.
All good here locally, merging this one in. Thanks for this enhancement @RKStrand ! |
N3, \field Earth Tube Dimensionless Boundary Above | ||
\note When set to 1.0, the upper boundary is one earth tube radius below ground. | ||
\type real | ||
\units dimensionless | ||
\minimum 0.25 | ||
\maximum 1.0 | ||
\default 1.0 | ||
N4, \field Earth Tube Dimensionless Boundary Above | ||
\note When set to 1.0, the upper boundary is one earth tube radius below ground. | ||
\type real | ||
\units dimensionless | ||
\minimum 0.25 | ||
\maximum 1.0 | ||
\default 0.25 |
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.
N4 is below. Note should be updated too.
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.
Yes, you are correct--N4 should say below. Sorry!
@Myoldmopar Any chance we can slide in a typo correction to the field name in the IDD or is that not allowed. Sorry about the bad cut/paste/non-edit.
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.
I think this is an outdated document compared to the Design-Document one no?
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.
Yes, the design document is more up-to-date.
Note sure about the \note @RKStrand cf #10138 (review)
Pull request overview
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.