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

@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?

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

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

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)

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