-
Notifications
You must be signed in to change notification settings - Fork 398
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
FluidAPI Continued #10872
FluidAPI Continued #10872
Conversation
5ZoneAirCooledConvCoef_VSFan shows this error for develop and this branch (this type of error should not be a fatal):
AbsorptionChiller_Macro failed to run, for some reason, in develop and this branch (a regression tool issue?).
So I don't think these failures are related to changes in this branch. I'm not sure why the VSFan file runs on Linux, or if it even did. |
src/EnergyPlus/FluidProperties.cc
Outdated
@@ -4560,6 +4562,11 @@ namespace FluidProperties { | |||
return (refrigNum > 0) ? df->refrigs(refrigNum) : nullptr; | |||
} | |||
|
|||
RefrigProps *GetSteam(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.
Shortcut for getting built-in Steam properties object.
src/EnergyPlus/FluidProperties.cc
Outdated
@@ -4591,6 +4598,11 @@ namespace FluidProperties { | |||
return (glycolNum > 0) ? df->glycols(glycolNum) : nullptr; | |||
} | |||
|
|||
GlycolProps *GetWater(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.
Similar shortcut for getting built-in Water fluid properties object.
@@ -165,8 +165,6 @@ namespace Furnaces { | |||
// MODULE PARAMETER DEFINITIONS | |||
static constexpr std::string_view BlankString; | |||
|
|||
constexpr std::string_view fluidNameSteam("STEAM"); |
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.
There is a direct shortcut now for getting the steam fluid properties object that does not require a lookup by name.
src/EnergyPlus/Furnaces.cc
Outdated
SteamIndex = 0; // Function GetSatDensityRefrig will look up steam index if 0 is passed | ||
SteamDensity = FluidProperties::GetSatDensityRefrig( | ||
state, fluidNameSteam, state.dataFurnaces->TempSteamIn, 1.0, SteamIndex, getUnitaryHeatOnly); | ||
SteamDensity = FluidProperties::GetSteam(state)->getSatDensity(state, state.dataFurnaces->TempSteamIn, 1.0, getUnitaryHeatOnly); |
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.
Saving a pointer to the built-in steam fluid properties object would be a tiny bit faster, but not enough to matter for a one-off instance.
src/EnergyPlus/Humidifiers.cc
Outdated
WaterSpecHeatAvg = 0.5 * (GetSpecificHeatGlycol(state, format(fluidNameWater), TSteam, WaterIndex, CalledFrom) + | ||
GetSpecificHeatGlycol(state, format(fluidNameWater), Tref, WaterIndex, CalledFrom)); | ||
|
||
auto *water = FluidProperties::GetWater(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.
An index-based lookup like FluidProperties::GetPropertyRefrig(state, refrigNum, x, y, z);
requires three consecutive indirections: i) state.dataFluidProperties
, ii) dataFluidProperties->refrigs
, iii) refrigs(refrigNum)
. Saving the object pointer and making this into a method eliminates these three consecutive lookups. One small step for EnergyPlus.
This is ready to go. |
|
|
|
|
|
|
|
@@ -88,68 +88,68 @@ void registerErrorCallback(EnergyPlusState state, void (*f)(int, const char *)) | |||
Glycol glycolNew(EnergyPlusState state, const char *glycolName) | |||
{ | |||
auto *thisState = reinterpret_cast<EnergyPlus::EnergyPlusData *>(state); | |||
auto *glycol = new EnergyPlus::FluidProperties::GlycolAPI(*thisState, glycolName); | |||
auto *glycol = EnergyPlus::Fluid::GetGlycol(*thisState, EnergyPlus::Util::makeUPPER(glycolName)); |
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 call used to go through a GlycolAPI
object which held the GlycolName
and GlycolIndex
fields that were used by the old procedural API. We now have an object-oriented API that doesn't use those fields and so the internal GlycolProps *
can be directly cast to the extenrnal Glycol
type handle without the need for an intermediate object.
Pulled in develop which should get the code integrity check passing. I'll double check things and see if we can get the merge train rolling today with this one. |
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.
Alright, this is enormous, but a nice cleanup. I could think of some tweaks to make, but they are not necessary right now. With CI happy here, I think this will merge. I'll hold momentarily for clarification on the dangling #ifdef GET_OUT
block, but otherwise this seems ready. Thanks @amirroth
baseboard.AirOutletTemp = AirOutletTemp; | ||
baseboard.Power = LoadMet; | ||
baseboard.WaterMassFlowRate = WaterMassFlowRate; | ||
baseboard.AirMassFlowRate = AirMassFlowRate; |
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 especially nice :)
@@ -388,7 +388,7 @@ struct EnergyPlusData : BaseGlobalStruct | |||
std::unique_ptr<FansData> dataFans; | |||
std::unique_ptr<FaultsManagerData> dataFaultsMgr; | |||
std::unique_ptr<FluidCoolersData> dataFluidCoolers; | |||
std::unique_ptr<FluidData> dataFluidProps; | |||
std::unique_ptr<FluidData> dataFluid; |
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 almost dare say just ... fluid
? But that's for another 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.
I almost dare say just ...
fluid
? But that's for another discussion.
Normalize using short names.
@@ -521,7 +529,8 @@ namespace FluidProperties { | |||
int &GlycolIndex, // Index to Glycol Properties | |||
std::string_view CalledFrom // routine this function was called from (error messages) | |||
); | |||
|
|||
#endif // GET_OUT |
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.
Are you wanting to leave these #ifdef
s ?
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 will probably take them out in a later PR that cleans up the caching. I can also take them out now.
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.
Let's defer to later.
Can you look at IceThermalStorage.cc:1684? I think that quantity should be specific heat, not density, based on the name of the variable and the way it is used below. I left it as density so that there would be no diffs, but someone should take a look at this. |
Wait until you see |
src/EnergyPlus/IceThermalStorage.cc
Outdated
// BUG? I think this is supposed to be getSpecificHeat, not getDensity | ||
Real64 CpFluid = state.dataPlnt->PlantLoop(loopNum).glycol->getDensity(state, | ||
state.dataLoopNodes->Node(this->PltInletNodeNum).Temp, | ||
RoutineName); |
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, this should be specific heat. And this could be moved down to line 1718
Real64 DeltaTemp = Qice / CpFluid / this->ITSMassFlowRate;
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 that here? Or separately as a bug fix? Oh, another thing to normalize ... no unparenthesized divisions!
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.
Issue #10890 posted
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 would do this separate as a specific bug fix. You could do it here if you like, as long as the diffs are explained (which should be straight-forward).
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.
The thing with doing this here is if anyone ever goes back to see what the change was it would be hard to find it.
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.
Yep, I'm in full support of doing this in it's own minimalistic PR rather than adding it in here.
OK, got formatting applied (that's another issue to deal with very soon). The cp vs density change is deferred to later, along with the stray ifdef. I think this is ready as long as the integrity check passes. Any other final thoughts? |
Yes, Go Birds! |
This is a continuation of this PR which created an object-oriented API for FluidProperties. This PR propagates this API to all uses and comments out the previous procedural API.
In addition, the
GlycolAPI
andRefrigAPI
objects that served as wrappers for the external C API have been deleted. Those held theFluidName
andFluidIndex
parameters for the old procedural interface, which are no longer used. The new C API implementation usingGlycolProps *
andRefrigProps *
casting them to externally visible types for client management and casting back during API calls.Conceptually this is just a "simple" search-and-replace PR. If I knew Python as well as @Myoldmopar, I may have been able to do this using an actual search-and-replace.
There are no diffs as expected. This is ready to go.