and I here is what I have to share:
Thanks! Thank you for being awesome! When I released Ladybug two years ago I could never imagine how this project will take over my life! It has been such an invaluable experience for me so far and it wasn’t possible without you - so thank you so much.
What’s next? Recently I get this question more and more and here is my fairly long answer! Chris is pushing the boundaries with comfort tools. Chien Si is working on HVAC systems integration. Chris, Anton and Alejandra will figure out how to effectively get natural ventilation to be modeled. Patrick, Sandeep, Michal and Boris are working on their developments. I’m working on getting 3 Phase method integrated, and Butterfly will be out at some point, but... they are not going to be what makes the next step. The next step is up to you. It is what you will do with the development. So go ahead and let us know what’s next!
If you can help someone on the group please do! Doing so you are not only helping another person (and potentially yourself) but also the developers. The more you can help each other here the more we will have time for development and documentation.
Best place to send your questions is this group. If you are using the latest version from github then you may want to sent it to github. Please consider emails as the last option. Go back to number 3 again! Thanks.
Don’t be nice to us! Well, I mean don’t just be nice to us. I love your nice comments like anybody else and please keep them coming ;) but what we also need next to nice comments is your critiques, wishes and insight. I feel that recently we are getting less wishes and critiques than what it used to be. You can post them here in the group or on github and either way we will know about it. Thank you to all of you who has already done this.
Thanks again! Before I let you go I want to specially thank all of you who contributed to the project by your development, thoughts and support. You are great and I can’t thank you enough.
David Weinberger in his book “Too Big to Know” says: “When an expert network is functioning as its best, the smartest person in the room is the room itself.” Reading some of the discussions on the group gives me the feeling of staying inside a smart room. Thank you and let’s keep the room growing!
Cheers,
Mostapha
PS: To avoid sending another post, I just post the updates about the two upcoming workshops here:
I will lead a workshop in LA next Friday (Feb. 6) and there is still few seats left. If you want to learn more about energy and daylighting simulation with Honeybee here is your chance. Here is more information who to register: (http://www.facadesplus.com/technology-workshops/).
Chris will lead a 3 days intense and comprehensive Ladybug and Honeybee workshop in Mexico City this March. You have probably watched Chris’s tutorials and already know what you can expect from a workshop with Chris so I don’t have to speak for that! I would take this workshop if I was around that area. If you are around Mexico City or know a friend who might be interested please let them know. Here is more information about the workshop: (https://www.facebook.com/LadyBugforGrasshopper/photos/a.442320969114095.107084.413910668621792/919318878080966).
…
eration!
See an example work flow for designing, simulating and analysing a Photovoltaic system below.
Download a Grasshopper and Rhino example file:
https://www.dropbox.com/s/krbszlplj5i40dz/017_HBgeneration%20Rhino%20model.3dm?dl=0
https://www.dropbox.com/s/lxneuzal3mipd2q/017_HBgeneration.gh?dl=0
See a quick introduction and tutorial videos here: https://www.youtube.com/playlist?list=PLrx2KnyhaJ5YXo5hpk8Q9q4Vy99O5IegK
1. Select a building to mount a photovoltaic generator on (seen in Rhino in green).
2. Select a surface within that building to mount a photovoltaic generator on (seen in Rhino in green).
3. Create a Honeybee context surface from that surface.
4. Place a photovoltaic generator on that Honeybee context surface by using the Honeybee generation component. Honeybee_Generator_PV and connecting the context surface to it's input _HBSurfaces. Then you can specify both the performance and the financial data of the photovoltaic generator.
5. Create a Honeybee generation system which consists of the photovoltaic generator in 4. By using the component Honeybee_generationsystem and connecting 4 to its input PVHBSurfaces_. Then you can specify the annual maintenance cost of this system.
6. Run the simulation in Energy Plus by connecting 5. to the input HBGenerators_.
7. Read the results of the simulation:
- The electricity produced by the Honeybee generation system in 5.
- The net purchased electricity of the facility (the Honeybee zone) to which the Honeybee generation system is attached to. This is the electricity consumed by the facility less the electricity generated by the Honeybee generation system.
- The financial costs of the Honeybee generation system; capital, maintenance and replacement costs.
8. Calculate the net present cost of the Honeybee generation system in 5 assuming a 25 year lifetime.
9. Visualise the net present cost.
…
ting at multiple geometries in the same location. I simply sorted the list of values and used the Delete Consecutive component. This potentially rearranges the order of values but I don't think that matters in your case. I also threw in an Int component which actually seems to make a difference (try sidestepping it and you will see!).
2-I flattened the output of the mesh component before sending it to union. This ensures that the original mesh is booleaned once with all the components rather than individually with each of the 86 components.
Is this what the result should look like?
One suggestion for future postings: when referencing geometry in rhino, it often helps if you attach your rhino file as well so people don't have to guess where you are starting from.
If you have further questions, just ask ;-)
cbass…
edit 29/04/14 - Here is a new collection of more than 80 example files, organized by category:
KangarooExamples.zip
This zip is the most up to date collection of examples at the moment, and collects t
what they really mean by that, as in what buttons to push, so I assume it's a Windows Path entry?
2.) Modify PATH
Add the install location on the path, this is usually: C:\Program File\IronPython 2.7
But on 64-bit Windows systems it is: C:\Program File (x86)\IronPython 2.7
As a check, open a Windows command prompt and go to a directory (which is not the above) and type:
> ipy -V PythonContext 2.7.0.40 on .NET 4.0.30319.225
Tutorial on setting a Windows environmental variable (path):
http://www.computerhope.com/issues/ch000549.htm
But this fails to point out that path contains many entries already separated by semicolons so if I merely add a new variable called "path" it's likely that I will destroy existing program function. There's no info on how to just tack on another entry, and the Windows 7 edit box doesn't even show the whole collection, but one item (!), so I copied the existing path into a text editor to see the whole collection successfully and added the C:\Program Files (x86)\IronPython 2.7 entry after an added semicolon, correcting for an Enthought page typo of no 's' on the end of "Program Files". I also checked the others and many pointed to old missing directories so I deleted those entries.
...and the test fails and "ipy" is not recognized as a command, even though the path now shows up using "path" in the Windows CMD window, that is if I copy all by right clicking and pasting the stuff into a text editor to really view it all. I can run it from the source directory just fine.
The rabbit hole was indeed deep. Using the Task Manager (control-alt-delete) to kill Explorer and then Run in the menu to restart "Explorer," along with restarting the Windows CMD window however, worked. I can now invoke Iron Python ("ipy") via command line from any directory. For the "path" I edited path in the System Variables and not the User Variables. No, you don't have to type that whole crazy line above just to test the path variable, just "ipy" (and control-Z to quite IronPython) in the CMD window invoked by typing "cmd" into the Start menu search box.
From the CMD line this step did work fine:
3.) ironpkg
Bootstrap ironpkg, which is a package install manager for binary (egg based) Python packages. Download ironpkg-1.0.0.py and type:
> ipy ironpkg-1.0.0.py --install
Now the ironpkg command should be available:
> ironpkg -h(some useful help text is displayed here)
But of course Step 4 fails, giving pages of what seem to be error messages;
C:\Users\Nik>ironpkg scipy
Traceback (most recent call last):
File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\enstaller\utils.
py", line 92, in write_data_from_url
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 126, in urlo
pen
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 397, in open
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 509, in http
_response
...
Why can't I just download Numpy as a normal file and thus also have it easy for other users to install it when they use my scripts? This is just crazy and lazy. The Enthought developer has turned this into a computer game, with a missing registration link and then the last step spits out errors with utterly no information on how to fix it manually.
This Step 4 error is covered here:
http://discourse.mcneel.com/t/trying-to-import-numpy-in-rhino-python-but-im-getting-this-error-cannot-import-multiarray-from-numpy-core/12912/16…
Added by Nik Willmore at 2:36pm on October 11, 2015
t defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.
So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:
(image extracted from Johnson, G. T., & Watson, 1984)
Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:
So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.
The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.
H/W=0.25, SVF=0.895
H/W=1, SVF=0.447
H/W=2, SVF=0.246
It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)
According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.
I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.
Appreciate your comments and advice!
References:
SVF: definition based on first principle
Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
Papers on SVF calculation:
Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
SVF calculation based on first principle:
Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
paper on Sky Exposure Factor:
Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011
…
value=WINTERDESIGNDAY, in SIZINGPERIOD:DESIGNDAY=SINGAPORE ANN HTG 99.6% CONDNS DB ************* IDF Context for following error/warning message: ************* Note -- lines truncated at 300 characters, if necessary... ************* 53 SizingPeriod:DesignDay, ************* indicated Name=SINGAPORE Ann Htg 99% Condns DB ************* Only last 10 lines before error line shown..... ************* 57 23.5, !- Humidity Indicating Conditions at Maximum Dry-Bulb ************* 58 101133., !- Barometric Pressure {Pa} ************* 59 2, !- Wind Speed {m/s} design conditions vs. traditional 6.71 m/s (15 mph) ************* 60 320, !- Wind Direction {Degrees; N=0, S=180} ************* 61 0.00, !- Clearness {0.0 to 1.1} ************* 62 0, !- Rain {0-no,1-yes} ************* 63 0, !- Snow on ground {0-no,1-yes} ************* 64 21, !- Day of Month ************* 65 12, !- Month ************* 66 WinterDesignDay,!- Day Type
The relevant lines in the IDF file is shown below:
SizingPeriod:DesignDay, SINGAPORE Ann Htg 99.6% Condns DB, !- Name 23, !- Maximum Dry-Bulb Temperature {C} 0.0, !- Daily Temp Range {C} 23, !- Humidity Indicating Conditions at Maximum Dry-Bulb 101133., !- Barometric Pressure {Pa} 2, !- Wind Speed {m/s} design conditions vs. traditional 6.71 m/s (15 mph) 320, !- Wind Direction {Degrees; N=0, S=180} 0.00, !- Clearness {0.0 to 1.1} 0, !- Rain {0-no,1-yes} 0, !- Snow on ground {0-no,1-yes} 21, !- Day of Month 12, !- Month WinterDesignDay,!- Day Type 0, !- Daylight Savings Time Indicator WetBulb; !- Humidity Indicating Type ! SINGAPORE_SGP Annual Heating 99%, MaxDB=23.5°C SizingPeriod:DesignDay, SINGAPORE Ann Htg 99% Condns DB, !- Name 23.5, !- Maximum Dry-Bulb Temperature {C} 0.0, !- Daily Temp Range {C} 23.5, !- Humidity Indicating Conditions at Maximum Dry-Bulb 101133., !- Barometric Pressure {Pa} 2, !- Wind Speed {m/s} design conditions vs. traditional 6.71 m/s (15 mph) 320, !- Wind Direction {Degrees; N=0, S=180} 0.00, !- Clearness {0.0 to 1.1} 0, !- Rain {0-no,1-yes} 0, !- Snow on ground {0-no,1-yes} 21, !- Day of Month 12, !- Month WinterDesignDay,!- Day Type 0, !- Daylight Savings Time Indicator WetBulb; !- Humidity Indicating Type
It seems that there is an empty line after the line for "!- Humidity Indicating Type" field, and nothing is specified for "! SINGAPORE_SGP Annual Heating 99%, MaxDB=23.5°C" field.
May I ask why this happens and how to correct the error?
Thank you very much!…
ers can be applied from the right click Context Menu of either a component's input or output parameters. With the exception of <Principal> and <Degrees> they work exactly like their corresponding Grasshopper Component. When a I/O Modifier is applied to a parameter a visual Tag (icon) is displayed. If you hover over a Tag a tool tip will be displayed showing what it is and what it does.
The full list of these Tags:
1) Principal
An input with the Principal Icon is designated the principal input of a component for the purposes of path assignment.
For example:
2) Reverse
The Reverse I/O Modifier will reverse the order of a list (or lists in a multiple path structure)
3) Flatten
The Flatten I/O Modifier will reduce a multi-path tree down to a single list on the {0} path
4) Graft
The Graft I/O Modifier will create a new branch for each individual item in a list (or lists)
5) Simplify
The Simplify I/O Modifier will remove the overlap shared amongst all branches. [Note that a single branch does not share any overlap with anything else.]
6) Degrees
The Degrees Input Modifier indicates that the numbers received are actually measured in Degrees rather than Radians. Think of it more like a preference setting for each angle input on a Grasshopper Component that state you prefer to work in Degrees. There is no Output option as this is only available on Angle Inputs.
7) Expression
The Expression I/O Modifier allows you change the input value by evaluating an expression such as -x/2 which will have the input and make it negative. If you hover over the Tag a tool tip will be displayed with the expression. Since the release of GH version 0.9.0068 all I/O Expression Modifiers use "x" instead of the nickname of the parameter.
8) Reparameterize
The Reparameterize I/O Modifier will only work on lines, curves and surfaces forcing the domains of all geometry to the [0.0 to 1.0] range.
9) Invert
The Invert Input Modifier works in a similar way to a Not Gate in Boolean Logic negating the input. A good example of when to use this is on [Cull Pattern] where you wish to invert the logic to get the opposite results. There is no Output option as this is only available on Boolean Inputs.
…
the daylighting and energy sim with Nat Vent create many complex questions.
Daylighting :
1. Adding shading to energy AND daylight simulation: Can I add HBconext to Honeybee_run daylight simulation HBobject input ?
Looking at the results it seems like daylight simulation doesn't recognize HBcontext, or maybe the difference is minute. Am I doing this correctly? Is there a possible error due to redundancy ? (meaning I am introducing the HBcontext twice, one time to the Honeybee_run daylight simulation AND energy simulation)
2. One of the component, Honeybee_Read annual result 1 keeps failing and says that ''1. Solution exception:index out of range: 0." I read here input needs to be internalize data but maybe there is a better solution?
Shading :
I want to study life cycle perspective of
A) Optimal ratio of fixed vs dynamic louvers for economic implementation,
B) Assess whether it makes more sense for the dynamic louvers to functions as light shelvs or the fixed ones for economic reasons
C) Simulate dynamic/fixed hybrid louver system schedule, and show it in a manner similiar to lighting schedule.
For this I would need to simulate the effect of dynamic and-or fixed shades in reducing annual lighting cost while reducing cumulative heat gain.
3_How to introduce Dynamic shading schedule for custom shades? Is this done with EPtranschedule input of the HB EP context component? I would like to keep the louvers branched so that it is possible to assign different modes i.e. fixed or dynamic
Light Shelf:
4_Is the lighting schedule effected by light shelves introduced in the annual daylighting simulation?
5_Does energy simulation take account of additional heat gain from light shelvs ?
6_When I use Honeybee_createHBSrfs with Honeybee_radiance Mirror material, it crashes rhino. The geometry input is not branched. Any report similar crashes?
Nat Vent:
I want to design to combine passivhaus principles with Natural ventilation.
My goal to simulate the energy performance of passivhaus house like building system with Bouyancy driven Nat Vent design which maximizing the percentage of the year Nat Vent takes care of ventilation and cooling, and in cloud days heat exchanger with fans kicks in.
using a trombe roof that heats air and using a vertical shaft that recirculate air, want to minimize the use of fans, Ducts, Heating etc. and I want to use the HB Set_Air flow component to evaluate such system if I can.
while I have heard that bouncy driven system may only be reserved for tall buildings, I still would to simulate the effectiveness for mid rizes and podium- types. I am skeptical whether there will be enough pressure difference for effective ventilation of 1.5ms so I would like to test.
How to set up models to evaluate bouyancy driven ventilation :
7 About HB Set_Air Flow, with Natural ventilation, If I use the HB Set_air the honeyzone output is null. I am not sure why, no error messages.
8_ When using the HB Set Air component to include Nat Vent with bouyancy,
does the result of reduced temperature to take effect into the cooling/equipment/ventilation schedule of the Honeybee_set Energy plus zone schedules?
Additionally I want to incorporate Nat vent analysis with the light shelf, since both would effect indoor temperature.
A wish list: as if it were all this has been not.
9_I wish there is something like a deconstruct honeybee zone component that basically breaks down all the options (mechanically ventilated or not) that is associated with the honeybee zones so that it is easy to document all the properties in text.…