search

kbenne / cbecc

Automatically exported from code.google.com/p/cbecc
0 stars 0 forks source link

Reverse Translation (SDD -> OS) of Daylighting Control Objects #361

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Translation of daylighting control objects from SDD to  E+ has been outlined on 
the the Google Doc 'SDD to E+ Translation' located here:

https://drive.google.com/a/360-analytics.com/?tab=wo#folders/0B63Ndkzvj2l6Rm10bW
tHZ0RDOW8

I am not familiar with the OS data model on this issue, so I have not attempted 
to outline that section of the translation process.

Attached is a .xml file containing a sample daylighting control specification 
at the thermal zone level.

Modifications to the CBECC data model and rules corresponding to inclusion of 
the thermal zone level daylighting control properties have been commited to SVN 
revision 1186

Original issue reported on code.google.com by lu...@360-analytics.com on 27 Nov 2013 at 1:05

Attachments:

GoogleCodeExporter commented 9 years ago 
This should be pretty easy to translate.  The only issue will be which space to 
assign each control to in the thermal zone (this is mostly so it can be 
rendered in SketchUp, all the other properties are zone level in OS).  My 
suggestion is that I assign each control point to the first space in the 
thermal zone where the space bounding box includes the point, sound good?

Original comment by dan.macu...@gmail.com on 27 Nov 2013 at 4:40

GoogleCodeExporter commented 9 years ago 
I think I have the SDD->OSM translation working:  Couple of quick questions:

1) Are daylighting coordinates in building coordinate system?

2) If I were able to do OSM->SDD translation of daylighting controls would you 
want that?  Scott, does your GUI explicitly NOT want points from OSM making it 
into SDD?

Original comment by dan.macu...@gmail.com on 27 Nov 2013 at 6:33

GoogleCodeExporter commented 9 years ago 
The example xml has <DayltgMaxGlrIdx>0</DayltgMaxGlrIdx>, the minimum value 
allowed by the EnergyPlus IDD is 1 (default is 22)

Original comment by dan.macu...@gmail.com on 27 Nov 2013 at 6:41

GoogleCodeExporter commented 9 years ago 
In response to comment #1.  Each control point should be geometrically located 
within a  space. (Scott, I think we should avoid situations where a point is 
located ON the boundary of a space).  Dan your approach should work.  An 
alternative is for us to add a SDD term i.e. ThrmlZn:RefPtCoord1OriginalSpace, 
or something like that.  Based on our rule logic, the reference points 
originate at the space level, and we select from among the available reference 
points - so we could also track which space the point originated in.

In response to comment #2 - currently the user is not allowed to specify 
reference points.  Their location is specified by the ACM and calculated by the 
ruleset.  For compliance purposes, I don't not really see a situation where we 
would want to import existing reference points from OS.  However - as the tool 
evolves for other purposes this may not hold true.  Scott - you may have a 
better understanding of where the tool is going and a stronger opinion of 
forward translation of daylighting reference points.

In response to #3, I meant to address the GlareIdx issue and must have forgot.  
If the values for GlareIdx and GlareAz are not specified, I think we should 
leave them out (Undefined? Does OS have a parallel to UNDEFINED?).  If the 
value specified is out of range for E+, go ahead and default it as you normally 
would (i.e. 22 in this case?)

Original comment by lu...@360-analytics.com on 27 Nov 2013 at 6:49

GoogleCodeExporter commented 9 years ago 
The bounding box approach seems to be working so far, if you want to add the 
space ID i can use that instead

Yes OpenStudio does have the idea of undefined and using default values. I am 
currently treating these fields as optional (using defaults if they are empty):
DayltgMinDimLtgFrac
DayltgMinDimPwrFrac
DayltgGlrAz
DayltgMaxGlrIdx

Original comment by dan.macu...@gmail.com on 27 Nov 2013 at 6:53

GoogleCodeExporter commented 9 years ago 
A couple of misc responses -

Daylighting control positions are in building coordinates.  Currently, that is 
the only coordinate system the compliance manager/ruleset tracks.  Let me know 
if we need to make an adjustment here to accommodate reverse translation.

Re: forward translation of daylighting reference points - I think probably not, 
at least for the time being.  Within CBECC (and tools importing CIBD files), 
daylighting inputs would be specified at the Space level and those would get 
simplified to Zone level positions and settings by the ruleset (or perhaps with 
user intervention when in research mode).
If forward translation of OpenStudio daylighting inputs could be done in a 
fairly straight-forward way into the SDD Space level inputs, then that would 
argue for forward translation sooner rather than later.

Original comment by scriswel...@gmail.com on 27 Nov 2013 at 9:07

GoogleCodeExporter commented 9 years ago 
Hey Scott, I don't quite understand what you mean by forward translation from 
osm to sdd space level inputs.  Are there space level elements for daylighting 
controls defined in the SDD?  The only SDD daylighting control elements I am 
aware of are under thermal zone.  If there are space level fields do I need to 
consider those during SDD->OSM conversion?  OpenStudio associates daylighting 
controls with a space and also with a thermal zone so I can do space level 
mapping.  

On another note, I have not been able to pull an update on the google code 
cbecc repo, is anyone else having difficulties with that?

Dan

Original comment by dan.macu...@gmail.com on 27 Nov 2013 at 9:12

GoogleCodeExporter commented 9 years ago 
Re: Forward translation to Space level inputs - yes there are Space level 
inputs, but those are NOT to be referenced when performing the OpenStudio 
REVERSE translation.  The reverse translation should look only at the Zone 
level inputs.
Lets just leave it at that for now - once we get the daylighting control 
simulation functioning we can consider what, if anything, to do re: forward 
translation of Space inputs.

Re: CBECC repo issues - no problems that I am aware of.  I have both updated 
and committed mods today without incident.

Original comment by scriswel...@gmail.com on 27 Nov 2013 at 10:12

GoogleCodeExporter commented 9 years ago 
Sounds good to me.  Here is an installer, this has been merged to trunk:

https://pfs.nrel.gov/main.html?download&weblink=e61bd9b8f1795f92ea912cb332ad2ea5
&realfilename=OpenStudio-1.1.3.57c072b45f-Windows.exe

Original comment by dan.macu...@gmail.com on 30 Nov 2013 at 2:04

GoogleCodeExporter commented 9 years ago 
After reviewing the Reverse Translation of Daylighting Control properties from 
SDD to OS, I have found that all but one property is being translated 
correctly.  Summary Below:

  -Correct translation of daylt ctrl location (DayltgIllumRefPt1Coord, DayltgIllumRefPt2Coord)

  -Correct translation of daylt ctrl zone assignment

  -Correct translation of daylt ctrl lighting fractions (DayltgCtrlLtgFrac1, DayltgCtrlLtgFrac2)

-Correct translation of daylt ctrl illuminance set point (DayltgIllumSetPt1, 
DayltgIllumSetPt2)

  -Incorrect translation of daylt ctrl type (DayltgCtrlType) - this is my fault, it had been scrubbed from the sample .xml I sent

  - Correct translation of daylt ctrl lighting and power minimum fractions for continuous dimming (DayltgMinDimLtgFrac, DayltgMinDimPwrFrac)

  - Unable to confirm translation of daylt ctrl number of control steps for stepped control (DayltgNumCtrlSteps)

I have attached a sample .xml file that includes examples of all of the sample 
control types.

Also the properties for translation, as well as the E+ target properties are 
outlined in the Daylighting tab of the 'SDD to E+ translation' Google 
Spreadsheet that David and Kyle have been using.

Original comment by lu...@360-analytics.com on 6 Dec 2013 at 11:30

Attachments:

GoogleCodeExporter commented 9 years ago 
I don't see any daylighting elements in this file?

"5 Zone Daylt v3.xml"

Original comment by dan.macu...@gmail.com on 10 Dec 2013 at 9:48

GoogleCodeExporter commented 9 years ago 
There are a few in '5 Zone Daylt v3 - p.xml', ill use those

Original comment by dan.macu...@gmail.com on 10 Dec 2013 at 9:55

GoogleCodeExporter commented 9 years ago 
yeah, I think I attached the wrong file... again.  Sorry for the confusion.  
Just to make sure, here's the one I had intended to attach.

Original comment by lu...@360-analytics.com on 10 Dec 2013 at 10:24

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by dan.macu...@gmail.com on 10 Dec 2013 at 11:02

GoogleCodeExporter commented 9 years ago

Original comment by dan.macu...@gmail.com on 10 Dec 2013 at 11:09

GoogleCodeExporter commented 9 years ago 
After Updates, translation is correct.  Updating status to DoneVerified

  -Correct translation of daylt ctrl location (DayltgIllumRefPt1Coord, DayltgIllumRefPt2Coord)

  -Correct translation of daylt ctrl zone assignment

  -Correct translation of daylt ctrl lighting fractions (DayltgCtrlLtgFrac1, DayltgCtrlLtgFrac2)

  -Correct translation of daylt ctrl illuminance set point (DayltgIllumSetPt1, DayltgIllumSetPt2)

  - Correct translation of daylt ctrl type (DayltgCtrlType)

  - Correct translation of daylt ctrl lighting and power minimum fractions for continuous dimming (DayltgMinDimLtgFrac, DayltgMinDimPwrFrac)

  - Correct translation of daylt ctrl number of control steps for stepped control (DayltgNumCtrlSteps)

Original comment by lu...@360-analytics.com on 13 Dec 2013 at 10:06

GoogleCodeExporter commented 9 years ago 
Copied from http://code.google.com/p/cbecc/issues/detail?id=344:

Reverse Translator (SDD->OS)

In SDD, DayltgIllumSetPt1 and DayltgIllumSetPt1 are specified in units of lux.  
The current SDD->OS translator is applying a conversion factor of ~10 as if the 
SDD objects were specified in fc.  Please remove the conversion factor.

This is done and is on develop

Original comment by dan.macu...@gmail.com on 13 Dec 2013 at 11:47