Addresses #3936, subSurface Type reset when assigned to surface

[joseph-robertson]

Pull request overview

• Fixes SubSurface Type reset when assigned to surface #3936

Please read OpenStudio Pull Requests to better understand the OpenStudio Pull Request protocol.

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

• 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)
• Checked behavior in OpenStudioApplication, adjusted policies as needed (src/openstudio_lib/library/OpenStudioPolicy.xml)
• 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]

@joseph-robertson @kbenne

I wonder if there is really any interest in actually calling assignDefaultSubSurfaceType(). We could just do this instead, which would perhaps be less surprising?

  std::string SubSurface_Impl::subSurfaceType() const {
    std::string result;
    if (isSubSurfaceTypeDefaulted()) {
        result = this->defaultSubSurfaceType();
    } else {
       result = getString(OS_SubSurfaceFields::SubSurfaceType,true)).get();
    }

    return result;
  }

(The FixedWindow IDD Default would be pointless in that case).

[joseph-robertson]

@jmarrec

Can you explain this further? What would that block of code replace? What could be the surprise if it's left the way it is now?

[jmarrec]

Suggested change

bool emptySubSurfaceType = isEmpty(OS_SubSurfaceFields::SubSurfaceType);

[jmarrec]

Suggested change

	if (result && emptySurface && emptySubSurfaceType){
	if (result && emptySurface && isSubSurfaceTypeDefaulted()){

[jmarrec]

Can you explain this further? What would that block of code replace? What could be the surprise if it's left the way it is now?

Well, the API is actually assigning a value based on logic, which is what I would call a (smart) default. There will be no way of knowing whether the user actually assigned a value or if it was automatically assigned by Openstudio.
That would also mean that the logic to default the subSurfaceType would happen the first time you call setSurface but not the second. I doubt that you would do that often, but you might, if doing it in the bindings and messing it up the first time.

eg:

Make two surfaces: a wall, and a ceiling
Make a subSurface, do not explicitly set the subSurfaceType

# First time
subSurface.setSurface(Wall) 
     => the subSurfaceType was blank, so assignDefault is called 
        and it is now **harcoded** to "FixedWindow"

# Second time: Oops, I messed up, Let's correct it:
subSurface.setSurface(Ceiling) 
        => the subSurfaceType being hardcoded already, it is **not** changed 
           so I end up with a "FixedWindow" on a ceiling, instead of a "Skylight".

Perhaps it's not too big of a deal in E+ context though: I did check the FT, and it appears that the result in E+ will end up fine, as the only thing that matters for E+ is 'Door', 'GlassDoor' or 'Window'.

[jmarrec]

Side note: This blocks need review, and definitely corrections to the "changing SubSurfaceType to Dloor/GlassDoor" warnings

https://github.com/NREL/OpenStudio/blob/ff0e898ff96e0653e1b72da4200a3403b927fdaa/src/energyplus/ForwardTranslator/ForwardTranslateSubSurface.cpp#L71-L93

https://github.com/NREL/OpenStudio/blob/ff0e898ff96e0653e1b72da4200a3403b927fdaa/src/energyplus/ForwardTranslator/ForwardTranslateSubSurface.cpp#L86-L88

Should be: LOG(Warn, "SubSurface '" << modelObject.name().get() << "' uses fenestration construction, changing SubSurfaceType to GlassDoor");

Perhaps we should also double check that the flow control is handling every case... And we should probably catch all other situations (but Door/GlassDoor) where a non-opaque type is used and the construction is opaque (eg FixedWindow, but using an Opaque construction... though perhaps that should be done in model API)

[jmarrec]

@kbenne Can you review #4023 (comment) and decide whether we choose to change things or just go with this PR please? I am not extremely opinionated on the subject so it'd be great to have another pair of eyes.

[jmarrec]

Unless we decide to change the underlying logic (assign a default or just actually default it), these changes are good and ready to drop.

[jmarrec]

👍