MRT calculations and radiant exchange calculations are not consistent

[mjwitte]

Issue overview

• CalcSurfaceWeightedMRT always adjusts the stored surface area*emissivity (after Calculate Mean Radiant Temperature (MRT) for Enclosures (not zones) #9628 is will only reset these if EnclRadReCalc is true and 9628 also moves these from state.dataThermalComforts->SurfaceAE to Surface(SurfNum).AE.
• CalcSurfaceWeightedMRT uses Construct(state.dataSurface->Surface(SurfNum2).Construction).InsideAbsorpThermal which is fine for opaque surface and unshaded windows, but not for shaded windows. It precalculates state.dataThermalComforts->SurfaceAE
• CheckGlazingShadingStatusChange checks for EMS or changes in shade status to set EnclRadCalc to indicate if emissivities need to be updated.
• ComputeIntThermalAbsorpFactors thoroughly adjusts for window shades etc and sets state.dataHeatBalSurf->SurfAbsThermalInt(SurfNum) to the appropriate value depending on shading type, and if there is no shade, it uses state.dataSurface->SurfActiveConstruction(SurfNum).
• CalcInteriorRadExchange uses SurfAbsThermalInt(SurfNum) for windows if there is a shade, but uses the base Surface(SurfNum).Construction otherwise --> should be SurfActiveConstruction(SurfNum)?
• CalcInteriorRadExchange checks for changes in window shading status similar to what is done in CheckGlazingShadingStatusChange - seems duplicative?
• CalcAngleFactorMRT recalculate surface emissivity times angle factor every time. It could store this and the sum and update only as needed. It's also using the base construction ignoring window shading or active construction.
• CalculateZoneMRT precalculates and saves state.dataHeatBalSurfMgr->SurfaceAE(SurfNum) and state.dataHeatBalSurfMgr->ZoneAESum(ZoneNum). These use the based construction and ignore window shading or active construction.
• Some of these functions use straight Temperature and some use Kelvin**4 during the accumulation. Maybe there's a good reason for them to be different?
• Any other places to look at?

1. Seems like there should be one place to store the current surface emissivity, and the current area*emissivity, and this should be used by all relevant calculations.
2. Seems like there should be one place to update the emissivities and A*Es based on status change due to window shading or EMS.
3. Then every function that needs it can simply grab the current Surface.AE values and use them directly with no checks on recalcs or construction numbers etc.
4. More??

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:
  https://unmethours.com/question/97414/does-e-consider-interior-shading-when-calculating-radiant-temperature/?comment=97416#post-id-97416
  https://unmethours.com/question/32800/does-e-consider-interior-shading-when-calculating-the-operative-temperature/

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)

[mjwitte]

Note that some of this code has been updated in #10244