Adjust SurfaceProperty:XXX IDD and fix/improve sunlit fraction schedule checks#11445
Adjust SurfaceProperty:XXX IDD and fix/improve sunlit fraction schedule checks#11445joseph-robertson wants to merge 13 commits intodevelopfrom
Conversation
…rty:SurroundingSurfaces.
…e has sunlit fraction schedule.
| SurfaceGeometry::SetupZoneGeometry(state, ErrorsFound); | ||
|
|
||
| SolarShading::GetShadowingInput(state); |
There was a problem hiding this comment.
This PR inadvertently moved GetShadowingInput before SetupZoneGeometry. But we need it after so that surface data is read first. The existing relevant unit test didn't catch this because of this reason.
There was a problem hiding this comment.
@RKStrand Are you OK with this change? I believe the only regression implication is to change the order of a few lines in the EIO file.
There was a problem hiding this comment.
@joseph-robertson Um, yeah, as long as it doesn't trip any weird things in the unit tests, I'm guessing it will be okay. I seem to vaguely remember some recent work here and there were some issues with order dependence on some of the calls in this area of the code. I think I couldn't move something up as high as I thought because it caused other crashes because stuff wasn't read in yet. Anyway, if you move it an there are no unit test or test suite issues that pop up, then it's probably fine.
| } | ||
| } | ||
|
|
||
| void checkNotScheduledSurfacePresent(EnergyPlusData &state) |
There was a problem hiding this comment.
New method for issuing a warning when a surface has a sunlit fraction schedule but the ShadowCalculation object has Shading Calculation Method != Scheduled. This is the contrapositive (?!) to checkScheduledSurfacePresent.
| surfData->Surface(6).Class = SurfaceClass::Window; | ||
| surfData->Surface(6).SurfSchedExternalShadingFrac = false; | ||
| surfData->Surface(6).Name = "WINDOW2NOTOK"; |
There was a problem hiding this comment.
Just improving the existing unit test -- we should see an additional warning line for a second valid surface without sunlit fraction schedule.
| EXPECT_TRUE(compare_err_stream(error_string, true)); | ||
| } | ||
|
|
||
| TEST_F(EnergyPlusFixture, SolarShadingTest_checkNotScheduledSurfacePresent) |
There was a problem hiding this comment.
New unit test, much like the existing unit test, for checking the new checkNotScheduledSurfacePresent method.
|
|
|
|
|
|
I think the |
| A2, \field Exterior Surface Name | ||
| \type object-list | ||
| \object-list SurfaceNames | ||
| \object-list AllHeatTranSurfNames |
There was a problem hiding this comment.
I assume this change was made to include FenestrationSurface:Detailed in the list of object names in the IDF Editor. However, AllHeatTranSurfNames (and SurfaceNames) also includes objects that should not show up in that list provided by the IDF Editor. It may also be that the IO Ref description below does not include all valid surface types but I did not check that. The fix would be to add a new reference to the valid objects and use that here instead?
1.11.28 SurfaceProperty:LocalEnvironment
The object links to an exterior surface object BuildingSurface:Detailed or an exterior fenestration object
FenestrationSurface:Detailed and is used when ...
FenestrationSurface:Detailed,
\memo Allows for detailed entry of subsurfaces
\memo (windows, doors, glass doors, tubular daylighting devices).
\min-fields 18
\format vertices
A1 , \field Name
\required-field
\type alpha
\reference SubSurfNames
\reference GlazedExtSubSurfNames
\reference SurfAndSubSurfNames
\reference AllHeatTranSurfNames
For example, what good would it do to use SurfaceProperty:LocalEnvironment with an adiabatic floor? Maybe I am overthinking this and this change is sufficient to at least include the relevant objects.
Floor:Adiabatic,
\memo Allows for simplified entry of exterior floors
\memo ignoring ground contact or interior floors.
\memo View Factor to Ground is automatically calculated.
A1 , \field Name
\required-field
\type alpha
\reference SurfaceNames
\reference SurfAndSubSurfNames
\reference AllHeatTranSurfNames
There was a problem hiding this comment.
Good point. For example currently if you open SolarShadingTest_ExternalFraction.idf in IDF Editor, the list of SurfaceProperty:LocalEnvironment objects will initially populate the Exterior Surface Name fields with:
- Shading:Site:Detailed (invalid)
- FenestrationSurface:Detailed (invalid)
- BuildingSurface:Detailed (valid)
But the dropdowns don't show any Shading:Site:Detailed or FenestrationSurface:Detailed objects. If we switched SurfaceNames -> AllHeatTranSurfNames we'd still be including invalid Floor:Adiabatic in the dropdowns. So assuming the docs are correct, we'd need a reference that is shared between only FenestrationSurface:Detailed and BuildingSurface:Detailed; if one doesn't already exist, we need to add a new one.
There was a problem hiding this comment.
Be careful when thinking the docs are correct. I think as a user I would expect Wall:Detailed to be the same as BuildingSurface:Detailed in the context of SurfaceProperty:LocalEnvironment. Even an exterior door should be able to use the local environment properties? I am sure you can think of other use cases for this object.
There was a problem hiding this comment.
See 1886efe. Indeed Wall:Detailed, e.g., is a valid object (I checked locally). Based on the code, shading objects are certainly invalid. So I propose that we stick with the \object-list AllHeatTranSurfNames change (to pick up fenestration), but not get overly ambitious with a new reference as we may accidentally exclude a valid object type.
… exterior surface and fenestration objects.
…g objects in SolarShadingTest_ExternalFraction.idf.
|
|
| @@ -670,215 +670,6 @@ | |||
| , !- Sky Diffuse Modeling Algorithm | |||
| Yes; !- Output External Shading Calculation Results | |||
|
|
|||
There was a problem hiding this comment.
@joseph-robertson I thought I saw a comment of why these were removed but can't find that now. Could you elaborate why these would need to be removed.
There was a problem hiding this comment.
The SurfaceProperty:LocalEnvironment objects referencing shading objects don't need to be removed; but I think they can safely be removed since they have no impact on the model.
|
Pull request overview
Description of the purpose of this PR
Pull Request Author
Reviewer