Forward Translator - Surface translation review

[GoogleCodeExporter]

Describe the translation issue or enhancement:

In preparation for another set of models we need to develop for testing the 
CBECC ruleset, we spent some time reviewing the geometry of a few of the CBECC 
models that we have been testing to date.  We found a few forward translation 
issues that I wanted to get in the pipeline, priority TBD based on amount of 
time it would take to address.

If issue occurs during translation, describe what steps reproduce the
problem.

1) Surfaces with Outside Boundary Condition = Adiabatic do not appear to be 
translated forward to SDD XML.  This presents an issue with models that have 
intermediate shells w/ multipliers, such as the Large Office prototype.  Unless 
others specify a preference, recommend these surfaces be translated as an 
Int*** surface w/o an AdjacentSpcRef specified.

2) Only surfaces with Outside Boundary Condition = Ground appear to be 
translated forward to SDD XML.  Recommend revising the forward translation to 
SDD UndgrWall/Flr objects for any of OSM surfaces with  Outside Boundary 
Condition = Ground**** 

What version of OpenStudio are you using? On what operating system?
r11994.  Will attached test OSM tomorrow.

Please provide any additional information below.

Original issue reported on code.google.com by da...@360-analytics.com on 21 May 2013 at 5:51

[GoogleCodeExporter]

Attached test model.  This include two cases for each BuildingStory:

1) 4 floors, 3 above grade with plenums, 1 below grade. All floors are stacked 
on top of eachother with thermal connections between plenum and space above.

2) Same as #1, but floors are separated and surfaces between floors are 
adiabatic surfaces

Original comment by da...@360-analytics.com on 22 May 2013 at 11:27

Attachments:

• single_ZN_test.osm

[GoogleCodeExporter]

Also, recently noted that Reverse translation of SDD UndgrWall/UndgrFlr objects 
is to 
!- Outside Boundary Condition = Ground, 
instead of
!- Outside Boundary Condition = GroundFCfactorMethod 
Not sure this impacts E+ simulation, but thought that it should be consistent 
with the underground surface construction definitions we are using in the SDD.

The models I attached to this issue include a a few different underground 
"Outside Boundary Condition" specifications to test forward translation of 
these different methods to SDD.

Original comment by da...@360-analytics.com on 23 May 2013 at 6:45

[GoogleCodeExporter]

This has been fixed on the sdd branch

Original comment by dan.macu...@gmail.com on 30 May 2013 at 4:15

• Changed state: Fixed

[GoogleCodeExporter]

I did some basic review and testing of the forward translator with a slightly 
different model (attached).  Adiabatic surfaces are now being translated.  

However, noted a different issue:  ConsAssm names for IntFlr and Ceiling 
(whether they are adiabatic or not) are not being translated forward. I just 
tested another model that has IntWall objects, and those are not being 
translated forward. 

Both models are attached.  Forward translation of interior wall constructions 
is nto a priority for our demo, but is an item that would improve the workflow.

Original comment by da...@360-analytics.com on 31 May 2013 at 11:33

• Changed state: Discussion

Attachments:

• SDD_SpacePolyLoop_Test_01.osm
• SDD_MultiStory_Test_01.osm

[GoogleCodeExporter]

Reviewed comments above an though the outstanding issues of this ticket should 
be more concisely summarized: 

Update forward translator to include assignment of ConsAssmRef properties for 
interior surfaces (IntWall, IntFlr, Ceiling)

Original comment by da...@360-analytics.com on 7 Jun 2013 at 11:08

[GoogleCodeExporter]

Hey David, I am confused about this thread, is there a specific issue or issues 
that I should look into?

Original comment by dan.macu...@gmail.com on 25 Jun 2013 at 8:50

[GoogleCodeExporter]

Hey Dan-
Comment #5 was intended to clarify the only outstanding issue for this ticket. 
Give me a buzz if this does not make sense (I am free until 6pm).  At this 
point, given the convention we decided on that all Spaces are written with 
IntFlrs rather than IntFlr/Ceiling, I don't think the Ceiling object is ever 
written but he OS forward translator.

Original comment by da...@360-analytics.com on 25 Jun 2013 at 9:05

[GoogleCodeExporter]

Dan, 
We are testing the latest OS package and seeing some strange behavior with the 
forward translation of OSM models that were created by importing IDFs.  In 
summary, the forward translation of the same OSM model (that originates from 
the MediumOffice IDF), two different times, will result in two different SDD 
XML files.  

We've found the files are different in the following ways:

- The ordering of objects is different
- The assignment of IntFlr objects to the various spaces varies.  In some cases 
the IntFlr is a child of a non-plenum space, and in some cases, it is the child 
of plenum space.
- In all cases, there are not enough IntFlr objects for the the given number of 
spaces.  In this model (3 stories, ground floor is slab on grade, all floors 
have plenums), there should be 25 IntFlr objects in the CBECC file.  I am only 
counting 10.  
- In some cases the AdjacentSpcRef property is incorrect.  In the *_2.xml 
model, the IntFlr objects are located in the FirstFloor_Plenum, but the 
AdjacentSpcRef is specified to be the space above (Perimeter_mid_ZN_3)

We did some similar testing of a SDD_MultiStory_Test_01.osm file, which was 
created in OS rather than from an IDF export.  We found that the SDD XML object 
ordering still is not consistent between exports, however, there is repeatably 
the correct number of IntFlr objects.  Therefore, this issue have something to 
do with the fact that the OSM geometry is from IDF import, but our testing does 
not confirm that.   

This testing was done using the latest package with the Space:PolyLp export 
included (1.0.3.1d51e90)

Original comment by da...@360-analytics.com on 1 Aug 2013 at 1:50

• Added labels: Priority-High
• Removed labels: Priority-Medium

Attachments:

• CZ15OfficeMediumBase_V800.zip

[GoogleCodeExporter]

Do you mean that you have one osm and export it twice to get two different sdd? 
 Not import idf twice to get two osm and export each once?  If I am 
understanding correctly then this is the same issue that we had with IDF files. 
 We solved it by sorting objects in the energyplus forward translator before 
translating them, we could apply the same strategy here.

Does order of the sdd matter for rules or is this for diffing files?

Original comment by dan.macu...@gmail.com on 1 Aug 2013 at 1:57

[GoogleCodeExporter]

Part of the issue here is the first scenario you described:  one osm and export 
it twice to get two different sdd.

Order of the objects doesn't matter to my knowledge as long as the parent/child 
relationships are preserved (Scott, please chime in if I am wrong).  The 
ordering is more about diffing files.  It would have taken a lot less time to 
debug this issue if objects were repeatably in the same order, so believe it is 
important to address this for long term support of the product.

The other part fo the issue is the IntFlr translation; do you think this is an 
artifact of IDF import, or did we just miss this in testing with the OS model 
because it was a simple, one zone/flr example we originally tested this on?

Original comment by da...@360-analytics.com on 1 Aug 2013 at 2:13

[GoogleCodeExporter]

Does the IntFlr translation error occur intermittently on separate translations 
of the same OSM or does it always occur on the translation of the same OSM?  Do 
you think the IntFlr issue is related to the random order of SDD objects or not?

Original comment by dan.macu...@gmail.com on 1 Aug 2013 at 2:22

[GoogleCodeExporter]

It seems to always occur on the translation of the same OSM.  I don't think the 
issue is related to the random ordering of the SDD objects, since the IntFlrs 
seem to come through fine from model we created natively in OS 
(SDD_MultiStory_Test_01.osm included in comment #4 above).  However a test to 
confirm this would be to create a more or less equivalent 5 zone, 3 floor 
building in OS and export that a few times. We have not done that yet, but I 
think Sandeep can mock something up quickly tomorrow if that would help.

Original comment by da...@360-analytics.com on 1 Aug 2013 at 2:36

[GoogleCodeExporter]

Dan - 

Do you need our help further debugging this issue?  I have been hesitant to put 
Sandeep on this issue (as described above) until I can be more confident that 
our approach will provide you with targeted and productive debugging assistance.

Original comment by lu...@360-analytics.com on 1 Aug 2013 at 11:38

[GoogleCodeExporter]

Hi Lukas, if we could make a new issue for the IntFlr problem and attach some 
problem files that would help me a lot.  I think a new ticket for the random 
order issue would be appropriate too.  It seems that the original issues in 
this ticket have been resolved right? 

Dan

Original comment by dan.macu...@gmail.com on 1 Aug 2013 at 11:41

[GoogleCodeExporter]

IntFlr issue described in comment #8 has been moved to new issue #259
Object ordering issue described in comment #8 has been moved to new issue #260

Changing status to fixed to close out original items in ticket

Original comment by da...@360-analytics.com on 2 Aug 2013 at 12:00

• Changed state: Fixed

[GoogleCodeExporter]

closing issue

Original comment by da...@360-analytics.com on 8 Aug 2013 at 5:58

• Changed state: DoneVerified