Skip to content
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

Merged
merged 22 commits into from
Jan 9, 2025
Merged

FluidAPI Continued #10872

merged 22 commits into from
Jan 9, 2025

Conversation

amirroth
Copy link
Collaborator

@amirroth amirroth commented Dec 22, 2024

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 and RefrigAPI objects that served as wrappers for the external C API have been deleted. Those held the FluidName and FluidIndex parameters for the old procedural interface, which are no longer used. The new C API implementation using GlycolProps * and RefrigProps * 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.

@amirroth amirroth assigned amirroth and Myoldmopar and unassigned amirroth Dec 23, 2024
@amirroth amirroth added Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring DoNotPublish Includes changes that shouldn't be reported in the changelog labels Dec 23, 2024
@amirroth amirroth added this to the EnergyPlus 25.1 milestone Dec 23, 2024
@rraustad
Copy link
Contributor

Local results:
image

@amirroth
Copy link
Collaborator Author

amirroth commented Dec 24, 2024

Local results: image

Why did this not show up in my inbox? Also, this doesn't jibe with the successful test report below. Is this stale maybe?

@rraustad
Copy link
Contributor

5ZoneAirCooledConvCoef_VSFan shows this error for develop and this branch (this type of error should not be a fatal):

** Severe  ** Iteration limit exceeded in calculating variable speed fan powered box 1st stage heating fan speed
**   ~~~   **  Environment=RUN PERIOD 1, at Simulation time=09/30 06:27 - 06:30
**  Fatal  ** PIU control failed for AirTerminal:SingleDuct:ParallelPIU:Reheat:SPACE4-1 VAV REHEAT 

AbsorptionChiller_Macro failed to run, for some reason, in develop and this branch (a regression tool issue?).
ShopWithPVandLiIonBattery failed in this branch with a sqlite error:

SQLite3 message, sqlite.err open for processing!

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.

@@ -4560,6 +4562,11 @@ namespace FluidProperties {
return (refrigNum > 0) ? df->refrigs(refrigNum) : nullptr;
}

RefrigProps *GetSteam(EnergyPlusData &state) {
Copy link
Collaborator Author

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.

@@ -4591,6 +4598,11 @@ namespace FluidProperties {
return (glycolNum > 0) ? df->glycols(glycolNum) : nullptr;
}

GlycolProps *GetWater(EnergyPlusData &state) {
Copy link
Collaborator Author

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");
Copy link
Collaborator Author

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.

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);
Copy link
Collaborator Author

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.

WaterSpecHeatAvg = 0.5 * (GetSpecificHeatGlycol(state, format(fluidNameWater), TSteam, WaterIndex, CalledFrom) +
GetSpecificHeatGlycol(state, format(fluidNameWater), Tref, WaterIndex, CalledFrom));

auto *water = FluidProperties::GetWater(state);
Copy link
Collaborator Author

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.

@amirroth
Copy link
Collaborator Author

amirroth commented Jan 3, 2025

This is ready to go.

Copy link

github-actions bot commented Jan 4, 2025

⚠️ Regressions detected on macos-14 for commit 8eb6fce

Regression Summary
  • EIO: 22
  • ERR: 17
  • ESO Big Diffs: 23
  • MTR Big Diffs: 13
  • Table Big Diffs: 26
  • Table String Diffs: 22
  • ESO Small Diffs: 2
  • MTR Small Diffs: 2
  • GLHE: 2

Copy link

github-actions bot commented Jan 4, 2025

⚠️ Regressions detected on macos-14 for commit 9628137

Regression Summary
  • EIO: 4
  • Table Big Diffs: 2
  • ESO Small Diffs: 3
  • Table Small Diffs: 2

Copy link

github-actions bot commented Jan 5, 2025

⚠️ Regressions detected on macos-14 for commit a72aecb

Regression Summary
  • EIO: 4
  • Table Big Diffs: 2
  • ESO Small Diffs: 3
  • Table Small Diffs: 2

Copy link

github-actions bot commented Jan 5, 2025

⚠️ Regressions detected on macos-14 for commit 7857d91

Regression Summary
  • EIO: 4
  • Table Big Diffs: 2
  • ESO Small Diffs: 3
  • Table Small Diffs: 2

Copy link

github-actions bot commented Jan 6, 2025

⚠️ Regressions detected on macos-14 for commit 269c8f0

Regression Summary
  • EIO: 6
  • ESO Big Diffs: 2
  • MTR Big Diffs: 1
  • Table Big Diffs: 3
  • ESO Small Diffs: 3
  • Table Small Diffs: 3
  • MTR Small Diffs: 1

@amirroth amirroth marked this pull request as draft January 6, 2025 14:09
Copy link

github-actions bot commented Jan 6, 2025

⚠️ Regressions detected on macos-14 for commit b9ef692

Regression Summary
  • EIO: 6
  • ESO Big Diffs: 2
  • MTR Big Diffs: 1
  • Table Big Diffs: 3
  • ESO Small Diffs: 3
  • Table Small Diffs: 3
  • MTR Small Diffs: 1

Copy link

github-actions bot commented Jan 6, 2025

⚠️ Regressions detected on macos-14 for commit 7ec6935

Regression Summary
  • EIO: 6
  • ESO Big Diffs: 2
  • MTR Big Diffs: 1
  • Table Big Diffs: 3
  • ESO Small Diffs: 3
  • Table Small Diffs: 3
  • MTR Small Diffs: 1

@amirroth amirroth marked this pull request as ready for review January 8, 2025 14:27
@@ -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));
Copy link
Collaborator Author

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.

@Myoldmopar
Copy link
Member

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.

Copy link
Member

@Myoldmopar Myoldmopar left a 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;
Copy link
Member

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;
Copy link
Member

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.

Copy link
Collaborator Author

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
Copy link
Member

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 #ifdefs ?

Copy link
Collaborator Author

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.

Copy link
Member

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.

@amirroth
Copy link
Collaborator Author

amirroth commented Jan 9, 2025

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.

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.

@amirroth
Copy link
Collaborator Author

amirroth commented Jan 9, 2025

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

Wait until you see ScheduleAPI.

// 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);
Copy link
Contributor

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;

Copy link
Collaborator Author

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!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue #10890 posted

Copy link
Contributor

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).

Copy link
Contributor

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.

Copy link
Member

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.

@Myoldmopar
Copy link
Member

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?

@amirroth
Copy link
Collaborator Author

amirroth commented Jan 9, 2025

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!

@Myoldmopar Myoldmopar merged commit f224405 into develop Jan 9, 2025
6 checks passed
@Myoldmopar Myoldmopar deleted the FluidAPI2 branch January 9, 2025 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DoNotPublish Includes changes that shouldn't be reported in the changelog Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants