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

V23.2.0-IOFreeze - Fuel Type enum changes (DistrictHeatingWater / DistrictHeatingSteam) #4968

Merged
merged 11 commits into from
Sep 19, 2023

Conversation

jmarrec
Copy link
Collaborator

@jmarrec jmarrec commented Sep 18, 2023

Pull request overview

  • Fixes Partially the Update to EnergyPlus 23.2.0 #4934

  • Fuel Type enum changes (OtherEquipment, Exterior:FuelEquipment, ZoneHVAC:HybridUnitaryHVAC, etc.)

    • "DistrictHeating" to "DistrictHeatingWater"
    • "Steam" to "DistrictHeatingSteam"

Pull Request Author

  • Model API Changes / Additions
  • Any new or modified fields have been implemented in the EnergyPlus ForwardTranslator (and ReverseTranslator as appropriate)
  • Model API methods are tested (in src/model/test)
  • EnergyPlus ForwardTranslator Tests (in src/energyplus/Test)
  • If a new object or method, added a test in NREL/OpenStudio-resources: Add Link
  • If needed, added VersionTranslation rules for the objects (src/osversion/VersionTranslator.cpp)
  • Verified that C# bindings built fine on Windows, partial classes used as needed, etc.
  • All new and existing tests passes
  • If methods have been deprecated, update rest of code to use the new methods

Labels:

  • If change to an IDD file, add the label IDDChange
  • If breaking existing API, add the label APIChange
  • If deemed ready, add label Pull Request - Ready for CI so that CI builds your PR

Review Checklist

This will not be exhaustively relevant to every PR.

  • Perform a Code Review on GitHub
  • Code Style, strip trailing whitespace, etc.
  • All related changes have been implemented: model changes, model tests, FT changes, FT tests, VersionTranslation, OS App
  • Labeling is ok
  • If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
  • If feature, test running new feature, try creative ways to break it
  • CI status: all green or justified

@jmarrec jmarrec added component - Model component - IDF Translation Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge. labels Sep 18, 2023
@jmarrec jmarrec self-assigned this Sep 18, 2023
@jmarrec jmarrec mentioned this pull request Sep 18, 2023
26 tasks
Comment on lines +36710 to +36711
\key DistrictHeatingSteam
\key DistrictHeatingWater
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Renames in OpenStudio.idd

Comment on lines +37 to +42
"District Cooling Water Rate",
"District Cooling Water Energy",
"District Cooling Water Inlet Temperature",
"District Cooling Water Outlet Temperature",
"District Cooling Water Mass Flow Rate",
};
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Update out vars

Comment on lines +76 to +78
((Steam)(DistrictHeatingSteam))
((DistrictCooling))
((DistrictHeating))
((DistrictHeating)(DistrictHeatingWater))
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Aliases on FuelType Enum. SHould always use valueDescription() to interface with E+ now

