OpenStudio exports only materials, no geometry in xml

[GoogleCodeExporter]

OSM v1.4 on Win8-64. Choose export -> SDD. Examine XML file in text editor. No 
geometry.

Open XML in CBECC-Com v2b. Materials are imported but no geometry.

I've attached .osm and .xml files. How do I make this work? I'm supposed to be 
turning out a compliance report and I don't have much time.

Original issue reported on code.google.com by f.le...@gmail.com on 29 Jul 2014 at 11:55

[GoogleCodeExporter]

Requested user for OSM and XML model files - were not attached originally.

Original comment by nka...@archenergy.com on 30 Jul 2014 at 5:09

[GoogleCodeExporter]

We have looked at the OSM file. It seems you are missing the Building Story 
Assignment which should automatically be generated but for some reason was 
missing in the model. This object can be found in the OpenStudio Inspector. 
Once you have a Building Story defined you need to associate it with the spaces 
and then save and export to SDD XML and you should see the model. 

Also the materials need to be defined in the CBECC-Com interface. You can use 
the Construction Assembly that came in from Open Studio but you would need to 
assign materials from the CBECC-Com material library as they are very specific 
to Title-24.

Original comment by nka...@archenergy.com on 30 Jul 2014 at 8:33

[GoogleCodeExporter]

From user: 

If a space is created using the "New Space" icon, there is no default Building 
Story Name populated. If the user doesn't create a name/story on her own, the 
SDDxml export will contain no building geometry. (see attached PDF with 
screenshots)

On the other hand, if a space is created using the "Create Spaces From Diagram" 
icon, the resulting space will have "Building Story 1" populated automatically. 
Then when SDDxml file is exported, it will contain geometry. 

The tutorials for using CBECC-com show using the "Create Spaces From Diagram" 
tool. However, as a previous Legacy plug-in user, I have always used the Create 
new Space---then draw inside the space---pathway. Building Story is not needed 
to get a working IDF using Legacy. I wouldn't have thought that the choice of 
modeling path could make or break the SDD export. 

I think the missing default Story Name should be fixed because OSM is now a 
public business tool used for compliance with the CA State Energy Code and lots 
of non-researcher newbies will be using this, who are proficient with other 
modeling tools but never used OSM, EnergyPlus, etc. Currently, people have to 
use either OSM/CBECC-com or IES-VE to get a building permit. It's not grad 
students or software developers doing this work, but average software users 
running small businesses. This is far too much troubleshooting.

Original comment by nka...@archenergy.com on 31 Jul 2014 at 10:22

[GoogleCodeExporter]

Copying Kyle and Dan.

Original comment by nka...@archenergy.com on 31 Jul 2014 at 10:25

[GoogleCodeExporter]

From Dan:

It is becoming clear that this issue is troubling for many users.  Currently, 
the SDD translator issues a warning if there are any spaces that are not 
assigned to building stories on export to SDD.  These warnings are shown when 
exporting an SDD from the OpenStudio application but not from the SketchUp 
plug-in. 

We could show these errors when exporting from the SketchUp plug-in, I think 
that would at least alert users at the right time.  We could back port this 
change to the 1.4.0-LTS branch as well.

Implementing any type of automated story assignment would require a very clear 
algorithm definition and is likely out of scope

Original comment by nka...@archenergy.com on 31 Jul 2014 at 10:27

[GoogleCodeExporter]

Yes that should work. Getting this alert in to the plugin is a good option – 
so that at least users are aware of the problem. If in the message you could 
add something to the effect that…this may result in the building components 
to not show when imported into the compliance software or something to that 
effect

Original comment by nka...@archenergy.com on 31 Jul 2014 at 10:27

[GoogleCodeExporter]

From Dan:

Before I make the commit to show errors and warnings on export, I wanted to 
review the error and warning messages that are issued by the SDD 
ForwardTranslator (OSM->SDD).  The messages issued by the ReverseTranslator 
(SDD->OSM) are another story.  I am not sure which of these issues are easy to 
fix in the CBECC interface vs which ones should be show on export (also which 
should be errors vs warnings), can you review these and see if they are 
appropriate?

