ConstructionProperty:InternalHeatSource not being properly integrated with the surface heat balance
#11729
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -81,6 +81,7 @@ | |
| #include <EnergyPlus/DataLoopNode.hh> | ||
| #include <EnergyPlus/DataMoistureBalance.hh> | ||
| #include <EnergyPlus/DataMoistureBalanceEMPD.hh> | ||
| #include <EnergyPlus/DataPhotovoltaics.hh> | ||
| #include <EnergyPlus/DataRuntimeLanguage.hh> | ||
| #include <EnergyPlus/DataSizing.hh> | ||
| #include <EnergyPlus/DataSurfaces.hh> | ||
|
|
@@ -111,6 +112,7 @@ | |
| #include <EnergyPlus/OutputProcessor.hh> | ||
| #include <EnergyPlus/OutputReportPredefined.hh> | ||
| #include <EnergyPlus/OutputReportTabular.hh> | ||
| #include <EnergyPlus/Photovoltaics.hh> | ||
| #include <EnergyPlus/Psychrometrics.hh> | ||
| #include <EnergyPlus/ScheduleManager.hh> | ||
| #include <EnergyPlus/SolarShading.hh> | ||
|
|
@@ -162,6 +164,17 @@ void ManageSurfaceHeatBalance(EnergyPlusData &state) | |
| } | ||
| InitSurfaceHeatBalance(state); // Initialize all heat balance related parameters | ||
|
|
||
| // Surface-coupled PV must be initialized before its first temperature-dependent calculation. | ||
| if (state.dataPhotovoltaicState->GetInputFlag && | ||
| state.dataInputProcessing->inputProcessor->getNumObjectsFound(state, "Generator:Photovoltaic") > 0) { | ||
| Photovoltaics::GetPVInput(state); | ||
| state.dataPhotovoltaicState->GetInputFlag = false; | ||
| } | ||
|
|
||
| for (int PVnum = 1; PVnum <= state.dataPhotovoltaic->NumPVs; ++PVnum) { | ||
| Photovoltaics::SimSurfaceCoupledPV(state, PVnum); | ||
|
Collaborator
There was a problem hiding this comment. Hitting this before resolving the outside and inside heat balance. Seems fine.
Collaborator
Author
There was a problem hiding this comment. I think it's actually necessary, and is the crucial piece in this PR. We need to supply the PV heat sink that the surface heat balance eqns need for the current timestep. |
||
| } | ||
|
|
||
| // Solve the zone heat balance 'Detailed' solution | ||
| // Call the outside and inside surface heat balances | ||
| if (state.dataHeatBalSurfMgr->ManageSurfaceHeatBalancefirstTime) { | ||
|
|
@@ -231,6 +244,26 @@ void ManageSurfaceHeatBalance(EnergyPlusData &state) | |
| state.dataHeatBalSurfMgr->ManageSurfaceHeatBalancefirstTime = false; | ||
| } | ||
|
|
||
| void ResimulateSurfaceHeatBalanceForPV(EnergyPlusData &state) | ||
| { | ||
| // Repeat the coupled surface and PV calculations after electric simulation changes the PV heat sink. | ||
| if (!state.dataHVACGlobal->PVSurfaceHeatBalanceResimFlag) { | ||
| return; | ||
| } | ||
|
|
||
| for (int pass = 1; pass <= 2; ++pass) { | ||
| state.dataHVACGlobal->PVSurfaceHeatBalanceResimFlag = false; | ||
|
Collaborator
There was a problem hiding this comment. So, you set PVSurfaceHeatBalanceResimFlag to false, and then inside SimSurfaceCoupledPV it can drop into UpdatePVIntegrationSource, which then evaluates whether another iteration is needed. But only up to a max of 2. Seems OK, I think.
Contributor
There was a problem hiding this comment. Is the pass max of 2 due to the impact on the outside surface heat balance and needing it to better update?
Collaborator
Author
There was a problem hiding this comment. Here we are within an HVAC iteration. We want to limit each HVAC iteration to two surface/PV correction updates:
If after 2 passes PV surface sink is still changing, then the HVAC iteration loop can hit |
||
| CalcHeatBalanceOutsideSurf(state); | ||
| CalcHeatBalanceInsideSurf(state); | ||
| for (int PVnum = 1; PVnum <= state.dataPhotovoltaic->NumPVs; ++PVnum) { | ||
| Photovoltaics::SimSurfaceCoupledPV(state, PVnum); | ||
| } | ||
| if (!state.dataHVACGlobal->PVSurfaceHeatBalanceResimFlag) { | ||
| break; | ||
| } | ||
| } | ||
| } | ||
|
Comment on lines
+247
to
+265
Collaborator
There was a problem hiding this comment. New function to resim the outside and and inside surface heat balances, and then (?) resim the PV after. That's backwards from what you did earlier. Does it matter?
Contributor
There was a problem hiding this comment. Isn't it true that by the time the simulation has hit this point that it has already gone through the inside and outside heat balance? So, why would it need to do another round of that (for all surfaces) if the point here is that something in the PV systems has to update and another round of the heat balance has to take place? In UpdateFinalSurfaceHeatBalance, another round is needed because those systems are running at the HVAC time step and the zone heat balance needs to update based on the "average" of what has been happening. Since PV is running at the HVAC time step level, is something similar happening here? Or is there a different reason that I'm not understanding yet? I guess, why not call SimSurfaceCoupledPV and then just use the UpdateFinalSurfaceHeatBalance with an updated flag?
Collaborator
Author
There was a problem hiding this comment. @mitchute The differing orders are intentional:
@RKStrand I think we could use UpdateFinalSurfaceHeatBalance with an updated flag, but then we wouldn't be able to feed the corrected surface temperatures back through |
||
|
|
||
| // Beginning Initialization Section of the Module | ||
| //****************************************************************************** | ||
|
|
||
|
|
@@ -5433,6 +5466,10 @@ void UpdateFinalSurfaceHeatBalance(EnergyPlusData &state) | |
| // Call the outside and inside surface heat balances | ||
| CalcHeatBalanceOutsideSurf(state); | ||
| CalcHeatBalanceInsideSurf(state); | ||
|
|
||
| for (int PVnum = 1; PVnum <= state.dataPhotovoltaic->NumPVs; ++PVnum) { | ||
| Photovoltaics::SimSurfaceCoupledPV(state, PVnum); | ||
| } | ||
| } | ||
| } | ||
|
|
||
|
|
@@ -7238,7 +7275,6 @@ void CalcHeatBalanceOutsideSurf(EnergyPlusData &state, | |
| // // Locals | ||
| // // SUBROUTINE ARGUMENT DEFINITIONS: | ||
| // | ||
| // SUBROUTINE PARAMETER DEFINITIONS: | ||
| constexpr std::string_view RoutineNameGroundTemp("CalcHeatBalanceOutsideSurf:GroundTemp"); | ||
| constexpr std::string_view RoutineNameGroundTempFC("CalcHeatBalanceOutsideSurf:GroundTempFC"); | ||
|
|
||
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'm not proposing we change this now, just wondering why not integrate this with
InitSuraceHeatBalance?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's a good point. It might fit better there, but maybe the thinking was it's only for PV not for "all surfaces" and so maybe it doesn'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.
I think the idea is that
InitSurfaceHeatBalancedoes the heat balance initialization whereas this block is related to making sure PV data are available right before runningSimSurfaceCoupledPV(i.e., not doing any surface heat balancing).