Grasshopper

algorithmic modeling for Rhino

Annual Daylight Simulation: Running the simulation for only a few days in each month

Hi!

I am running a series of annual daylight simulations to get readings for sDA and ASE, but naturally the process time is quite long.

I know for quick analysis using 3DS Max Design, you can specify certain frames to render for a weather file/Perez sky model analysis to provide illuminance readings for certain days of the year.

Is there a way we could do this in Honeybee much like the analysis period component from ladybug, but specify several disconnected periods instead of one period (5 days of every month for example)?

Views: 1906

Replies are closed for this discussion.

Replies to This Discussion

Currently it's not possible, and won't be helpful, simply because of how Daysim works. The calculation for Daysim is based on calculating daylight coefficients which is the part that takes the longest time. Once that is done generating the results for couple of hours vs the whole year doesn't make that much of a difference. If your geometry doesn't change then 3-phase method could have been very useful in a case like this.

Hi Mostapha
i heard about 3-phase method radiance in
"The New IES-Approved Daylight Metrics - AIA San Francisco -Webinar "
in Honeybee how we can use 3-phase method ? just without changing geometry in future analysis?
Best

Hi Mohammad. We currently don't support 3Phase method but it will be available at some point soon or at least through OpenStudio.

Is anyone working on this right now ? I am doing something for my dissertation work which I  will try and pass on upstream, however, if there is someone else working on it as well I'd like to collaborate and share notes !

I'm working on 3 Phase through the OpenStudio integration (https://github.com/mostaphaRoudsari/Honeybee/issues/290) but you're the only one who I know who's doing it from Honeybee itself.

Okay. I thought of going OpenStudio or Stadic (the Penn State project) route too but I am not likely to learn a whole lot for myself that way. It's great to know that you've made progress on that.

Any suggestions on how to handle perl files in a Honeybee environment? I usually do something like ["c:\radiance\perl\bin\perl.exe","c:\radiance\bin\genkelmsamp.pl" ....] when I do this in pure python and subprocess but that doesn't seem to be the right or stablest approach in Grasshopper/Honeybee. It also tends to fail when the folder structure is relative instead of absolute ( I guess that can be fixed by specifying a cwd upfront).

In any case we will need 3 Phase for Honeybee as OpenStudio workflow has it's own limitation. I will be also joining you at some point to get this work together.

I believe that you don't need to run the perl script anymore using the new method. gendctimestep takes care of what genkelmsamp is supposed to do. Isn't it? Nevertheless, I found os.system more stable than using subprocess specially for longer executions.

I was using genklemsamp all this while. If I can get it to work with normal binary file like dctimestep that will be great ! Thanks for the tip about os.system.

In case you haven't already check Andy's presentation for using the new files: http://www.radiance-online.org/community/workshops/2014-london/pres...

Sarith, OpenStudio gives a very nice report while it's running the 3Phase analysis. I thought that it might be helpful for you. Here is the lines. I also attached the file which is the OpenStudio testroom for Radiance measure.

```

SET RAYPATH=.;C:\Radiance\lib
PATH=C:\Radiance\bin\;$PATH

:: :: Running radiance in directory: 'C:/Users/Administrator/AppData/Local/Temp/OpenStudio.CyK480/resources/run/1-UserScript-0/radiance'
epw2wea "C:\EnergyPlusV8-3-0\WeatherData\USA_CA_San.Francisco.Intl.AP.724940_TMY3.epw" wx\in.wea

:: :: passing 45 calculation points to Radiance
:: :: computing daylight coefficient matrices
oconv materials\materials.rad model.rad > model_dc.oct
oconv "materials\materials.rad" "materials\materials_WG0.rad" model.rad "skies\dc_sky.rad" > model_WG0.oct

:: :: UTC: computing daylight/view matrix for static window group (WG0)...
:: type "numeric\merged_space.map" | rcontrib -ab 6 -ad 4050 -as 256 -dj 1 -dp 1 -dt 0 -dc 1 -lw 0.001 -I+ -fo -e MF:1 -f tregenza.cal -b tbin -bn Ntbins -o "output\dc\WG0.vmx" -m skyglow model_WG0.oct
:: :: It gives me a warning > c:\radiance\bin\rfluxmtx: warning - ignoring output file in sender ('output/dc/WG1.vmx')

:: :: computing daylight matrix for window group WG1...
rfluxmtx -ab 2 -ad 512 -as 256 -dj 1 -dp 1 -dt 0 -dc 1 -lw 0.001 -n 3 -fa -v "scene\shades\WG1_SHADE.rad" "skies\dc_sky.rad" -i model_dc.oct > "output\dc\WG1.dmx"

:: :: computing daylight matrix for window group WG2...
rfluxmtx -ab 2 -ad 512 -as 256 -dj 1 -dp 1 -dt 0 -dc 1 -lw 0.001 -n 3 -fa -v "scene\shades\WG2_SHADE.rad" "skies\dc_sky.rad" -i model_dc.oct > "output\dc\WG2.dmx"

:: :: computing view matri(ces) for controlled windows
:: type "materials\materials_vmx.rad" scene\shades\WG1_SHADE.rad scene\shades\WG2_SHADE.rad > receivers_vmx.rad
:: oconv materials\materials.rad scene\NE_Space_104.rad scene\NW_Space_103.rad scene\SE_Space_102.rad scene\shading_building.rad scene\shading_site.rad scene\SW_Space_101.rad > model_vmx.oct
rfluxmtx -ab 6 -ad 4050 -as 256 -dj 1 -dp 1 -dt 0 -dc 1 -lw 0.001 -n 3 -ds .15 -faa -y 45 -I -v - receivers_vmx.rad -i model_vmx.oct < numeric\merged_space.map
oconv "materials\materials.rad" model.rad "skies\dc_sky.rad" > model_wc.oct

:: :: computing DCs for window control points
type "numeric\window_controls.map" | rcontrib -ab 2 -ad 512 -as 256 -dj 1 -dp 1 -dt 0 -dc 1 -lw 0.001 -I+ -fo -e MF:1 -f tregenza.cal -b tbin -bn Ntbins -o "output\dc\window_controls.vmx" -m skyglow model_wc.oct
:: :: done (daylight coefficient matrices).

:: :: Calculating annual daylight values for all window groups and shade states
gendaymtx -m 1 "wx\in.wea" > annual-sky.mtx
dctimestep "C:\Users\Administrator\AppData\Local\Temp\OpenStudio.CyK480\resources\run\1-UserScript-0\radiance\output\dc\WG0.vmx" annual-sky.mtx | rmtxop -fa -c 47.4 120 11.6 - > "C:\Users\Administrator\AppData\Local\Temp\OpenStudio.CyK480\resources\run\1-UserScript-0\radiance\output\ts\WG0.ill"
dctimestep output\dc\WG1.vmx bsdf\air.xml output\dc\WG1.dmx annual-sky.mtx | rmtxop -fa -c 47.4 120 11.6 - > output\ts\WG1_air.xml.ill
dctimestep output\dc\WG1.vmx bsdf\air.xml output\dc\WG1.dmx annual-sky.mtx | rmtxop -fa -c 47.4 120 11.6 - > output\ts\WG1_air.xml.ill
dctimestep output\dc\WG2.vmx bsdf\air.xml output\dc\WG2.dmx annual-sky.mtx | rmtxop -fa -c 47.4 120 11.6 - > output\ts\WG2_air.xml.ill
dctimestep output\dc\WG2.vmx bsdf\air.xml output\dc\WG2.dmx annual-sky.mtx | rmtxop -fa -c 47.4 120 11.6 - > output\ts\WG2_air.xml.ill
dctimestep output\dc\window_controls.vmx annual-sky.mtx | rmtxop -fa -c 47.4 120 11.6 - | getinfo - > output\ts\window_controls.ill

:: :: Merging results:
:: :: Processing window group 'WG1', setpoint: -1000 lux

```

Attachments:

Hi Mostapha, the OpenStudio output log is really helpful ! I can use that to create a similar workflow in Grasshopper/Honeybee. By the way, is there a 2-phase(ie daysim type daylight-coefficient) implementation in honeybee right now ? I know from reading your code that you create a .hea (daysim-header) file for annual daylighting simulations. Do you also have a rcontrib based annual daylighting calculation implemented somewhere ? I got the two phase calculations, with rmtxop and gendaymtx, to work yesterday and they seem to work a lot faster than Daysim. I still don't know if the illuminance values being generated by it are right/reasonable or not.  

(Dont' know why, but I am not able to reply to your last comment directly)

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service