Adiabatic Boundary Condition Reporting Issue for Surface Outside Face heat transfer output variables

[EnergyArchmage]

Issue overview

There is a code problem here https://github.com/NREL/EnergyPlus/blob/develop/src/EnergyPlus/HeatBalanceSurfaceManager.cc#L5083

The logic should be if (surface.ExtBoundCond > 0 && surface.ExtBoundCond != SurfNum)

When surfaces are so-called Adiabatic, they self reference and the ExtBoundCond value is the surface's own index. The otherside face is never going to get calculated separately, as it would for an actual partition. The values for SurfOpaqOutsideFaceConductionFlux and SurfOpaqOutsideFaceConduction never get calculated. This causes erroneous values to be present in a set of surface output variables related to these:

Surface Outside Face Conduction Heat Transfer Rate
Surface Heat Storage Rate 
Surface Average Face Conduction Heat Transfer Rate

I believe it is just a reporting issue.

Details

Some additional details for this issue (if relevant):

• Platform (Operating system, version)
• Version of EnergyPlus (if using an intermediate build, include SHA)
• Unmethours link or helpdesk ticket number

Checklist

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

• [ ] Defect file added (list location of defect file here)
• [ ] Ticket added to Pivotal for defect (development team task)
• [ ] Pull request created (the pull request will have additional tasks related to reviewing changes that fix this defect)

[lgu1234]

@EnergyArchmage I modified an example file of 1ZoneUncontrolled.idf as a test file. The Outside Boundary Condition are revised as Adiabatic in both Zn001:Wall001 and Zn001:Wall002. The Outside Boundary Condition of Zn001:Flr001 is already defined as Adiabatic. The outputs of Surface Outside Face Conduction Heat Transfer Rate for these 3 surfaces are all zero as expected.

When I add your logic, if (surface.ExtBoundCond > 0 && surface.ExtBoundCond != SurfNum), The outputs of Surface Outside Face Conduction Heat Transfer Rate for these 3 surfaces are not zero anymore.

I found via debug that all surface.ExtBoundCond = SurfNum. Therefore, SurfOpaqOutsideFaceConductionFlux calculations are not bypassed and generate some values which are not compatible with Adiabatic boundary condition. Based on observation with the test file, the existing calculation may be OK.

Enclosed is a test file.

in - Copy.txt

Please let me know what you think.

[EnergyArchmage]

I know it sounds like Adiabatic should have zero values at outside face, but not in E+. It is the same boundary conditions inside and outside (well except for an annoying lag from previous timestep) and the values should not be all zero.

[lgu1234]

@EnergyArchmage My understanding is that SurfOpaqOutsideFaceConductionFlux and others should not be bypassed and should be calculated. Is my understanding correct?

[EnergyArchmage]

Yes. If its so-called Adiabatic they should get calculated. Just to fill reporting variable

[lgu1234]

@EnergyArchmage Here is a definition of Adiabatic boundary condition from a web site as https://www.thermal-engineering.org/what-is-adiabatic-boundary-thermal-symmetry-definition/: If any values of heat flux are reported, more justification is needed. To be honest, I may not accept no zero fluxes, When there is an annoying lag from previous timestep, the item should be a part of storage.

[EnergyArchmage]

He he, I wish there really was an Adiabatic boundary condition in EnergyPlus.

I can't explain it if you don't already know. But the heat flows are occurring at the outside face in the modeling. It is just balanced so that the same thing is happening at both the inside face and the outside face. The problem is that user cannot explore the storage (and release) of heat over time because the report variables, such those cited above. are not accurate. It should be the case that over a 24 hour period on a cooling design day, the adiabatic surface will store and release an equal amount of heat. But with the error here, that is not the case.

The code comment about partitions is correct, but adiabatic surfaces are not partitions.

[lgu1234]

@EnergyArchmage Here is the code in Develop

Line 5042 if (surface.ExtBoundCond > 0) continue; Line 5902 state.dataHeatBalSurf->SurfOpaqStorageCond(surfNum) = -(state.dataHeatBalSurf->SurfOpaqInsFaceCond(surfNum) + state.dataHeatBalSurf->SurfOpaqOutFaceCond(surfNum));

Since SurfOpaqOutFaceCond = 0, the storage is equal to SurfOpaqInsFaceCond

Based on your suggestion

Line 5042 if (surface.ExtBoundCond > 0 && surface.ExtBoundCond != SurfNum) continue; Line 5057 (calculated) state.dataHeatBalSurf->SurfOpaqOutFaceCond(SurfNum) = surface.Area * state.dataHeatBalSurf->SurfOpaqOutFaceCondFlux(SurfNum); Line 5902 state.dataHeatBalSurf->SurfOpaqStorageCond(surfNum) = -(state.dataHeatBalSurf->SurfOpaqInsFaceCond(surfNum) + state.dataHeatBalSurf->SurfOpaqOutFaceCond(surfNum));

if SurfOpaqOutFaceCond is calculated, the storage value is 0.

Here are two plots to show SurfOpaqOutFaceCond and SurfOpaqStorageCond from develop and the revision.

The difference is a report issue. The item should be reported either storage or outside face conduction. I think since the outside face BC is adiabatic, storage report may be appropriate. Please let me know what you think.