v24.1.0-IOFreeze: HeatExchangerAirToAirSensibleAndLatent

[joseph-robertson]

Pull request overview

Remove:

• Sensible Effectiveness at 75% Heating Air Flow
• Latent Effectiveness at 75% Heating Air Flow
• Sensible Effectiveness at 75% Cooling Air Flow
• LatentEffectiveness at 75% Cooling Air Flow

Add:

• Sensible Effectiveness of Heating Air Flow Curve Name
• Latent Effectiveness of Heating Air Flow Curve Name
• Sensible Effectiveness of Cooling Air Flow Curve Name
• Latent Effectiveness of Cooling Air Flow Curve Name

Questions:

• Do we want to support deprecated 75 methods? If so, seems like it would get tricky. They would need to operate on TableLookup objects, checking for existence, creating if not in existence, etc. I think even the 100 methods would need to modify the TableLookup objects...

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]

I was tempted to say we shouldn't even try to support backward compat here (just log a message saying the method does nothing now and you should call xxxCurve() method), but it seems some amount of backward compat is needed due to the SDD stuff.

I think I'm going to sleep on it, I'll try to think overnight about the amount of work that'd be necessary to properly support it.

[jmarrec]

Suggested change

	m_new.push_back(varList);
	ss << varList;
	m_new.push_back(var);
	ss << var;
	ss << varList;
	m_new.emplace_back(std::move(varList));
	ss << var;
	m_new.emplace_back(std::move(var));

[jmarrec]

Suggested change

	m_refactored.push_back(RefactoredObjectData(object, newObject));
	ss << newObject;
	ss << newObject;
	m_refactored.emplace_back(object, std::move(newObject));

[jmarrec]

I don't think so. The 100% value is set, and then the Curve will express the relationship of the Effectiveness as a function of the cooling air flow. This is the same thing that's used for a eg for a Chiller: you set the COP at rated conditions, and the curve modifies based on it.

I guess remove all these FIXME

[jmarrec]

Ok, so I get why this is here: to maintain the same effectiveness at different airflows as we had before.

• We could also not do this, similar to what E+ would do if you create this object in the IDF Editor
  • Leave them empty so the effectiveness is linear.
  • You could extract that bit of code into a public method, something like "applyDefaultEffectivenessCurves" or something for convenience, so that the user has the ability to use the former defaults with a single method call.
  • VT (already done here) + modification of the OS resources ruby tests would ensure we don't show EUI deviations.
• If we want these curves to be set, then please name the Table / Vars

[jmarrec]

• You have no proof that the outputValues()[0] corresponds to X=0.75. If I created that TableLookup manually, this may very well NOT be the case.

• You MUST check if the sensibleEffectivenessofHeatingAirFlowCurve() is initialized before you deference it or it'll throw if not. Your testing didn't catch it because the curves are optional BUT your constructor is initializing them.

• If I have set something other than a TableLookup (meaning a regular Curve:XXX object), you're also returning the 100 airflow without warning.

[jmarrec]

All the getters would work fine if we had TableLookup_Impl::evaluate, but we don't.

[jmarrec]

TODO: update the message.

DEPRECATED_AT_MSG(3, 8, 0, "Use sensibleEffectivenessofHeatingAirFlowCurve instead.");

[jmarrec]

No ambiguity in this case: if the curve isnt there, we can make a table lookup indeed.

[jmarrec]

same problems: can't dereference the curve object if not initialized, and the setting of the output values isn't good since you're not also modifying the independent variable.

[jmarrec]

Side note, but related to a potential final conclusion on whether we should try to maintain backward compatibilty: The TableLookup interface is crap from a user experience perspective. The former TableMultiVariableLookup was better in that sense since you could do addPoint(x, y) and it'd detect if the x value was already there, and you could call boost::optional<double> yValue(const std::vector<double>& xValues)

I think we should re-add that capability...

[jmarrec]

Ok, so it seems we do want to support some amount of backward compatibility in setting the 75% effectivness due to this MapHVAC stuff.

I don't think the current implementation here is good though. You're creating the object, so you're in control. You should create the curve instead of checking whether it exists.

[jmarrec]

I think the opposite way (OSM > SDD) is missing too.

[jmarrec]

Options:

• Remove backward compatibility altogether. This would require the SDD stuff to be updated... Is that an option @kbenne ?
• Implement backward compatibility manually. This requires a bit of code to do it right, I'm guessing I can do it in about 4 hours.
• Implement TableLookup_Impl::evaluate: this would ideally require using https://github.com/bigladder/btwxt like E+ does, but the packaging is problematic. It has submodules dependencies (google test, fmt and bigladder's courier) and therefore creating a conan recipe is quite problematic. Using CMAke's ExternalPackageAdd isn't really helping either since some of these dependencies we also do have and we don't want to mix up deps versions.

[ci-commercialbuildings]

CI Results for 8c9e74e:

• Ubuntu 20.04:

• Ubuntu 22.04:

• Darwin:

  • OpenStudio-3.8.0+8c9e74e228-Darwin-x86_64.dmg
  • OpenStudio-3.8.0+8c9e74e228-Darwin-x86_64.tar.gz

• Windows:

  • OpenStudio-3.8.0+8c9e74e228-Windows.exe
  • OpenStudio-3.8.0+8c9e74e228-Windows.tar.gz

• Code Coverage:

[jmarrec]

@joseph-robertson I made some changes, this is good enough to go into the main IO freeze branch

[mdahlhausen]

@joseph-robertson @jmarrec we may need to modify the work done in this PR. Some models made in OpenStudio are hitting a failure in EnergyPlus with the default curve set: NREL/EnergyPlus#10464

[mdahlhausen]

update - issue is the default table from OpenStudio has a divide by zero. Need to change the OpenStudio default.