Revision history [back]

The linked file (Google Drive) requires authorization to access (you'd preferably want to make it public).

OpenStudio's forward translation (to EnergyPlus) code (here or here) logs this info/warning (not an error, right?) when paired interzone surfaces (e.g. 2 adjacent walls, adjacent floor & ceiling) don't inherit the same (reversed) construction from their respective default construction set. This is OK - OpenStudio is simply informing you that it has detected an initial conflict, and that it has picked Surface 9's default construction (instead of Surface 6's).

This determination is based on OpenStudio's "search distance", which isn't really informative to the typical user. It refers to OpenStudio's building-to-space hierarchy when assigning default constructions, default schedules, etc. When sorting out potential conflicts, OpenStudio picks the shortest "search distance" (e.g. "1" is preferred over "3"), as described here:

a space's default construction set                  search distance = 1
a space's space type's default construction set     search distance = 2
a space's building story's default construction set search distance = 3
a building's default construction set               search distance = 4
a building's space type's default construction set  search distance = 5

Open your .osm file with a text editor. CTRL-F for Surface 9. Then determine (through successive searches) whether its space has a "space" default construction set, or a "spacetype" construction set, etc. Do the same for Surface 6. You're likely to find something like Surface 6's space has a "building" default construction set, while Surface 9's space has a "spacetype" default construction set, or something similar. Again, this is not something to worry about ... if that's what you intended when assigning default construction sets. Hope this helps.

The linked file (Google Drive) requires authorization to access (you'd preferably want to make it public).

OpenStudio's forward translation (to EnergyPlus) code (here or here) logs this info/warning (not an error, right?) when paired interzone surfaces (e.g. 2 adjacent walls, adjacent floor & ceiling) don't inherit the same (reversed) construction from their each's respective default construction set. This is OK - OpenStudio is simply informing informing you that it has detected an initial conflict, and that it has picked Surface 9's default construction (instead of Surface 6's).

This determination is based on OpenStudio's "search distance", which I admit isn't really informative to the typical user. It refers to OpenStudio's building-to-space hierarchy when assigning default constructions, default schedules, etc. When sorting out potential conflicts, OpenStudio picks the shortest "search distance" (e.g. "1" is preferred over "3"), as described here:

a space's default construction set                  search distance = 1
a space's space type's default construction set     search distance = 2
a space's building story's default construction set search distance = 3
a building's default construction set               search distance = 4
a building's space type's default construction set  search distance = 5

Open your .osm file with a text editor. CTRL-F for Surface 9. "Surface 9". Then determine (through successive searches) whether its space has a "space" default construction set, or a "spacetype" default construction set, etc. Do the same for Surface 6. You're likely to find something like Surface 6's space has a "building" default construction set, while Surface 9's space has a "spacetype" default construction set, or set (or something similar. similar).

Again, this is not isn't typically something to worry about ... if that's what you actually intended when assigning default construction sets. sets with different "search distances". Hope this helps.

The linked file (Google Drive) requires authorization to access (you'd preferably want to make it public).

OpenStudio's forward translation (to EnergyPlus) code here or here logs this info/warning (not an error, right?) when paired interzone surfaces (e.g. 2 adjacent walls, adjacent floor & ceiling) don't inherit the same (reversed) construction from each's respective default construction set. This is OK - OpenStudio is simply informing you that it has detected an initial conflict, and that it has picked Surface 9's Surface 9's default construction (instead of Surface 6's).Surface 6's).

This determination is based on OpenStudio's "search distance", which I admit isn't really informative to the typical user. It refers to OpenStudio's building-to-space hierarchy when assigning default constructions, default schedules, etc. When sorting out potential conflicts, OpenStudio picks the shortest "search distance" (e.g. "1" is preferred over "3"), as described here:

a space's default construction set                  search distance = 1
a space's space type's default construction set     search distance = 2
a space's building story's default construction set search distance = 3
a building's default construction set               search distance = 4
a building's space type's default construction set  search distance = 5

Open your .osm file with a text editor. CTRL-F for "Surface 9". "Surface 9". Then determine (through successive searches) whether its space has inherits a "space" default construction set, or a "spacetype" default construction set, etc. Do the same for Surface 6. Surface 6. You're likely to find something like Surface 6's Surface 6's space has a inherits the "building" default construction set, while Surface 9's Surface 9's space has references a "spacetype" default construction set (or something similar).

Again, this isn't typically something to worry about ... if that's what you actually intended when assigning default construction sets with different "search distances". Hope this helps.

The linked file (Google Drive) requires authorization to access (you'd preferably want to make it public).

OpenStudio's forward translation (to EnergyPlus) code here or here logs this info/warning (not an error, right?) when paired interzone surfaces (e.g. 2 adjacent walls, adjacent floor & ceiling) don't inherit the same (reversed) construction from each's default construction set. This is OK - OpenStudio is simply informing you that it has detected an initial conflict, and that it has picked Surface 9's default construction (instead of Surface 6's).

This determination is based on OpenStudio's "search distance", which I admit isn't really informative to the typical user. It refers to OpenStudio's building-to-space hierarchy when assigning default constructions, default schedules, etc. When sorting out potential conflicts, OpenStudio picks the shortest "search distance" (e.g. "1" is preferred over "3"), as described here:

a space's default construction set                  search distance = 1
a space's space type's default construction set     search distance = 2
a space's building story's default construction set search distance = 3
a building's default construction set               search distance = 4
a building's space type's default construction set  search distance = 5

Open your .osm file with a text editor. CTRL-F for "Surface 9". Then determine (through successive searches) whether its space inherits a "space" default construction set, or a "spacetype" default construction set, etc. Do the same for Surface 6. You're likely to find something like Surface 6's space inherits the "building" default construction set, while Surface 9's space references a "spacetype" default construction set (or something similar).

Again, this isn't typically something to worry about ... if that's what you actually intended when assigning default construction sets with different "search distances". Hope this helps.

[openstudio.energyplus.ForwardTranslator] Surfaces 'Surface 9', and 'Surface 6' reference different constructions, choosing 'Surface 6''s construction based on search distance.

The linked file (Google Drive) requires authorization to access (you'd preferably want to make it public).

OpenStudio's forward translation (to EnergyPlus) code here or here logs this info/warning (not an error, right?) when paired interzone surfaces (e.g. 2 adjacent walls, adjacent floor & ceiling) don't inherit the same (reversed) construction from each's default construction set. This is OK - OpenStudio is simply informing you that it has detected an initial conflict, and that it has picked Surface 9's default construction (instead of Surface 6's).

This determination is based on OpenStudio's "search distance", which I admit isn't really informative to the typical user. It refers to OpenStudio's building-to-space hierarchy when assigning default constructions, default schedules, etc. When sorting out potential conflicts, OpenStudio picks the shortest "search distance" (e.g. "1" is preferred over "3"), as described here:

a space's default construction set                  search distance = 1
a space's space type's default construction set     search distance = 2
a space's building story's default construction set search distance = 3
a building's default construction set               search distance = 4
a building's space type's default construction set  search distance = 5

Open your .osm file with a text editor. CTRL-F for "Surface 9". Then determine (through successive searches) whether its space inherits a "space" default construction set, or a "spacetype" default construction set, etc. Do the same for Surface 6. You're likely to find something like Surface 6's space inherits the "building" default construction set, while Surface 9's space references a "spacetype" default construction set (or something similar).

Again, this isn't typically something to worry about ... if that's what you actually intended when assigning default construction sets with different "search distances". Hope this helps.

EDIT. Thanks for providing access. Going through your .osm file, I notice "Surface 6" has a shorter search distance than "Surface 9" - not the other way around (as originally stated). "Surface 6" instead has a construction hard-assigned to it - not inherited from a default construction set. When I run OpenStudio, I get the following:

[openstudio.energyplus.ForwardTranslator] Surfaces 'Surface 9', and 'Surface 6' reference different constructions, choosing 'Surface 6''s construction based on search distance.

So OpenStudio's search distance prioritization is working as expected, as hard-assigned constructions take precedence over default construction sets (is it possible the uploaded file had since been updated?). The EnergyPlus simulation ultimately fails because of a severe error related to an invalid material thickness - easy to fix. Otherwise, there are a fair number of geometry issues to fix ...

The linked file (Google Drive) requires authorization to access (you'd preferably want to make it public).

OpenStudio's forward translation (to EnergyPlus) code here or here logs this info/warning (not an error, right?) when paired interzone surfaces (e.g. 2 adjacent walls, adjacent floor & ceiling) don't inherit the same (reversed) construction from each's default construction set. This is OK - OpenStudio is simply informing you that it has detected an initial conflict, and that it has picked Surface 9's default construction (instead of Surface 6's).

This determination is based on OpenStudio's "search distance", which I admit isn't really informative to the typical user. It refers to OpenStudio's building-to-space hierarchy when assigning default constructions, default schedules, etc. When sorting out potential conflicts, OpenStudio picks the shortest "search distance" (e.g. "1" is preferred over "3"), as described here:

a space's default construction set                  search distance = 1
a space's space type's default construction set     search distance = 2
a space's building story's default construction set search distance = 3
a building's default construction set               search distance = 4
a building's space type's default construction set  search distance = 5

Open your .osm file with a text editor. CTRL-F for "Surface 9". Then determine (through successive searches) whether its space inherits a "space" default construction set, or a "spacetype" default construction set, etc. Do the same for Surface 6. You're likely to find something like Surface 6's space inherits the "building" default construction set, while Surface 9's space references a "spacetype" default construction set (or something similar).

Again, this isn't typically something to worry about ... if that's what you actually intended when assigning default construction sets with different "search distances". Hope this helps.

EDIT. Thanks for providing access. Going through your .osm file, I notice "Surface 6" has a shorter search distance than "Surface 9" - not the other way around (as originally stated). "Surface 6" instead has a construction hard-assigned to it - not inherited from a default construction set. When I run OpenStudio, I get the following:

[openstudio.energyplus.ForwardTranslator] Surfaces 'Surface 9', and 'Surface 6' reference different constructions, choosing 'Surface 6''s construction based on search distance.

So OpenStudio's search distance prioritization is working as expected, as hard-assigned constructions take precedence over default construction sets (is it possible the uploaded file had since been updated?). The EnergyPlus simulation ultimately fails because of a severe error related to an invalid material thickness - easy to fix. Otherwise, there are a fair number of geometry issues to fix ...

2nd EDIT (in relation to reported geometry "errors", see your follow-up comment). I have to backtrack a bit, I think. Having gone through parts of your .osm file, I'm unable to find anything wrong with surface geometry. This may instead be related to stacking multiple spaces (25) within a limited number of thermal zones (8) in your model. EnergyPlus may be tripping over interspace floor/ceiling pairs (within the same thermal zone), when they intersect 2 exterior walls (again within the same thermal zone). EnergyPlus offers the space option as of v9.6 (2021), yet a series of fixes and adjustments have been introduced since then, e.g. here and here. Maybe this still needs tweaking in some cases like yours. Maybe follow to the letter what's recommended in the docs. Then again, this may be linked to related OpenStudio forward translation code - I can't say. As a quick fix, I suggest either option:

1. assign a single thermal zone per space (25 thermal zones rather than 8), OR
2. hard-assign ceiling height, volume and floor area for each of the 8 thermal zones

One or the other should get rid of the warnings, yet I have a preference for option 1.