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.

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.

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.

3rd EDIT (in response to today's follow-up). Running the updated file (ideal loads scenario), I'm noticing (as before) the same (or similar) mismatches between layered construction materials of paired interzone surfaces. These generate the severe/fatal errors you're seeing, which you definitely need to fix.

Consider again "Surface 6" (a Floor in "Bedroom_Floor3") and its adjacent "Surface 9" (a RoofCeiling in "Bedroom_Floor2"). Both bedroom spaces reference their own default construction set, so both OpenStudio construction search distances are equal to 1. In such cases, each surface's layered construction must match the other (yet in reverse order). In your OSM file:

• "Interior Floor" (Surface 6): 5mm "Plaster" + 100mm "M11 100mm lightweight concrete"
• "Interior Ceiling" (Surface 9): 5mm "Plaster" + 100mm "MAT-CC05 4 HW CONCRETE"

Two things wrong here:

1. "Interior Ceiling" should have "Plaster" as the last material
2. Pick either 100mm concrete material for both constructions - they can't co-exist

I haven't gone through all reported interzone surface errors, but the first few I looked at have the same issue. So the fix should be fairly repetitive for you.

Regarding the other warnings (not errors): they are common and somewhat secondary at this point. They are EnergyPlus is pretty clear as to what the issue is, but here's an overview:

• Timestep vs conduction finite difference: EnergyPlus is informing you that it has reset the number of timesteps per hour to better suit the requested conduction finite difference option. Either drop the latter, or increase the number of timesteps per hour.
• ProcessScheduleInput: this warning is systematically generated whenever a schedule can't be synchronized with the requested number of timesteps per hour. One can have hourly schedules and run sub-hourly simulations. But several of your schedules switch at minute 28 for instance, while keeping 1 timestep per hour. If you're eventually running e.g. 6 timesteps per hour, you should ensure that changes in schedules occur at minutes 10, 20, 40, etc.
• Missing ground temperatures: EnergyPlus hasn't found a ground temperature object in the generated IDF, so it's assuming 18°C year round. Provide one one, or ignore the warning.
• Check Convexity: On one hand, EnergyPlus is informing you that it's purging collinear vertices in some of the surfaces (no harm done). On the other, it's informing you that some surfaces aren't convex. This may or may not be an issue, depending on the shadowing shadowing option and interior solar distribution distribution option you may select down the line. For now, you're fine.

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.

3rd EDIT (in response to today's follow-up). Running the updated file (ideal loads scenario), mode), I'm noticing (as before) the same (or similar) similar mismatches between layered construction materials of paired interzone (i.e. adjacent) surfaces. These generate the severe/fatal errors (no longer warnings) you're seeing, which you definitely need to fix.

Consider again "Surface 6" (a Floor in "Bedroom_Floor3") and its adjacent "Surface 9" (a RoofCeiling in "Bedroom_Floor2"). Both bedroom spaces now reference their own default construction set, so both OpenStudio construction search distances are equal to 1. In such cases, each surface's layered construction must match the other (yet in reverse order). In your OSM file:

• "Interior Floor" (Surface 6): 5mm "Plaster" + 100mm "M11 100mm lightweight concrete"
• "Interior Ceiling" (Surface 9): 5mm "Plaster" + 100mm "MAT-CC05 4 HW CONCRETE"

Two things wrong here:

1. "Interior Ceiling" should have "Plaster" as the last material
2. Pick either 100mm concrete material for both constructions - they can't co-existco-exist in paired/adjacent interzone surfaces

I haven't gone through all reported interzone surface errors, but the first few I looked at over have the same issue. So the fix should be fairly repetitive for you.

Regarding the other warnings (not errors): they are common and somewhat secondary at this point. EnergyPlus is pretty clear as to what the issue is, issues are - an overview:

• Timestep vs conduction finite difference: EnergyPlus is informing you that it has reset the number of timesteps per hour to better suit the requested conduction finite difference option. Either drop the latter, or increase the number of timesteps per hour.
• ProcessScheduleInput: this warning is systematically generated whenever a schedule can't be synchronized with the requested number of timesteps per hour. One can have hourly schedules and run sub-hourly simulations. But several of your schedules switch at minute 28 for instance, while keeping 1 timestep per hour. If you're eventually running e.g. 6 timesteps per hour, you should ensure that changes in schedules occur at minutes 10, 20, 40, etc.
• Missing ground temperatures: EnergyPlus hasn't found a ground temperature object in the generated IDF, so it's assuming 18°C year round. Provide one, or ignore the warning.
• Check Convexity: On one hand, EnergyPlus is informing you that it's purging collinear vertices in some of the surfaces (no harm done). On the other, it's informing you that some surfaces aren't convex. This may or may not be an issue, depending on the shadowing option and interior solar distribution option you may select down the line. For now, you're fine.