guages I'd recommend all use the RhinoCommon SDK and thus all have access to the same functionality.
How long would it take me to understand and write my own code?
If you already know how to program, it probably won't take too long. If you're past the hurdle of what it means to declare and assign variables, how conditionals and loops work and what scope is, you've already rounded the hardest corner.
Is it even worth it?
That really depends. "Learn programming" is clearly not blanket good advice. Most people out there do not have to learn programming to be happy with their lives and successful in their careers. For some people it can make a small difference, and for a few people it can make a huge difference. If you feel you're in the 'some' category then this is indeed a question you have to answer. Note that the investment for learning programming is a continuous process. Unless you keep up your skills and learn about new stuff that becomes available, you'll lose the ability to write successful code over time.
Where do I start?
Step 1 is to answer the previous question. It is unlikely that anyone besides yourself can answer it, but you can start by making a list of things you do manually now that may be programmable. Then make a list of the things you are unable to do now but which you might be able to do with programming. If while looking at these lists your reaction is: "meh", the answer is probably no.
Step 2 is to pick a language. This is again a very personal thing; there's no wrong answer, because there's no right answer.
Step 3 is to start learning this language. My experience is that the best way to learn a programming language is to try and solve a real problem that you understand very well. If the problem statement is nebulous or poorly understood, you'll be learning two things and that's a recipe for unnecessary frustration.
Here are my thoughts on language:
Python: I don't use Python myself, I can sort of read it while moving my lips. I don't particularly like Python though. The indentation sensitiveness stresses me out, and I find the lack of type-safety disturbing. However it is a good language for mathematical/scientific programs. There are lots of additional code libraries you can easily import that will ease the development of mathematically intense algorithms.
C#: I like C# very much, but it does suffer from geekerosis. A lot of the keywords used in the language are not self-explanatory (abstract, sealed, virtual). For me this is no longer a problem as I've memorised what they all mean. C# is designed to be an efficient language to write, rather than an easy one to learn.
The great thing about C# though is that there's a huge amount of material out there for learning it. It is one of the most popular, mature and modern languages you can hope to pick.
VB: I learned VBScript as my first language, and then moved on to VB5, VB6 and VB.NET. It is somewhat more friendly than C#, and functionally it is almost identical. The switch from VB to C# is reasonably low-threshold and there are excellent tools for translating VB code to C# and vice versa.
Since you already know some Python, it probably makes the most sense to continue on that path. If you want to switch, C# is more like Python than VB, so C# would be my next suggestion.
As for where to get information... you have 4 major options when developing code for Rhino.
If it's a question about the language itself, StackOverflow is a great resource. It can be a pretty hostile place for beginner questions, but I find that mostly the questions I'm asking have been asked already and the answers on SO tend to be good. In fact usually when I google my questions, the first few hits are always SO posts.
If it's a question about the Rhino SDK or Grasshopper, you can ask it either on the GH forums (where we are now), or on Discourse. We're not as quick on the draw as SO, but we do know about Rhino.
If you're looking for a basic explanation of what a keyword or a type is for, perhaps with an example, MSDN is the best first choice. In fact if you google the name a of a .NET type, the first hit is almost always an MSDN page.…
Added by David Rutten at 2:03pm on December 3, 2014
umbrella of Urban Heat Island (UHI) and I am going to try to separate them out in order to give you a sense of the current capabilities in LB+HB.
1) UHI as defined as a recorded elevated air temperature in an urban area:
If you have access to epw files for both an urban area and a rural area, you can use Ladybug to visualize and deeply explore the differences between the two weather files. Ladybug is primarily a tool for weather file visualization and analysis and it can be very helpful for understanding the consequences of UHI on strategies for buildings or on comfort. This said, if you do not have both rural and urban recorded weather data or you want to generate your own weather files based on criteria about urban areas (as it sounds like you want to do), this definition might not be so helpful.
2) UHI defined by air elevated air temperature but viewed as a computer model-able phenomenon resulting primarily from urban canyon geometry, building materials, and (to a lesser degree) anthropogenic heat:
This definition seems to fit more with they type of thing that you are looking for but it is unfortunately very difficult and computationally intensive such that we do not currently have anything within Ladybug to do this right now. I can say that the state-of-the art for this type of modeling is an application called Town Energy Budget (TEB) and this is what all of the advanced UHI researches that I know use (http://www.cnrm.meteo.fr/surfex/spip.php?article7). Unfortunately for those trying to use it in professional practice, it can take a while to get comfortable with it and it currently runs exclusively on Linux (this does mean that it is open source, though, and that you can really get deep into the assumptions of the model). A couple years ago, a peer of mine translated almost all of TEB into Matlab language making it possible to run it on Windows if you have Matlab. He wrapped everything together into a tool called the Urban Weather Generator (UWG), which can take an epw file of a rural area and warp it to an urban area based on inputs that you give of building height, materials, vegetation, anthropogenic heat, etc. I would recommend looking into this for your project, although, bear in mind that is it not open source like the original TEB tool and that you may need to get a (very expensive) copy of MATLAB (http://urbanmicroclimate.scripts.mit.edu/uwg.php).
3) UHI as defined by a thermal satellite image of an urban area depicting an elevated average radiant environment that reaches a maximum a the city center and changes by land use:
This is the definition of UHI that I am most familiar with and was the basis of much of my past research. I feel that it is also a definition of UHI that is a bit more in line with where a lot of contemporary UHI research is headed, which is away from the notion of UHI as a macro-scale meteorological phenomena that is averaged as an air temperature over a huge area towards one that accepts that different land uses have different microclimates and (importantly) different radiant environments. While the air temperature difference between urban and rural areas usually does not change more than 1-4 C, the radiant environment can be very different (on the order of 10-15 C differences). The best way to understand UHI in this context is with Thermal satellite images, for which there is ha huge database of publicly available data on NASA's glovis website (http://glovis.usgs.gov/) or their ECHO website (http://reverb.echo.nasa.gov/reverb/#utf8=%E2%9C%93&spatial_map=satellite&spatial_type=rectangle). I tend to use thermal data from LANDSAT 5-8 and ASTER satellites in my research. Unfortunately, there is a lot f bad data with a lot of cloud cover mixed in with the really good stuff and it can take some time to find good images. Also, there aren't too many programs that read the GeoTiff file format that you download the data as. I know that ArcGIS will read it, a program called ENVI will read it (I think that the open source QGIS can also red it). I have plans to write a set of components to bring this type of data into Rhino and GH (I may get to it a few months down the line).
4) UHI as a computer model-able notion of "Urban Microclimate" with consideration of local differences and the local radiant environment:
This is where a lot of my research has lead and, thankfully, is an area that Honeybee can help you out a lot with. EnergyPlus simulations can output information on outside building surface temperatures and these can be very helpful in helping get a sense of the radiant environment around individual buildings. Right now, I am focusing just on using this data to fully model the indoor environments of buildings as you see in this video:
https://www.youtube.com/watch?v=fNylb42FPIc&list=UUc6HWbF4UtdKdjbZ2tvwiCQ
I have plans to move this methodology to the outdoors once I complete this initial application to the indoors. For now, you can use the "Surface result reader" and the "color surfaces based on EP result" components to get a sense of variation in the outside temperature of your buildings.
I hope that this helped,
-Chris
…
ahams's question about how shades are accounted for in the simulation/thermal map and Theodore's thought that just accounting for shades in the E+ run was sufficient. I think that it may be clearest to explain what is going on with this infographic:
As the graphic shows, the thermal maps are made from 4 key types of inputs. The radiant temperature map is formed through a consideration of both the temperature of the surfaces surrounding the occupants and the direct solar radiation that might fall onto the occupants through un-shaded windows. The first surface temperature effect is easily computable from your Energy simulation results and the HBZone geometry. However, the second is calculated by seeing how sun vectors pass through the windows of the zones and uses the SolarCal method of the CBE team (http://escholarship.org/uc/item/89m1h2dg) to compute an MRT delta resulting from solar radiation. This delta is then added to the initial values computed through surface temperature view factor. When you do not connect up your shading brep geometry, internal furniture breps, or outdoor context geometry that might block sun to the additionalShading input, the thermal map will assume that sun can pass unobstructed through the window or through indoor furniture to fall onto occupants. It is important to stress that the EnergyPlus simulation does not count for blind geometry or internal furniture as actual geometry. Just as numerical abstractions of surface area and material properties. So we need you to plug in the actual geometry of these things when we compute the MRT delta resulting from sun falling directly onto people.
Next, to clear up the definition of window transmissivity. The important thing to clarify here is that, whether it refers to the tranmittance of glass or to the amount of sun coming through a fine screen of blinds, the value is multiplied by the radiation falling on the occupant and thus has a direct correlation to the MRT Delta from sun falling on occupants. So, if you set transmissivity to zero, the sun falling on the occupants will not be considered in the calculation and, if you set the transmissivity to 1, the assumption is that there is no window (or the window glass is 100% clear). So, Abraham, your definition of it as a coefficient is appropriate.
Normally, I would just recommend that you leave this value at the default 0.7, which corresponds to the transmittance of the default glass material in Honeybee. However, there are 4 cases in which you might consider changing it:
1) You are not using the default Honeybee glazing material, in which case, you should change the transmissivity to be equal to this new value.
2) You have a lot of really small blind/shade geometries and you do not want the view factor component to take several minutes to trace sun vectors through the detailed shade geometry and so you are ok with using just a simple abstraction instead of plugging shade breps into the additionaShading. In this case, you might try to estimate the average percentage of radiation coming through the blind geometry (maybe with some simple Ladybug radiation studies or with your intuition about the amount of sun blocked by the shades). You will then multiply this by the tranmissivity of your glass and this will be the value that you input to the component.
3) Your blinds for your Honeybee simulation are dynamic, in which case, plugging shade breps into additionalShading is not going to work because the component will assume that those shades are always there. In this case, you should be plugging a list of 8760 values into the transmissivity that correspond to when the shades are pulled. When the blinds are completely up, the value should be the tranmittance of your window and, when they are down, the value should be the window tranmittance multiplied by the fraction of light coming through the shades.
4) You have shades/blinds but they are transparent or are not completely opaque. The additionalShading_ input assumes that all shade geometry is opaque and so you cannot use it to account for such shades. Accordingly, you will need to account for it through the tranmissivity.
In the future, I may try to pull more information about blinds and glass properties off of the HBzones inside the view factor component but, for now and for the next few months, the above describes how it works.
Theodore, for curved geometry, I think that your safest bet is going to be planarizing the Rhino geometry before you turn it into a HBZone (so you just divide the curved surface into a few vertical planar panes of glass that approximate the curve well enough). This is essentially what the runSimulation component does for you automatically (it meshes the geometry as you see here: https://www.youtube.com/watch?v=nMQ2Pau4q6c&index=12&list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_). If I were to figure out a way to incorporate shades in this automatic meshing workflow, your EnergyPlus simulation would take a very long time to run and I am not even sure if the result will be that accurate with the way E+ abstracts shades. So I don't think that it's really worth it over just planarizing the geometry yourself.
Lastly, I won't be able to figure out the problem with your current run Theodore, unless I get the GH file from you. Make sure that you are using all up-to-date components.
-Chris…
Because the Adaptive methodology is founded upon the notion that there are hundreds of social factors that influence comfort and that the best we can do to forecast comfort is to find variables with good correlations to these social factors (like outdoor temperature), the premise that these published Adaptive model holds regardless of cultural norms is dangerous. Notably, the founders of the adaptive model have stressed that this particular linear correlation that you cite comes from recent surveys of buildings where people have both the the ability to open windows AND a great freedom to dress down. Hypothetically, if occupants were able to open the windows in Abraham's building but the cultural norm was that everyone was expected to wear multi-layered suits or dresses (as in historic Britain), a different correlation between outdoor temperature and comfort temperature would exist. In fact, historical European comfort surveys show that people likely preferred cooler temperatures in buildings (about 1-2C cooler) than today's occupants. Accordingly, after recognizing this social premise in the Adaptive model, I have built in a few ways to adjust/alter the version in Ladybug based on the literature I have read (even though these alterations are not a part of any official ASHRAE or European standard).
Abraham, you might have to be a bit more specific about how you would like to adjust the Adaptive comfort model for me to help your particular case and this may lead to me adding in new functionality. For the time being, I can tell you that the 'Ladybug_Adaptive Comfort Parameters' component is going to be your friend and I would recommend using the Adaptive Comfort Chart to visualize how you are changing the model. You can plug these 'Adaptive Comfort Parameters' into the 'Adaptive Comfort Recipe' component to have the microclimate analysis run with these parameters. Here are a few examples of how to alter the model:
1) Mixed-mode Building - Humphreys and the European Adaptive comfort team derived two separate correlations.
One for naturally ventilated buildings:
and conditioned buildings:
The dimensionless value between 0 and 1 for _levelOfConditioning allows you to create different correlations depending on whether occupants have complete freedom of dress and window operability (0) or have slight restrictions like in a mixed mode building (0.5, for example):
2) Changing Response Time of Occupants - There has been a bit of a debate in Literature about whether it is better to use the average monthly temperature or a weekly running mean temperature. The avgMonthORRunningMean input allows you to adjust this like so:
Average Month:
Running Mean:
3) Greater Temperature Range Tolerance - While this last one is actually a part of the European and Adaptive standards, you can adjust the range of the comfort band with either the 'eightyOrNintetyComf' input or the comfortClass input like so:
Ninety Percent Comfortable
Eighty Percent Comfortable
Abraham, let me know if you would like more controls over the model or if this is enough to do what you are thinking of. This example file allows you to construct the images I have above:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Adaptive_Comfort_Chart&slide=0&scale=1&offset=0,0
-Chris…
ther math and logic. i can usually conceptualise what i want to do and cobble some semi working thing together but don't know which components to use and how to patch it. so i'm super happy to have someone who knows what he's doing to find this interesting.
and i'm glad you mention the fanned frets again, there is one input parameter that's still missing for the multiscale frets to be fully parametric, it's the angle of the nut or which fret should be straight. it depends a bit on personal preferences and playing posture what is more comfortable. so being able to adjust this easily would be cool. again i have no idea how the maths for that work or if you can just rotate each fret the same amount around it's middle point. The input either as fret number (for the straight fret) or as a simple slider from bridge to nut should do as input setting.
Here are the two extremes and the middle ground:
i've been thinkin today while analysing your patches and cleaning up my mess what exactly the monster should do.
Here are the input parameters needed, i think it's the complete list
scale length low E string
scale length high e string
fret angle/straight fret
string width at nut
string width at bridge
number of frets
fretboard overhang at nut (distance from string to fretboard bounds)
fretboard overhang at last fret
string gauges
string tensions
fretboard radius at nut (for compound radius fretboard radius at bridge is calculated with the stewmac formula)
fretwire crown width
fretwire crown height
action height at nut (distance between bottom of string and fretwire crown top)
action height at last fret
pickup 1 neck position
pickup 2 middle position
pickup 3 bridge position
nut width
the pickup positions should be used to draw circles for the magnet poles on each string so they are perfectly aligned and can be used for the pickup flatwork construction. ideally they would need a rotation control aligning the center line of the pickup so it's somewher between the last fret angle and bridge angle. personally i do this visually depending on the design i'm looking for, some people have huge theories on pickup positioning but personally i don't believe in it.
that should result in everything needed to quickly generate all the necessary construction curves or geometry for nut/fingerboard/frets/pickups. this is the core of what makes a guitar work, the more precise this dynamic system is the better the guitar plays and sounds.
i posted another thread trying to understand how i could use datasets form spreadsheets,databse, csv to organize the input parameters. What would make sense for the strings for example is hook into a spreadsheet with the different string sets, i attached one for the d'Addario NYXL string line which basically covers all combos that make sense.
The string tension is an interesting one, and implmenting it would sure be overkill albeit super interesting to try. it should be possible to extrapolate from the scale length of each string what the tension for a given string gauge of that string would be so that you could say 'i want a fully balanced set' or 'heavy top light bottom) and it would calculate which SKU from d'addario would best match the required tension. All the strings listed in the spreadsheet are available as single strings to buy.
i'm trying to reorganize everything which helps me understand it. i just discovered the 'hidden wires' feature which is great since once i understood what a certain block does or have finished one of my own, i can get the wires out of the way to carry on undistracted. a bit risky to hide so many wires but it makes it so much easier not to get completely lost :-)
btw, the 'fanned fret' term is trademarked, some guy tried to patent it in the 80's which is a bit silly since it has been done for centuries. there is a level of sophistication above this as well, check out http://www.truetemperament.com/ and that really is something else. it really is astounding how superior the tuning is on those wigglefrets, the problem is that it's rather awkward for string bending and also you can't easily recrown or level the frets when they are used. …
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.
…
nd the challenge "Building the Invisible: Informing Digital Design with Real World Data". Information about each Workshop Cluster can be found here:
Cyber GardensUse the ForceUrban FeedsSuspended DreamsInteracting with the CityAgent ConstructionAuthored SensingPerforming SkinsResponsive Acoustic SurfacingHybrid Space Structure Typologies
The SmartGeometry 2011 Workshop will take place at CITA http://cita.karch.dk/
Applications to attend the SmartGeometry 2011 Workshop in Copenhagen will close on 31st January 2011. General Conference registration will open within 1 month.
We hope to see you there!
****************************************************
Workshop 28th-31st March
Shop Talk 1 April
Symposium 2 April
Reception 2 April
These events follow the highly successful previous SG events in Barcelona 2010, San Francisco 2009, Munich 2008, New York 2007, Cambridge/London, UK 2006 and multiple preceding events.
Click here for more info...
This year's Challenge is entitled:BUILDING THE INVISIBLEInforming Digital Design with Real World Data
THE PREMISEVast streams of data offer a rich resource for designers. By incorporating external information into our design processes the autonomy of the design is challenged. User data, energy calculations, embedded sensing, material and structural simulation, human behaviour and perception, particle flows and force fields allows design to be situated and responsive. From the simulation of megacities to the solid modelling of material systems, design has the potential to be informed by the real. Design sits not separate from is environment but inhabits an ecological system, open, dynamic and interdependent, diverse, partially self-organising, adaptive, and fragile. Across scale and within time we now have the chance to instil architecture with an immanent intelligence creating new relationships between the user, the built and its ecosphere.THE OPPORTUNITYSystems theorists suggest that data is only a raw material. It can be differentiated from information, knowledge and wisdom. Understanding is multi-levelled: understanding of relations, understanding of patterns, understanding of principles. As digital designers our challenge is in harnessing the power of computation to assist us in informing our design process. Computers help us collect, manage and analyse the environment and inform us about an abundance of data. Our challenge is to use these inputs in a meaningful way to help us make better informed design decisions.THE AIMSG 2011 explores how the incorporation of real world data challenges existing design thinking. The SG 2011 workshop aim is to create physical prototypes of design systems to be exhibited in the SG2011 exhibition.
The SmartGeometry Group is a not-for-profit educational organization dedicated to the use of computational tools in architecture and engineering. SG brings professionals, academics, and industry together to explore the next generation of digital design. SG Workshops are non-platform specific, believing it is the methodology, not the tool, that matters.
…
Added by Shane Burger at 11:23am on January 6, 2011
currently within a fake euphoria framework - blame China/UAE) and a potential decision about doing/developing this or doing that … well …anyway … read and enjoy.
AEC matters: The good, the bad and the ugly.
The bad news: Rhino is NOT suitable for the job (although some use it … but only in the sense that people use Modo for the so called “hard modeling”). By job I mean things up to shop drawing level + specs + you and me (we call it Final level) – nothing to do with sketches and outlines of some abstract “schematic” topology.
The ugly news: The so called Design-Construct approach gains exponentially momentum especially in countries the likes of China/UAE/BRICS (95% of the whole AEC activity worldwide happens there). DeCo means: AEC engineers deliver some kind of study in a preliminary level and the main contractor splits (outsourcers) the job and assigns the study completion AND the construction to various sup-constructors. That thing appeared first – in a large scale - in Dubai 15 years ago. This means that the era of Sergio Pininfarina is over and out: welcome anonymous Toyota designer. In plain English: days of construction corporations fast replacing practices. Dead men walking.
The good news: All AEC related apps (Revit, AECOsim, Allplan and the likes) are in a lethargic state as regards the brave new world (based on the archaic level driven organization schemas etc etc). Of course they all claim the exact opposite and point that support BIM (nobody mention PLM) better than the other guy. But the 21st century – helped by 2 forthcoming unavoidable crisis (a) about shortage of water (b) about transition from carbon to hydrogen economy – isn’t about bureaucracy: think cost/resources optimization and “fitness” rather than China/UAE type of liquid trend. Days of euphoria fast approaching the Wall.
Top to bottom and visa versa.
Old days Titans (Oscar, Mies, Walter, Pierre Luigi, Frank, Eero, blah blah) outlined things (mostly using crayons) and the rest were struggling to translate these in reality in an one way vector like process : Top to bottom that is. These days the inverse gains momentum : when in the whole consider the part … validate … redo … validate … redo. This means bottom to top geared with top-to-bottom. In plain English : child imposes rules to parent and parent imposes rules to child. This means classic MCAD feature/history modeling (CATIA/NX/MS). This is something that Rhino can’t do (not to mention that Rhino is a surface modeler – a rather critical fact).
The parts that are bigger than the whole.
Go there ( http://www.behance.net/gallery/2885057/a-myriad-of-cables) are inspect the whole thing: it’s a parametric nightmare made with the other guy (Generative Components – slower than a Skoda + bugs + why bother?). But the whole (masts and membranes and the likes) means nothing here: focus to the details that are critical for connecting this with that. Complex feature driven solids that are made with internal (on a per se basis) parameters (like fillets required for casting or radius for cable anchoring) whilst they comply with external rules/parameters (cable angles, topology clash issues etc etc). So the whole outlines possibilities … and the part either can follow…or the part must change…or the whole must change. Can you do that with GH/Rhino? And if not what’s missing? (lot’s of things to be honest).
Some other "similar" things:
The narrow picture.
I agree with what others already said and with pretty much all Ola’s points – especially the visual drag-and-drop path mapper (i.e. a visual data manipulator so to speak) and the enable/disable components in groups capability.
Some other suggestions:
A multi canvas capability. As things are right now…it’s like working in Rhino in one view (rather unsuitable I guess). In fact …since overlapping views they don’t work in Rhino…well…you know, he he.
A working auto profile arrangement capability (non twisted Loft/Sweep and the likes). Worth 1Bn dollars that one.
Ability to locate components that caused this or that in the Rhino view: meaning a 2 way communication approach : GH makes things happen in Rhino and things can indicate their cause in the GH canvas.
A robust collection of components that bake stuff in nested blocks (emulating some primitive assembly/component way of thinking). Why may you ask? Well … the whole objective is to talk to CATIA (via STEP) don’t you agree? CATIA makes things happen in real-life not Rhino.
A robust collection of components that can create real-life parametric tensile membrane solutions (get some inspiration from FormFinder: useless because it’s academic but good to point the way). Membranes (and geodesics) are the future.
I could continue at infinitum but IMHO the big picture is worth 12345,67 “focused” GH improvements.
May the Force (the dark option) be with us all.
…
looked at autodesk simulation cfd 2015 and was optimistic because it had an export plugin from revit, which i use anyway for material takeoffs and etc, but found that it did not take solar radiation into account. This was a downer because I have heard that solar radiation could effect indoor airflow - convection - as much as 50 percent at a time.
Then I searched again and found that Hyperworks, a software by altair technology can be coupled with a radiation software. So I went through the trouble of obtaining an educational license of Hyperworks. However, though some email exchange I have found that the coupling is a one-way. The radiation analysis software was used, I think, for understanding the solar loading for a SOM project called church of light.
The support guy said : "Unfortunately our coupling with Hyperworks is really a one way coupling. We can accept H coefficients from their software in RadTherm, but they will not read in our wall temps. That said, it still can be a useful coupling in the sense that you can run the analysis in Hyperworks, send H coefficients to RadTherm, and run the analysis to better understand radiation and conduction. Most importantly, that analysis can be done for longer transient analysis, but will require much less compute time and resources."
Not only did I not understand what he means by the H coefficients, my wanting to get a CFD understanding coupled with solar radiation was again, unsatisfied. In the mean while I had to finish a presentation so I haven't had the time to try to get some result on the natural ventilation. I would probably need to look into how their solutions work before I can understand if their software would "do the job"
Thank you for letting me know about your work on this. I downloaded the Honeybee_Set EP Natural Ventilation component and made sure that it is allowed, but it does not show up in grasshopper.
You pointed out that "The component (and the corresponding equation) is mostly meant for cases where you have zones with windows that are NOT connected by an air wall (or a larger airflow network)." I wondered if you are suggesting it would be a code violation for zones to be connected by an air wall for fire safety reasons. It would be a violation I guess, like not putting an fiber insulation or some kind of smoke stop between Spandrel panels and the edge of a floor plate would be a code violation for a typical office building.
There is a project by kevin daly architects where you can see a section drawing with what seems like a cfd analysis (could be an illustration)
it was my initial visualization/simulation goals were for a facade design I am working on
1) an average air velocity across a zone at noon, for example, if a passive design strategy like this was used. for this I am guessing cfd is not entirely necessary. probably means that it could be used earlier in a design process, too. This would be more about user comfort.
2) at a later phase, like in detailing facade components, if airflow is indeed as expected for a zone that is connected to an air wall / chimney like feature (and to see if there is a proper mixing of air)
3) and a projection of energy savings, of course.
After seeing a video of simulation cfd I was optimistic, but like I said sim cfd does not take account of solar loading. I think I would probably go ahead start with one zone with sim cfd first, try three zones stacked on top of each other, then try hyperworks and try to factor in solar radiation.
For analyzing multiple zones on different levels, being able to add a chimney would be especially useful, I think. Having said that, I don't have a lot of experience of using honeybee except for the daylight component so it would take some time for me to understand the components.
I hope some of the information here is useful for you. after all, both sim cfd and hyperworks are commercial softwares and somewhat different than the e plus project you are working on, I guess but still trying to address a similar problem.
so.. in cased you missed it I was asking I downloaded the Honeybee_Set EP Natural Ventilation component and made sure that it is allowed and placed in the user object foler, but it does not show up in grasshopper. what could be the reason?
…