Addresses #4946, allow TableLookup curves for Coil:*:WaterToAirHeatPump:EquationFit objects

[joseph-robertson]

Pull request overview

• Fixes WaterToAirHeatPumpEquationFit curves do not support Table:Lookup #4946

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]

This specifically expects a QuadvariateFunctions one in the IDD. Should we check that heatingCapacityCurve.numVariables() == 4 here?

Genuine question. Not saying we should necessarily, but since this is the general move of E+ to allow generic curve and table objects everywhere, this is bound to come up again, I think now's a good time to decide what to do/standardize. @kbenne @joseph-robertson

Pros:

• Checking is good because it catches user errors early instead of letting E+ complain (via CheckCurveDim)

Cons:

• More work for us
• Options:
  • Option1: we are hardcoding a curve.numVariables() check in each setter that takes a generic Curve, which potentially could fall out of date (though in this case I don't see why the number of expected independent variables would change suddenly in E+)
  • Option 2: The alternative is to add a special case in WorkspaceObject_Impl::setPointer or a new method WorkspaceObject_Impl::setCurvePointer
    • A new check in setPointer is going to impose a performance penalty for all objects
    • A new method specifically for Curves means we gotta be careful to use this one specifically for curves

[jmarrec]

actually for option 2, the best option is probably to a new bool ModelObject_Impl::setCurve(unsigned index, const Curve& curve) method that would check the IDD references and do the numVariables() check for us before setting the handle via WorkspaceObject_Impl::setPointer (or WorkspaceObject_Impl::setString for speed).

That'd avoid having to do lots of shenanigans in Workspace land to figure out the number of variables a Table object has.

[kbenne]

Increasingly, I'm starting to appreciate some value in not making OpenStudio too smart and therefore letting EnergyPlus report certain errors. I wouldn't be opposed to just accepting the generic Curve type throught OpenStudio and letting EnergyPlus report if there are errors.

That said if we do go with validation in OpenStudio then option 2, but with a new ::setCurve method seems right. Paying the performance penality for every call to the existing ::setPointer seems unacceptable to me.

[jmarrec]

I'm opening an issue here, that we may just end up closing. I realize the Curve objects are already fine (via the \reference check), only the TableLookup has this issue:

• Consider checking TableLookup number of independent variables when setting a Curve where the reference is <Uni/Bi/.../Quint>VariateFunctions #4982

[ci-commercialbuildings]

CI Results for b0f6f2e:

• Ubuntu 20.04:

• Ubuntu 22.04:

  • OpenStudio-3.7.0-alpha+7b1cde82e1-Ubuntu-22.04-x86_64.deb
  • OpenStudio-3.7.0-alpha+7b1cde82e1-Ubuntu-22.04-x86_64.tar.gz

• Darwin:

  • OpenStudio-3.7.0-alpha+1144281f7d-Darwin-x86_64.dmg
  • OpenStudio-3.7.0-alpha+1144281f7d-Darwin-x86_64.tar.gz

• Windows:

  • OpenStudio-3.7.0-alpha+a4d24644de-Windows.exe
  • OpenStudio-3.7.0-alpha+a4d24644de-Windows.tar.gz

• Code Coverage: