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
…
I live on my computer and I even sleep with it, so learning all this is probably within my reach but I'm a complete beginner as of now.
I'm downloading the 32 bit version of rhino 5 since the 64 bit doesn't seem to work with your downloads Jon.
I haven't grasped everything you have made yet Jon I can't even begin to understand what your IFC stuff is actually capable of, but just to be clear I'm not interested in solely being able to tell that something is colliding as there are already software that can do that beautifully. What I want to do is bypass that step altogether by never having collision-checking back and forth go on, even collisions which aren't physical collisions, but rather just violations by code. The simplest way to do this would be to simply make the geometry of the beams 2 feet wider than they are in real life, so that way you could put a light right next to the 'over-sized' beam and it would still be within the rules. But that would be extremely primitive and I'm sure there's a way to do it mathematically.
Just to clarify, I'm the fire sprinkler designer in the architectural circus. The sprinkler designer (me) doesn't really get the luxury of telling the other trades that they're colliding with my stuff and they should move. Rather, I get their drawings, find out I'm colliding with them, and move around them. So it would be of great use to me to have this be automatic - that is, to automatically space my sprinklers the neccesary distance away from all obstructions. There are different spacing rules for different obstructions - walls, beams, open web steel, unit heaters, hvac ducts depending on how wide the ducts are, lights, fans, high rack storage, basically anything that would obstruct the water spray from a sprinkler needs to be taken into account and spaced away from.
It's therefore a very attractive idea to be able to just draw a rectangle (representing the walls of a simple room) for instance, have the sprinklers automatically spaced as far apart as possible within the rectangle according to the rulebooks (to minimize the amount of sprinklers needed which minimizes the material cost of the job).
Then add obstructions inside the rectangle, such as a beam, and have the sprinklers relocate themselves or add new sprinklers to accommodate for the new obstruction.. Keep adding obstructions until you have the realistic 3d model of the room, with the sprinklers spaced accordingly, and you have an up-to-code sprinkler system.
There is one example where sprinklers actually need to be spaced really close to, rather than away from, an object.. and that is the ceiling (sprinklers must be within 12 in of ceiling typically).
If the HVAC guy decides to reroute his ducts right through my sprinklers, then I could draw 3D HVAC ducts (I usually get 2D drawings coming in) going right through the room and the sprinklers would relocate and auto-space away from the ducts, without actually having to tell the HVAC guy he is colliding with me because all that will do is require me to do a redesign anyway.
And presto, the HVAC guy loves me because I didn't complain to him at all and seemingly did all this work by moving around him when all I really did was use the computer to do it, the job gets done much faster and I don't have to worry that I'm going to lose my job in court because I made a silly human error when I was patching my system manually because some HVAC guy made me redesign 12 times in different places.
From what I have been reading from you guys, doing this is possible although (I realize) ambitious. The end result would be vastly increased productivity, less error making, cheaper design cost, etc. Using programs like Rhino, architects are getting more and more funny-shaped buildings and making it difficult for guys like me to make sprinkler systems within the rules, and I see it as an inevitability that computers will be making almost all of the typical design decisions in the future when it comes to life safety systems, I'm just trying to see if it's possible to start implementing this extra aid today.
…
h, and using the BScale and BDistance are creating havoc somehow too. I've simplified first, and used the Kangaroo Frames component along with setting internal iterations, to make MeshMachine act like a normal component, along with releasing the FixC and FixV. The FixV didn't make any sense anyway. I've also set Pull to 0 to speed it up during testing, since much less calculation is involved to just let the meshes collapse, prevented from disappearing altogether by using a mere 15 iterations.
Also, your breps are open so that allows much more chaos and then collapse, though they did manage to close themselves too at times. Here is closed breps with a full 45 iterations:
So now that it's working, lets re-Fix the curves, and the problem arises that there is an extra seam line that is getting fixed too, running along the cylinder, stopping the mesh from pulling tight under tension wherever a vertex happens to be near that line:
So lets grab only the naked edge curves instead:
And what happens if we lose the end caps, now that we don't have an extra line skewing the result?:
There is no real curvature differences since it's not a curvy brep so the Adapt at full 1 setting has little to do. Now what does the BScale and BDist do? Nothing! Why? Your scale is out of whack, 99 mm high cylinders but only a falloff maximum of about 5, so let's make the falloff be 25 instead, but I must restore the end caps or the meshes collapse away for some reason and freezes Rhino for a minute or so the first time I try it:
It's a start.
If I intersect the cylinders, nothing changes, since they are being treated as separate runs. MeshMachine outputs a sequence of two outputs though, due to Frames being set to a bare minimum of 2 needed to get it to work, so I filter out the original run, which is just the unmodified initial mesh it creates.
The lesson so far is that closed meshes are much less prone to collapse and glitches leading to screw ups.
A Boolean union of the cylinders is when it gets funner, here show with and without the fixed curves that seem to define boundaries too where really there are just polysurface edges:
…
ne – power of the many è un corso advanced level che studia la produzione di effetti complessi a partire dalla modellazione di comportamenti semplici su un insieme strutturato con un numero alto di elementi. Attraverso un approccio generico e scaleless sarà possibile affrontare la tematica generale su più fronti e in una molteplicità di declinazioni possibili. Il corso è rivolto a chi,indipendentemente dal proprio background (urbanistica, architettura, ingegneria, design, arte o altro) già possiede una esperienza di base con Rhinoceros e Grasshopper, e desidera sviluppare aspetti di gestione avanzata del flusso di articolato di informazioni attraverso una strategia guidata basata su esempi pratici e sull’implementazione di un progetto personale sul tema generale del “field behaviour”. Sarà trattato anche l’utilizzo di alcuni plug-ins quali gHowl e WeaverBird. Il numero dei partecipanti è fissato a un massimo di 20 per offrire un tutoraggio proficuo ed una effettiva esperienza di learning ad ogni iscritto.
[.] Temi:
teoria
. complessità, emergence, effetti di campo (field behaviour), sensibilità, efficienza multiperformance
tecnica
. dati:gestione e manipolazione avanzata del data tree, streaming e visualizzazione; transizione, blending e modulazione delle geometrie; generazione e controllo multiperformance di popolazioni di componenti; attrattori, drivers e tecniche di modulazione avanzate; uso delle mesh con WeaverBird; ottimizzazione con Galapagos
[.] Dettagli :
Tutors: Alessio Erioli + Andrea Graziano – Co-de-iT
Si richiede esperienza di base nella modellazione in Rhino (equivalente a Rhino training Level 1, il Level 2 è gradito – la documentazione per il training è disponibile gratuitamente all’indirizzo: http://download.rhino3d.com/download.asp?id=Rhino4Training&language=it) e nell’uso di Grasshopper (la suddivisione di una superficie NURBS in componenti tramite isotrim è data come base assodata)
. luogo:
IreCoop – via Vasco De Gama 27 _ Firenze
. durata:
25-27 febbraio 2010 – 3 giornate consecutive _ orario 9:00 – 18:00
. costo:
professionisti – 450.00 € studenti – 280.00 €
. note:
scadenza iscrizioni: 20 febbraio 2010 il corso sarà attivato con un numero minimo di 15 iscritti al termine sarà rilasciato un attestato di frequenza gli iscritti dovrano venire muniti dei propri laptop con software installato. una versione free per 30 giorni è disponibile sul sito www.rhino3d.com
. contatti:
iscrizioni + info alloggi: www.irecooptoscana.it (Cosa offriamo > formazione > altri corsi)
info sul corso: info@co-de-it.com…
ust assume this is really what is being imported with the standard import line I see in all the examples:
# scriptcontext moduleimport RhinoPython.Host as __host'''The Active Rhino document (Rhino.RhinoDoc in RhinoCommon) while a scriptis executing. This variable is set by Rhino before the exection of every script.'''doc = None'''Identifies how the script is currently executing1 = running as standard python script2 = running inside grasshopper component3... potential other locations where script could be running'''id = 1'''A dictionary of values that can be reused between execution of scripts'''sticky = dict()def escape_test( throw_exception=True, reset=False ): "Tests to see if the user has pressed the escape key" rc = __host.EscapePressed(reset) if rc and throw_exception: raise Exception('escape key pressed') return rc def errorhandler(): ''' The default error handler called by functions in the rhinoscript package. If you want to have your own predefined function called instead of errorhandler, replace the scriptcontext.errorhandler value ''' return None…
Added by Nik Willmore at 7:47pm on October 10, 2015
eather data so it cannot be easily compared to Archsim. My account of the differences between Honeybee and Archsim will be far from complete but here are the key ones that I am aware of:
1) This difference is a bit of a superficial one but points to a deeper thinking about how the software should be used. Honeybee has many more components than Archsim, which means that Honeybee has a steeper learning curve than Archsim and will take longer to master. Along with this, you may also encounter a general mentality in the Honeybee community that "you should not be running a certain type of simulation unless you know how it works" whereas I know that Archsim is a bit more amenable to making things fast and easy to set up even when you are not sure what is going on under the hood. However, as a result of the large number of components in Honeybee, it is more open-ended, customizable, and includes more freedom in terms of cases that you can run and the parameters of the energy simulation that you can change than Archsim. You will also notice that, while there is a general ethos in the Honeybee community that you should not be running certain simulations unless you know what you are doing, we try to provide you with many resources to educate yourself if you are motivated. For example, we have long component descriptions that we assemble into documentation books like this (https://www.gitbook.com/book/mostapharoudsari/honeybee-primer/details), hours of video tutorial playlist like this one (https://www.youtube.com/playlist?list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_), and many GH example files on a github-based file sharing system (https://hydrashare.github.io/hydra/index.html). Not to mention a community of people who would respond to discussions like this one.
2) Archsim as a standalone application will soon be no more and will be instead distributed with the DIVA daylight analysis tool (http://diva4rhino.com/). While I am unclear on the exact trajectory of DIVA, it currently has a price tag attached to it and so I would assume that the future of Archsim will also carry this price tag. On the other hand, Honeybee and any derivative software will forever be free and open source under the GPL licence (https://github.com/mostaphaRoudsari/Honeybee/blob/master/License_Honeybee_GPL.txt).
3) This third point is a bit of a reiteration of the last one but Honeybee is open source, meaning that, if you need a feature of EnergyPlus that is not yet implemented on either interface, you can usually add it in yourself with a few lines of python code in Honeybee. This type of workflow is not possible with Archsim since it is closed source and requires you to use EnergyPlus's text editor interface after Archsim has exported an IDF in order to implement any additional EnerygPlus features.
4) The libraries and templates for Honeybee come from OpenStudio - the open source interface for EnergyPlus (https://www.openstudio.net/), which is supported by the US Department of Energy (just like EnergyPlus). Since Honeybee is open source, it is able to make use of the large database of building type schedules/loads and constructions that have been assembled by the OpenStudio team over the last several years as well as OpenStudio's SDK. I can also say that almost all of the development efforts of the Honeybee team are now focused now on integrating efforts with OpenStudio, including an exporter from Honeybee to OpenStudio that should be fully functional for the next stable release. I am not certain of the current extent of Archsim's libraries but, last I had checked, the creator was pulling them from his own experience and, as such, only had a few libraries to choose from. For all of my knowledge, through, this may be changing with the integration of Archsim with DIVA.
Let me know if this is helpful and, if anyone has more up-to-date knowledge on Archsim than I, please post there.
-Chris…
ave pointed out, if the older version of Honeybee EPZone does not have the recirculatedAirPerArea proprety, then it must be the cause of the error as I am using the Honeybee_Export to OpenStudio component (VER 0.0.58 Nov_07_2015). Given the discrepancy between the version of the Honeybee components used to setup everything in the file all the way prior to the point feeding the zones' data into the Export to Open Studio component, I can see different options/questions to tackle this issue:
1- I have the OpenStudio 1.9.0 that works with EnergyPlusV8-3-0 installed on my computer and the reason that I had to use the newer version of the Honeybee_Export to OpenStudio component (VER 0.0.58 Nov_07_2015) is that I had initially received an error message using the component of the same version as consistent with the rest of the project (VER 0.0.57 Jul_15_2015) with the following content:
"Cannot find OpenStudio libraries. You can download the libraries from the link below. Unzip the file and copy it to C:\Users\Alireza\AppData\Roaming\Ladybug\OpenStudio and try again. Click on the link to copy the address.https://app.box.com/s/y2sx16k98g1lfd3r47zi"
The download link provided in the error message appears to be not active and thereby, I could not follow the instructions on the error message and make the Hoenybee_Export to OpenStudio component (VER 0.0.57 Jul_15_2015) work.
Therefore, if there is a way to make this version (VER 0.0.57 Jul_15_2015) of the Hoenybee_Export to OpenStudio component work by downloading the OpenStudio libraries or switching to a legacy version of the OpenStudio application prior to 1-9-0, then probably this would be one option to solve this issue.
2- When I realized I could not download the OpenStudio libraries as described in section 1 (see above) and make the Honeybee_Export to OpenStudio Component (VER 0.0.57 Jul_15_2015) work with the installed OpenStudio application (V1-9-0), I updated the entire installation of Ladybug + Honeybee User Object files to the new version (Ladybug_0_0_61 and Honeybee_0_0_58). This time the Honeybee_Export to OpenStudio component (VER 0.0.58 Nov_07_2015) seemed to be working with the installed OpenStudio application (V1-9-0) as I did not receive any error messages about missing OS libraries. However, I could not make things work since all other components in my project (eg. Creat HB Zones,Creat HB Surface) have been setup with the 0.0.57 version and obviously, the updated version of the Honeybee User Objects (V0.0.58) could not recognize my HB component of the previous version in the file.
If there is a way to make 'in-place' updates of HB components, for example updating the Honeybee_Create HB Zones in the file without having to re-wire everything from scratch, then it probably would work as the updated version will include the 'recirculatedAirPerArea' property. Otherwise, given the complexity of the scene, it appears to be impossible for me to start everything from scratch and setup the entire scene with the new version of HB components.
3- If none of the options in the last two sections (see above) would be possible, I was wondering if there is a way to open the zones' data as the outcome of the Honeybee_Solve Adjacency component (prior to feeding this data to the Honeybee_Open Studio Systems component and subsequently, to the the Hoenybee_Export to Open Studio) in a text-editor and manually add the missing recirculatedAirPerArea property to the zones' data; then probably I could do that and then eventually feed it to the Hoenybee_Export to Open Studio component.
These are the three options that I could think of in order to tackle this issue of mine. I apologize for the extended reply but I figured it would be better to give a more comprehensive description of my problem and previous attempts to solve it.
Any helps is most appreciated.
Please let me know if you need further information about the described issues in each section or the simulation scene setup in general.
Thank you,
Alireza
…
er). With the command "End Bulge" I noticed that G2 moves perpendicular to G1! But with an increase which is not equal... and is different, every time, depending on the angle between G0 and G1 and G2. How do I predict the position of G2 compared to G1 simulating the "End Bulge" command? Thank you for your professional answers.
^___^
Below you can see an example with a curve crimson ... If I move G1 of 1 unit G2 moves of 0.42 units (perpendicular) .. If I move of 2 units the next step is 0.46 unit... 3 units --> step 0,50 units... etc.
And each time changes depending on the initial conditions (G0/G1/G2 angle).
…
Added by Lucius Santo at 4:21pm on September 20, 2012
.com/forum/topics/use-pythoneditor-to-run?commentId=2985220%3AComment%3A138538
For now I am considering a simple test case in which a set of sliders are added together into a GH_number component called "output":
I am finding that from the Rhino Python Editor it is definitely possible to change the slider values and retrieve results in a loop. Below I copied the code that runs from the Rhino Python Editor, where I simply change the slider value of the slider with Nickname "Number Slider1" from 0 to 2. (note that grasshopper and the testfile are already open in this example)
This script prints out the following results as expected:
Slider value: 0.0Result value: 1.154Slider value: 1.0Result value: 2.154Slider value: 2.0Result value: 3.154
However using the exact same code in a GHPython component within Grasshopper the Grasshopper Python Script Editor's console reads:
Slider value: 2.0Result value: 3.154Slider value: 2.0Result value: 3.154Slider value: 2.0Result value: 3.154
It seems that the solver doesn't recompute during each iteration but just retrieves the final state of my script.
So basically I have been trying to trigger a 'runsolver' command inside my loop. I tried using the methods available trough the RhinoScript interface, as David describes here.
http://www.grasshopper3d.com/forum/topics/open-a-gh-automatically
I could create a loop looking like this:
But running this in the Grasshopper Component crashes Rhino. I have also tried this by Disabling the solver first using the DisableSolver() method. This does disable the solver but still Rhino crashes. Also I used the ExpireSolution(True) method on the slider object like:
However in this case I don't get any different results.
So I guess my question is simple:
Is there a way to recompute the solver after a slider change inside a GHPython script component during a loop?
Any suggestions, or references would be greatly appreciated!
(FYI: I am using Rhino5x64 and Grasshopper Version 0.9.0014, attached is the script I used both in the Rhino Python Editor and the GHPython component and the grasshopper file)…
y using the Honeybee_Update Honeybee component.
The video below (best viewed in full-screen mode) provides an idea of what these components are capable of being used for:
The video below shows how these components can be used in an existing Honeybee project (for additional links please open this video in youtube):
I have uploaded two examples as Hydra files that show how these components can be used for grid-point and image-based simulations:
Example1 : Grid Point Calculations
Example2: Image based simulation
Finally, a more esoteric application is demonstrated in this video:
These components are still in the beta-testing stage. Some of the limitations of the components are:
1. Only Type C photometry IES files are supported at present.
2. Rhino is likely to get sluggish if there are too many luminaires (i.e. light fixtures) present in a scene.
3. Due to the spectral limitations of the ray-tracing software (RADIANCE), simulations involving color mixing might not be physically realizable.
Additional details about photometric and spectral calculations are probably an overkill for this forum. However, I'd be glad to answer any related questions. Please report any bugs or request new features either on this forum or on Github.
Mostapha, Leland Curtis, Reinhardt Swart and Dr. Richard Mistrick provided valuable inputs during the development of these components.
Thanks,
Sarith
Update 16th January 2017:
An example with some new components and bug fixes since the initial release announcement can be found here
…