• (***This will be common based on our templates***) If a door uses a 
construction that does not consist of a single layer of type 
MasslessOpaqueMaterial you will get the error "Could not calculate UFactor for 
DrCons #{name}”
• (***This will be common based on our templates***) If a window uses a 
construction that does not consist of a single layer of type SimpleGlazing you 
will get the error "Could not calculate SHGC, UFactor, or VT for FenCons 
#{name}”
• (***This is common based on user support***) If any space does not belong 
to a building story you will get the warning “Model contains spaces which are 
not assigned to a building story, these have not been translated.”
• If a surface uses a construction type which is not translated to SDD you 
will get the error “Surface #{name} uses construction #{constructionName} 
which has not been translated”
• If a subsurface uses a construction type which is not translated to SDD you 
will get the error “SubSurface #{name} uses construction #{constructionName} 
which has not been translated”
• If a shading surface uses a schedule type which is not translated to SDD 
you will get the error “ShadingSurface #{name} uses transmittance schedule 
#{transmittanceScheduleName} which has not been translated”
•  (***This will be common based on our templates***) If a ground contact 
floor uses a construction other than FFactorGroundFloorConstruction which is 
unique to that surface, you will get the error “Cannot compute exposed 
perimeter for surface #{name}”
• (***This will be common based on our templates***) If a ground contact wall 
uses a construction other than CFactorUndergroundWallConstruction which is 
unique to that surface, you will get the error “Cannot compute height for 
surface #{name}”

I am also thinking of adding this warning, is this worthwhile to add? 

• If any space does not belong to a thermal zone you will get the warning 
"Model contains spaces which are not assigned to a thermal zone.”

Any other warnings or errors we need to report?

Original comment by nka...@archenergy.com on 31 Jul 2014 at 10:28

[GoogleCodeExporter]

Original comment by nka...@archenergy.com on 31 Jul 2014 at 10:28

[GoogleCodeExporter]

Dan, can you add the following warnings on export to SDD XML?
1) Spaces with floor area of 0 or undefined
2) polyloops with area 0 or undefined
3) subsurfaces not contained within the parent surface
4) Surface with number of sides < 3
5) Spaces with total number of floor, wall, ceiling and roof surfaces < 6'
6) Non-planar surface
7) Space with surface not touching any other surface of the space 
8) Building Story defined but not assigned to any spaces

Original comment by rhedr...@archenergy.com on 1 Aug 2014 at 5:51

• Changed state: Discussion
• Added labels: SubType-OS
• Removed labels: Subtype-CBECC-NRes

[GoogleCodeExporter]

I can get some of these, here is the summary:

1) yes 
2) yes
3) yes
4) this is hard because vertices can be co-linear, I can check if the surface 
area is greater than some minimum
5) I can check for at least one floor, at least two walls, and at least one 
roof/ceiling
6) You can't make non-planar surfaces in the API or the SketchUp interface, I 
will skip this check
7) I can't do this check yet
8) yes

Original comment by dan.macu...@gmail.com on 4 Aug 2014 at 3:13

[GoogleCodeExporter]

For posterity the only existing forward translator warnings we want to keep are:

• (***This is common based on user support***) If any space does not belong 
to a building story you will get the warning “Model contains spaces which are 
not assigned to a building story, these have not been translated.”
• If a shading surface uses a schedule type which is not translated to SDD 
you will get the error “ShadingSurface #{name} uses transmittance schedule 
#{transmittanceScheduleName} which has not been translated”

Original comment by dan.macu...@gmail.com on 4 Aug 2014 at 3:21

[GoogleCodeExporter]

Looks good to me.  I have a question about number 4 - doesn't a surface need to 
have at least 3 sides to be bounded and have a non-zero area?  If check #2 
catches surfaces without 3 or more sides, then I guess we can drop #4.  

Original comment by rhedr...@archenergy.com on 4 Aug 2014 at 3:58

[GoogleCodeExporter]

https://github.com/NREL/OpenStudio/commit/077aab6988fb3160574b41a733bace9351ed11
73

Original comment by dan.macu...@gmail.com on 4 Aug 2014 at 6:53

[GoogleCodeExporter]

Can we change status to resolved or is this still open?

Original comment by dan.macu...@gmail.com on 28 Aug 2014 at 5:57

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by rhedr...@archenergy.com on 3 Sep 2014 at 5:21

• Changed state: DoneVerified