Question-and-Answer Resource for the Building Energy Modeling Community
 | 1 | initial version |
Thank you @rsunnam. I appreciate your suggestions and have spent considerable time redrawing my two floor plans, taking great care to snap to end points and ensure lines are drawn in the same plane. After having done this, I then surface-matched each floor plan in a separate .osm (in the plugin), and when viewing in render by boundary mode the interior walls were all green and all surfaces were as they should be. However, when the two different floor plans are extruded in the same .osm file and then surface-matched in the plugin, although all interior walls are green and all exterior walls and roof blue, still the entire ceiling of the first floor is outside bound and the entire floor of second floor shows as ground in the Inspector. And there are still those pesky "facets" that show up when I intersect the model.
Thus, I tend to think that the problem lies with the fact that the two floor plans are not identical. The intersection and surface-matching tools present no problems when I copy/paste to stack identical floors. But surely OS has the capability to accommodate different floor plans at different levels as would be the case in such a retrofit project ... OS is so powerful and useful, so I'm convinced the problem must be on my end!
Maybe my workflow is flawed? I drew the first floor with sketchup tools in a separate .skp file, I then copy/pasted the floor plan as a group into a new .skp file (which is not linked to the .osm I am drawing in, since I have found that linking an .osm to a .skp file via sequentially saving the .osm and then the .skp tends to yield errors). Then, there in the new, unlinked .skp file I exploded the group so that I'm always working top-level and used the "create space diagram" tool to extrude the diagram to the desired height of the energy model. I then used the same procedure for the second floor, stacked right on top of the first floor.
With minimal success using the surface-matching tool in the plugin, I then tried running the surface-matching measure (with intersection) through the OS app, which proved slightly more successful ... using the measure, the first floor had all correct boundary surfaces, but the second floor was not as obedient ... C:\fakepath\Screen Shot 2017-07-20 at 11.27.56 PM.png ... the "facets" still show up and some surfaces are not drawn, giving errors like:
"Error: Surface 923 Cannot compute outward normal. This error cannot be automatically fixed. The surface will not be drawn." (This is clearly an intersecting issue, but I don't think it's possible to get around the intersecting part of the workflow; as I see it, intersecting the model is essential in order to tell OS that I have a 2-storey building with different floor plates.)
When I manually fix the problem surfaces, either by matching using the Inspector, or deleting in a text editor and then redrawing in the plugin, the same surfaces show up again with wrong boundaries and give the same errors. In further trying to troubleshoot and digging a bit deeper, I have noticed that some spaces on the second floor have 2 surfaces in the same location: one surface is a floor with surface boundary, the other is a roof/ceiling with outside boundary. However, I had assumed that when the intersection/surface-match measure is run, that the ceiling surface of the first level would be intersected with the floor surfaces of the second level, resulting in a single surface that has an (indoor) surface boundary. Is this correct?
Running the simulation of the model as is failed:
Initializing workflow. Processing OpenStudio Measures. Translating the OpenStudio Model to EnergyPlus. Processing EnergyPlus Measures. Starting Simulation. EnergyPlus Starting EnergyPlus, Version 8.7.0-78a111df4a, YMD=2017.07.20 23:56 Processing Data Dictionary Processing Input File Initializing Simulation Reporting Surfaces Beginning Primary Simulation Computing Life Cycle Costs and Reporting Writing final SQL reports **FATAL:Error condition occurred. Previous Severe Errors cause termination. EnergyPlus Run Time=00hr 00min 0.64sec Failed.
... Would you have any more suggestions? I would greatly appreciate it! Thanks so much!
| | 2 | No.2 Revision |
I wanted to post my own solution to the issues I have encountered in trying to intersect and surface-match my building. The two main problems I encountered are indeed solvable: 1. extra diagonal lines that show up after intersecting; and 2. not all surfaces are assigned correctly.
Starting with 1. : If diagonal lines showed up in my model after using the intersecting/surface-matching measure, I went back and drew my space diagram more carefully and slowly, using sketchup inferencing, snapping, and axis-locking. In the sketchup file, I selected decimal units with a 6-digit accuracy. And I slowed waaaaay down when drawing. I also got the query tool from the sketchup extension warehouse, to help me check all vertices and midpoints for correct z's and to help check for segments of lines (these must be removed, or they create extra, unneeded surfaces and more problems). I also avoided using the protractor for drawing diagonal lines (using it would yield a z of -0.000000 on vertices of lines drawn using it and then extra intersecting diagonal lines would appear after surface matching). I also deleted all guides each time before I applied the surface matching measure. In terms of the room shapes (two floors with completely different space layouts), I avoided "jogs" in geometry as much as possible and tried to simplify the plan to be as orthogonal as possible. After many tries, these tips proved successful and I achieved a model without any extra diagonal lines from using the intersect/surface match measure. 2. If certain interior surfaces were showing as outside-bounded or if second floor surfaces were showing as ground-bounded after having used the Surface Match measure with Intersection option through the OpenStudio application, then I used the Inspector tool in the plugin to manually change the Outside Boundary Condition Object (OBCO) for those problem surfaces. Although I learned about this method in a previous post, it was not clear as to how the surfaces were connected... and so if I needed a second floor surface to change from "ground"- to "surface" -bound, I would find an adjacent "surface"-bound floor to match my faulty surface to. But you will notice that, through the surface match measure, all surfaces already have a matched surface (OBCO) that they are bound to (at least those surfaces on a floor higher than the ground floor), and so in selecting some other adjacent surface with the correct surface boundary, it wreaks havoc on other surfaces in the building ... unless you don't mind playing some "wack-a-mole", you will be solving one problem, only for another to appear somewhere else. However, in using the Filter tool in the plugin, it became apparent how the surfaces are connected! Each "Floor" surface type on the second floor has a corresponding "Roof/Ceiling" surface type, and vice-versa. Use the section cut tool in sketchup and select the problem floor surface... then opening the Inspector tool in the plugin, find the number associated with a given Floor; then reverse the section and select its corresponding Roof/Ceiling... when you type the number of the Floor into the OBCO of the Roof/Ceiling surface, they are automatically connected!! The second floor will instantly turn "green" the way it should be for both floor and roof/ceiling of an interior surface! I hope this helps others and saves them a load of time!!
Thank you @rsunnam. I appreciate your suggestions and have spent considerable time redrawing my two floor plans, taking great care to snap to end points and ensure lines are drawn in the same plane. After having done this, I then surface-matched each floor plan in a separate .osm (in the plugin), and when viewing in render by boundary mode the interior walls were all green and all surfaces were as they should be. However, when the two different floor plans are extruded in the same .osm file and then surface-matched in the plugin, although all interior walls are green and all exterior walls and roof blue, still the entire ceiling of the first floor is outside bound and the entire floor of second floor shows as ground in the Inspector. And there are still those pesky "facets" that show up when I intersect the model.
Thus, I tend to think that the problem lies with the fact that the two floor plans are not identical. The intersection and surface-matching tools present no problems when I copy/paste to stack identical floors. But surely OS has the capability to accommodate different floor plans at different levels as would be the case in such a retrofit project ... OS is so powerful and useful, so I'm convinced the problem must be on my end!
Maybe my workflow is flawed? I drew the first floor with sketchup tools in a separate .skp file, I then copy/pasted the floor plan as a group into a new .skp file (which is not linked to the .osm I am drawing in, since I have found that linking an .osm to a .skp file via sequentially saving the .osm and then the .skp tends to yield errors). Then, there in the new, unlinked .skp file I exploded the group so that I'm always working top-level and used the "create space diagram" tool to extrude the diagram to the desired height of the energy model. I then used the same procedure for the second floor, stacked right on top of the first floor.
With minimal success using the surface-matching tool in the plugin, I then tried running the surface-matching measure (with intersection) through the OS app, which proved slightly more successful ... using the measure, the first floor had all correct boundary surfaces, but the second floor was not as obedient ... C:\fakepath\Screen Shot 2017-07-20 at 11.27.56 PM.png ... the "facets" still show up and some surfaces are not drawn, giving errors like:
"Error: Surface 923 Cannot compute outward normal. This error cannot be automatically fixed. The surface will not be drawn." (This is clearly an intersecting issue, but I don't think it's possible to get around the intersecting part of the workflow; as I see it, intersecting the model is essential in order to tell OS that I have a 2-storey building with different floor plates.)
When I manually fix the problem surfaces, either by matching using the Inspector, or deleting in a text editor and then redrawing in the plugin, the same surfaces show up again with wrong boundaries and give the same errors. In further trying to troubleshoot and digging a bit deeper, I have noticed that some spaces on the second floor have 2 surfaces in the same location: one surface is a floor with surface boundary, the other is a roof/ceiling with outside boundary. However, I had assumed that when the intersection/surface-match measure is run, that the ceiling surface of the first level would be intersected with the floor surfaces of the second level, resulting in a single surface that has an (indoor) surface boundary. Is this correct?
Running the simulation of the model as is failed:
Initializing workflow. Processing OpenStudio Measures. Translating the OpenStudio Model to EnergyPlus. Processing EnergyPlus Measures. Starting Simulation. EnergyPlus Starting EnergyPlus, Version 8.7.0-78a111df4a, YMD=2017.07.20 23:56 Processing Data Dictionary Processing Input File Initializing Simulation Reporting Surfaces Beginning Primary Simulation Computing Life Cycle Costs and Reporting Writing final SQL reports **FATAL:Error condition occurred. Previous Severe Errors cause termination. EnergyPlus Run Time=00hr 00min 0.64sec Failed.
... Would you have any more suggestions? I would greatly appreciate it! Thanks so much!
| | 3 | No.3 Revision |
I wanted to post my own solution to the issues I have encountered in trying to intersect and surface-match my building. The two main problems I encountered are indeed solvable: 1. extra diagonal lines that show up after intersecting; and 2. not all surfaces are assigned correctly.
Starting with 1. : If diagonal lines showed up in my model after using the intersecting/surface-matching measure, I went back and drew my space diagram more carefully and slowly, using sketchup inferencing, snapping, and axis-locking. In the sketchup file, I selected decimal units with a 6-digit accuracy. And I slowed waaaaay down when drawing. I also got the query tool from the sketchup extension warehouse, to help me check all vertices and midpoints for correct z's and to help check for segments of lines (these must be removed, or they create extra, unneeded surfaces and more problems). I also avoided using the protractor for drawing diagonal lines (using it would yield a z of -0.000000 on vertices of lines drawn using it and then extra intersecting diagonal lines would appear after surface matching). I also deleted all guides each time before I applied the surface matching measure. In terms of the room shapes (two floors with completely different space layouts), I avoided "jogs" in geometry as much as possible and tried to simplify the plan to be as orthogonal as possible. After many tries, these tips proved successful and I achieved a model without any extra diagonal lines from using the intersect/surface match measure.
2. measure.
Thank you @rsunnam. I appreciate your suggestions and have spent considerable time redrawing my two floor plans, taking great care to snap to end points and ensure lines are drawn in the same plane. After having done this, I then surface-matched each floor plan in a separate .osm (in the plugin), and when viewing in render by boundary mode the interior walls were all green and all surfaces were as they should be. However, when the two different floor plans are extruded in the same .osm file and then surface-matched in the plugin, although all interior walls are green and all exterior walls and roof blue, still the entire ceiling of the first floor is outside bound and the entire floor of second floor shows as ground in the Inspector. And there are still those pesky "facets" that show up when I intersect the model.
Thus, I tend to think that the problem lies with the fact that the two floor plans are not identical. The intersection and surface-matching tools present no problems when I copy/paste to stack identical floors. But surely OS has the capability to accommodate different floor plans at different levels as would be the case in such a retrofit project ... OS is so powerful and useful, so I'm convinced the problem must be on my end!
Maybe my workflow is flawed? I drew the first floor with sketchup tools in a separate .skp file, I then copy/pasted the floor plan as a group into a new .skp file (which is not linked to the .osm I am drawing in, since I have found that linking an .osm to a .skp file via sequentially saving the .osm and then the .skp tends to yield errors). Then, there in the new, unlinked .skp file I exploded the group so that I'm always working top-level and used the "create space diagram" tool to extrude the diagram to the desired height of the energy model. I then used the same procedure for the second floor, stacked right on top of the first floor.
With minimal success using the surface-matching tool in the plugin, I then tried running the surface-matching measure (with intersection) through the OS app, which proved slightly more successful ... using the measure, the first floor had all correct boundary surfaces, but the second floor was not as obedient ... C:\fakepath\Screen Shot 2017-07-20 at 11.27.56 PM.png ... the "facets" still show up and some surfaces are not drawn, giving errors like:
"Error: Surface 923 Cannot compute outward normal. This error cannot be automatically fixed. The surface will not be drawn." (This is clearly an intersecting issue, but I don't think it's possible to get around the intersecting part of the workflow; as I see it, intersecting the model is essential in order to tell OS that I have a 2-storey building with different floor plates.)
When I manually fix the problem surfaces, either by matching using the Inspector, or deleting in a text editor and then redrawing in the plugin, the same surfaces show up again with wrong boundaries and give the same errors. In further trying to troubleshoot and digging a bit deeper, I have noticed that some spaces on the second floor have 2 surfaces in the same location: one surface is a floor with surface boundary, the other is a roof/ceiling with outside boundary. However, I had assumed that when the intersection/surface-match measure is run, that the ceiling surface of the first level would be intersected with the floor surfaces of the second level, resulting in a single surface that has an (indoor) surface boundary. Is this correct?
Running the simulation of the model as is failed:
Initializing workflow. Processing OpenStudio Measures. Translating the OpenStudio Model to EnergyPlus. Processing EnergyPlus Measures. Starting Simulation. EnergyPlus Starting EnergyPlus, Version 8.7.0-78a111df4a, YMD=2017.07.20 23:56 Processing Data Dictionary Processing Input File Initializing Simulation Reporting Surfaces Beginning Primary Simulation Computing Life Cycle Costs and Reporting Writing final SQL reports **FATAL:Error condition occurred. Previous Severe Errors cause termination. EnergyPlus Run Time=00hr 00min 0.64sec Failed.
... Would you have any more suggestions? I would greatly appreciate it! Thanks so much!
| | 4 | No.4 Revision |
I wanted to post my own solution to the issues I have encountered in trying to intersect and surface-match my building. The two main problems I encountered are indeed solvable: 1. extra diagonal lines that show up after intersecting; and 2. not all surfaces are assigned correctly.
Starting with 1. : If diagonal lines showed up in my model after using the intersecting/surface-matching measure, I went back and drew my space diagram more carefully and slowly, using sketchup inferencing, snapping, and axis-locking. In the sketchup file, I selected decimal units with a 6-digit accuracy. And I slowed waaaaay down when drawing. I also got the query tool from the sketchup extension warehouse, to help me check all vertices and midpoints for correct z's and to help check for segments of lines (these must be removed, or they create extra, unneeded surfaces and more problems). I also avoided using the protractor for drawing diagonal lines (using it would yield a z of -0.000000 on vertices of lines drawn using it and then extra intersecting diagonal lines would appear after surface matching). I also deleted all guides each time before I applied the surface matching measure. In terms of the room shapes (two floors with completely different space layouts), I avoided "jogs" in geometry as much as possible and tried to simplify the plan to be as orthogonal as possible. After many tries, these tips proved successful and I achieved a model without any extra diagonal lines from using the intersect/surface match measure.
2:
If certain interior surfaces were showing as outside-bounded or if second floor surfaces were showing as ground-bounded after having used the Surface Match measure with Intersection option through the OpenStudio application, then I used the Inspector tool in the plugin to manually change the Outside Boundary Condition Object (OBCO) for those problem surfaces. Although I learned about this method in a previous post, it was not clear as to how the surfaces were connected... and so if I needed a second floor surface to change from "ground"- to "surface" -bound, I would find an adjacent "surface"-bound floor to match my faulty surface to. But you will notice that, through the surface match measure, all surfaces already have a matched surface (OBCO) that they are bound to (at least those surfaces on a floor higher than the ground floor), and so in selecting some other adjacent surface with the correct surface boundary, it wreaks havoc on other surfaces in the building ... unless you don't mind playing some "wack-a-mole", you will be solving one problem, only for another to appear somewhere else. However, in using the Filter tool in the plugin, it became apparent how the surfaces are connected! Each "Floor" surface type on the second floor has a corresponding "Roof/Ceiling" surface type, and vice-versa. Use the section cut tool in sketchup and select the problem floor surface... then opening the Inspector tool in the plugin, find the number associated with a given Floor; then reverse the section and select its corresponding Roof/Ceiling... when you type the number of the Floor into the OBCO of the Roof/Ceiling surface, they are automatically connected!! The second floor will instantly turn "green" the way it should be for both floor and roof/ceiling of an interior surface! I hope this helps others and saves them a load of time!!Thank you @rsunnam. I appreciate your suggestions and have spent considerable time redrawing my two floor plans, taking great care to snap to end points and ensure lines are drawn in the same plane. After having done this, I then surface-matched each floor plan in a separate .osm (in the plugin), and when viewing in render by boundary mode the interior walls were all green and all surfaces were as they should be. However, when the two different floor plans are extruded in the same .osm file and then surface-matched in the plugin, although all interior walls are green and all exterior walls and roof blue, still the entire ceiling of the first floor is outside bound and the entire floor of second floor shows as ground in the Inspector. And there are still those pesky "facets" that show up when I intersect the model.
Thus, I tend to think that the problem lies with the fact that the two floor plans are not identical. The intersection and surface-matching tools present no problems when I copy/paste to stack identical floors. But surely OS has the capability to accommodate different floor plans at different levels as would be the case in such a retrofit project ... OS is so powerful and useful, so I'm convinced the problem must be on my end!
Maybe my workflow is flawed? I drew the first floor with sketchup tools in a separate .skp file, I then copy/pasted the floor plan as a group into a new .skp file (which is not linked to the .osm I am drawing in, since I have found that linking an .osm to a .skp file via sequentially saving the .osm and then the .skp tends to yield errors). Then, there in the new, unlinked .skp file I exploded the group so that I'm always working top-level and used the "create space diagram" tool to extrude the diagram to the desired height of the energy model. I then used the same procedure for the second floor, stacked right on top of the first floor.
With minimal success using the surface-matching tool in the plugin, I then tried running the surface-matching measure (with intersection) through the OS app, which proved slightly more successful ... using the measure, the first floor had all correct boundary surfaces, but the second floor was not as obedient ... C:\fakepath\Screen Shot 2017-07-20 at 11.27.56 PM.png ... the "facets" still show up and some surfaces are not drawn, giving errors like:
"Error: Surface 923 Cannot compute outward normal. This error cannot be automatically fixed. The surface will not be drawn." (This is clearly an intersecting issue, but I don't think it's possible to get around the intersecting part of the workflow; as I see it, intersecting the model is essential in order to tell OS that I have a 2-storey building with different floor plates.)
When I manually fix the problem surfaces, either by matching using the Inspector, or deleting in a text editor and then redrawing in the plugin, the same surfaces show up again with wrong boundaries and give the same errors. In further trying to troubleshoot and digging a bit deeper, I have noticed that some spaces on the second floor have 2 surfaces in the same location: one surface is a floor with surface boundary, the other is a roof/ceiling with outside boundary. However, I had assumed that when the intersection/surface-match measure is run, that the ceiling surface of the first level would be intersected with the floor surfaces of the second level, resulting in a single surface that has an (indoor) surface boundary. Is this correct?
Running the simulation of the model as is failed:
Initializing workflow. Processing OpenStudio Measures. Translating the OpenStudio Model to EnergyPlus. Processing EnergyPlus Measures. Starting Simulation. EnergyPlus Starting EnergyPlus, Version 8.7.0-78a111df4a, YMD=2017.07.20 23:56 Processing Data Dictionary Processing Input File Initializing Simulation Reporting Surfaces Beginning Primary Simulation Computing Life Cycle Costs and Reporting Writing final SQL reports **FATAL:Error condition occurred. Previous Severe Errors cause termination. EnergyPlus Run Time=00hr 00min 0.64sec Failed.
... Would you have any more suggestions? I would greatly appreciate it! Thanks so much!
