• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

ladybug-tools / honeybee-radiance / 168
81%

Build:
DEFAULT BRANCH: master
Ran 15 Apr 2020 09:11PM UTC
Jobs 3
Files 103
Run time 2min
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

pending completion
168

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 168.2 15 Apr 2020 09:11PM UTC 0
81.35
Travis Job 168.2
3 168.3 15 Apr 2020 09:11PM UTC 0
81.33
Travis Job 168.3
4 168.4 15 Apr 2020 09:14PM UTC 0
0.0
Travis Job 168.4
Source Files on build 168
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #168
  • 6e73b338 on github
  • Prev Build on master (#162)
  • Next Build on master (#171)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc