ladybug-tools / honeybee-radiance / 169
81%
master: 81%

LAST BUILD BRANCH: aperture-up-vector
DEFAULT BRANCH: master
Ran
Jobs 2
Files 103
Run time 19s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
169

push

travis-ci

chriswmackey 
feat(model): Add method for Model.to.rad_folder

This commit adds a method to the radiance writer to serialize a honeybee model into a radiance folder structure. At the moment, there are no states in honeybee-radiance and so this method only serializes objects into the static and bsdf folders.

There are a number of things to note about this implementation:
* All aperture-assigned static shades are written into either the opaque or nonopaque folder (not the aperture folder) since these are the only folders that allow us to distinguish between indoor and outdoor shades (the static aperture folder does not support this distinction).
* We currently do not enforce that apertures need to have a nonopaque modifier. So opaque apertures and doors are still written into the aperture folder.
* For every object where there is an overridden modifier_blk, two completely new modifiers are generated for every unique combination of modifer and modifier_blk. This greatly increases the complexity of the code since this type of check has to be run for every single sub-directory in the radiance folder structure.  But it's the only way to support the flexibility pf overriding the modifier_blk while also getting the matching names between modifer and modifer_blk that the radiance folder structure expects.
* In the event that no objects of a certain type are in the model (like no nonopaque building faces), I currently don't write any files at all rather than writing empty files. This is likely to be a very common occurrence since the folder structure has many directories that will rarely get use.
* I have included checks to be sure that, for every Face, Aperture, and Door with a Surface boundary condition, only one of the pair of the matching objects is written. There's no logic to which of the two objects is picked beyond whichever shows up first in the list (so the direction that this interior object should be considered random ).

I still have to add some tests for the n... (continued)

3385 of 4161 relevant lines covered (81.35%)

1.63 hits per line

Jobs
ID Job ID Ran Files Coverage
2 169.2 103
81.35
 Travis Job 169.2
3 169.3 103
81.33
 Travis Job 169.3
Source Files on build 169