Comment on lines 39 to +43
/** \class FuelType
* \brief EnergyPlus meterable fuel types
* \details See the OPENSTUDIO_ENUM documentation in utilities/core/Enum.hpp. The actual
* \brief EnergyPlus meterable fuel types.
* \details Use the valueDescription() for interfacing with EnergyPlus or setting an IDD field.
*
* See the OPENSTUDIO_ENUM documentation in utilities/core/Enum.hpp. The actual
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Clarify that you need valueDescription for E+ in docstring

Comment on lines +71 to 72
bool setFuelType(const FuelType& fuelType);
bool setFuelType(const std::string& fuelType);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, so for all types (ALMOST) that received a change, I implement an overload setFuelType. This overload is called by the setFuelType(std::string& one)

I do not do it for PythonPlugin:OutputVariable and EMS:MeteredOutputVariable.
The reason is that they support a ton more variables (and are less common objects). See this nice table I made here: https://docs.google.com/spreadsheets/d/1ZjLABsEOAYmAyrrI6iM1JMJi6uRYBMWHlu3AUcx40iE/edit#gid=518449229

They support all of these.

ENERGYTRANSFER MAINSWATERSUPPLY ONSITEWATERPRODUCED RAINWATERCOLLECTED SOLARAIRHEATING SOLARWATERHEATING CONDENSATEWATERCOLLECTED WATERUSE WELLWATERDRAWN

Comment on lines +201 to +212
bool MeterCustom::setFuelType(const std::string& fuelType) {
// Special case for custom meters, the only ones that have "Generic" as a possibility
if (openstudio::istringEqual("Generic", fuelType)) {
return this->setString(OS_Meter_CustomFields::FuelType, "Generic");
}
try {
return setFuelType(FuelType{fuelType});
} catch (std::runtime_error& e) {
LOG(Debug, e.what());
return false;
}
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So here is the setFuelType(std::string) one. As you can see, here I handle a special case, otherwise I defer to setFuelType(FuelType)

This allows me to call both

setFuelType("Steam") and setFuelType("DistrictHeatingSteam")

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's a special case because "Generic" is not added to DataEnums?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes. See the comment.

    // Special case for custom meters, the only ones that have "Generic" as a possibility

I don't think we want to add Generic to FuelType enum just for this object.

Comment on lines +412 to +413
"Baseboard)?:?(Electricity|Gasoline|NaturalGas|Diesel|Coal|FuelOilNo1|FuelOilNo2|Propane|Water|DistrictHeatingSteam|DistrictCooling|"
"DistrictHeatingWater|OtherFuel1|OtherFuel2|EnergyTransfer)?:?(Facility|Building|HVAC|Zone|System|Plant)?:?([^:]*?)?$");
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Update OutputMeter regex

Comment on lines 7901 to 7915
// Making the map case-insentive by providing a Comparator `IstringCompare`
const std::map<std::string, std::string, openstudio::IstringCompare> replaceFuelTypesMap{{
{"Steam", "DistrictHeatingSteam"},
{"DistrictHeating", "DistrictHeatingWater"},
// Additionally, for UtilityBill, align the IDD choices to E+. This will also be covered by this
{"FuelOil_1", "FuelOilNo1"},
{"FuelOil_2", "FuelOilNo2"},
{"OtherFuel_1", "OtherFuel1"},
{"OtherFuel_2", "OtherFuel2"},
}};

const std::multimap<std::string, int> fuelTypeRenamesMap{{
{"OS:OtherEquipment", 6}, // Fuel Type
{"OS:Exterior:FuelEquipment", 4}, // Fuel Use Type
{"OS:WaterHeater:Mixed", 11}, // Heater Fuel Type
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Lots of VT

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

VT Testing

Comment on lines +3477 to +3478
TEST_F(OSVersionFixture, update_3_6_1_to_3_7_0_fuelTypeRenames) {
openstudio::path osmPath = resourcesPath() / toPath("osversion/3_7_0/test_vt_FuelTypeRenames.osm");
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Lots of VT testing

@joseph-robertson joseph-robertson changed the title V23.2.0-IOFreeze - Fuel Type enum changes (DistrictHeatingWater / DistrictHeatingSteam V23.2.0-IOFreeze - Fuel Type enum changes (DistrictHeatingWater / DistrictHeatingSteam) Sep 18, 2023
Copy link
Collaborator

@joseph-robertson joseph-robertson left a comment

Choose a reason for hiding this comment

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

This looks great. Just a few clarifying questions. I'd also suggest a brief high-level description of this PR in the description box.

@@ -15410,7 +15410,6 @@ Exterior:FuelEquipment,
\required-field
\type choice
\key Electricity
\key Water
Copy link
Collaborator

Choose a reason for hiding this comment

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

So before, "Water" and "DistrictHeating" were redundant?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Or maybe "Water" was never mapped to?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Exterior:WaterEquipment is there for a reason. This is a change I'm upstreaming to E+ as well.

@@ -35642,7 +35641,7 @@ OS:LifeCycleCost:UsePriceEscalation,
\key ElectricitySurplusSold
\key ElectricityNet
\key NaturalGas
\key Steam
\key DistrictHeatingSteam
Copy link
Collaborator

Choose a reason for hiding this comment

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

No "DistrictHeatingWater" here?

Copy link
Collaborator Author

@jmarrec jmarrec Sep 19, 2023

Choose a reason for hiding this comment

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

E+ doesn't support it yet, I'm trying to fix that in:

Wasn't sure if I should try to support it just yet when E+ doesn't.
If that PR is merged, when we received a new E+ package, we'll catch the update.

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 added a specific note in #4934

image

\key OtherFuel_2
\key DistrictHeatingWater
\key OtherFuel1
\key OtherFuel2
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, how were these able to slip through the cracks?

Copy link
Collaborator Author

@jmarrec jmarrec Sep 19, 2023

Choose a reason for hiding this comment

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

UtilityBill actually uses FuelType and FuelType::valueDescription to write the E+ IDF, so it was working just fine already

    explicit UtilityBill(const FuelType& fuelType, const Model& model);

I'm just aiming for consistency here.

@@ -130,8 +131,8 @@ namespace model {
OS_ASSERT(result);
}

bool ExteriorFuelEquipment_Impl::setFuelType(const std::string& fuelType) {
bool result = setString(OS_Exterior_FuelEquipmentFields::FuelUseType, fuelType);
bool ExteriorFuelEquipment_Impl::setFuelType(const FuelType& fuelType) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should've been using FuelType before?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's my opinion, yes. Cf #4940 (comment)

Comment on lines +201 to +212
bool MeterCustom::setFuelType(const std::string& fuelType) {
// Special case for custom meters, the only ones that have "Generic" as a possibility
if (openstudio::istringEqual("Generic", fuelType)) {
return this->setString(OS_Meter_CustomFields::FuelType, "Generic");
}
try {
return setFuelType(FuelType{fuelType});
} catch (std::runtime_error& e) {
LOG(Debug, e.what());
return false;
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

It's a special case because "Generic" is not added to DataEnums?

@@ -7897,6 +7898,83 @@ namespace osversion {
{"OS:Coil:WaterHeating:AirToWaterHeatPump:Wrapped", 13},
}};

// Making the map case-insentive by providing a Comparator `IstringCompare`
Copy link
Collaborator

Choose a reason for hiding this comment

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

insensitive

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'll fix it in the next PR that rename OS:DistictHeating to OS:DistrictHeating:Water and takes in your DistrictHeating:Steam PR. Trying to save CI cycles.
(this is also a copy paste, I made that typo a long time ago :) )

@@ -8258,6 +8336,105 @@ namespace osversion {

ss << object;

} else if (iddname == "OS:Boiler:HotWater") {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm confused why BoilerHotWater is here. Is this branch just slightly out of date?

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 just moved it up in the if-else ladder.

Handle objects first, then do the lookup in the map things.

@jmarrec jmarrec merged commit 69021c4 into v23.2.0-IOFreeze Sep 19, 2023
@jmarrec jmarrec deleted the v23.2.0-IOFreeze-fuel_types branch September 19, 2023 07:32
jmarrec added a commit that referenced this pull request Sep 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component - IDF Translation component - Model Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants