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
…
ives that have been shared so far.
Intersect Shouldn't Punt When Encountering Areas of Intersection
Several posts talk about how Booleans are really just shortcut implementations of the Intersect/Trim/Split/Join (ITSJ) design pattern. Agreed. I realized this when trying to understand and resolve my first Boolean related problem. So when I broken down my characterization to the 4 component steps, I found is that it was the Intersect operation that was generating an erroneous (read: incomplete) set of intersection curves. I posted my findings along with a possible solution in an email to McNeel tech support and in this Rhino discussion an edited version of which I’ve quoted again below. But the only response I received from McNeel was that I shouldn't expect any changes in the product that improves Booleans.
The unexpected behavior I've been having with Rhino, and by extension Grasshopper, is that the current implementation of the Rhino Intersect command is generating an incomplete network of curves when given 2 surfaces having regions that are (almost) coincident. When Intersect determines that there's no single curve able to represent the intersection in those areas, but rather an area of intersection, Intersect erroneously doesn't generate any curve to represent that portion of the intersection — which is mathematically incorrect. This decision to "punt" in these situations renders the generated results to not be useful for subsequent steps of the ITSJ design pattern. Rather than not including these areas of intersection in the network of curves, Intersect should generate any non-kinky, non-looping curve(s) through a region of intersection that connects with all other intersection curves adjacent to the region. Any valid curve is far more useful — and mathematically correct — than no curve through these regions.
Informative and Detailed Error Reporting Will Save Users’ Time
A number of users feel as I do that the error information available when an operation fails is insufficient.
The Rhino Learning Curve Is Fractally Steep
While some responses have suggested that I’m just too new to Rhino, a number of long-time Rhino users have said that they are continually “learning” the product's idiosyncrasies, and expect that they will never really know what the product will do every time. What they’ve learned from their years of experience is how to hack their designs to work around Rhino’s quirks.
I conclude from these stories that, sure, I’m green, but that I, all of us, are destine to be forever “green” because the current development methodology results in a product that can never really be understood.
Wow.
In his reply above @Paul N Jeffies said…
One thing that's important to understand when using Rhino for this kind of thing is that Rhino does not have a particularly meaningful conception of a 'solid object' - solids are defined simply as a collection of (infinitely thin) NURBS surfaces joined together with no gaps between. That's part of the reason for the problems with booleans in Rhino, but it also means that you don't really need boolean operations since you can do everything by exploding the polysurface and using the Intersect/Trim/Split commands on the individual surfaces to build up the boundary surfaces you want, then rejoin into a solid afterwards.
As a software architect with ~40 years of tech experience, I would again suggest that the root cause of the product's unknowability is the lack of rigor so far exhibited in defining the layers of abstraction. If proper rigor were applied, then, from a user’s perspective, a solid really would be a solid. The proper way to reduce a solid to a set of adjacent surfaces would be to use a function like ExplodeSolid, and to get a set of curves from a surface we would have to use ExplodeSurface, and so on. So rigor doesn’t prohibit users from pulling back the curtain, but rather empowers the core development team to enforce encapsulation at the current layer of abstraction — whether point, curve, surface, solid, or whatever.
The Solution Begins With Changing The Conversation
With all this said, I don’t believe that Rhino is fatally flawed or impossible to fix. I also don't believe that the resulting loss of productivity is the users' fault. I do believe though that the first step is for all, McNeel and users, to name the condition, raise this as a high priority, work collaboratively to define a corrected abstraction stack, and add appropriate rigor to the implementation of the next major release.
About a month ago I spent about 1/2 hour searching through the Rhino discussions for topics related to The Boolean Problem. I found literally 100's of posting, with many noops like I am now saying they were giving up and going to another tool because Rhino’s learning curve was too steep. Yes, filleting and trimming are two other big Rhino problems that I believe have similar roots. Yet I wonder whether these deep-seated challenges could, in fact, be overcome — by first changing the conversation.
I’d again ask what other, more experienced users think.
- Bob…
Added by neobobkrause at 2:49pm on October 4, 2016
occur more than once in the same list, and different elements with identical values can occur more than once. Also, a list may contain lack of elements, referred to as "nulls".
Sets. Strictly speaking a Set is a mathematical construct which adheres to a strict collection of rules and limitations. Basically, a Set is the same as a List, with the exception that it cannot contain the same element more than once, or indeed two or more different elements with the same values. You see, in mathematics there is no difference between a value and an instance of that value, they are the same thing. In programming however it is possible to store the number 7 in more than one spot in the RAM. Grasshopper does not enforce this rule very strongly though, you can use a lot of Set components on lists that have multiple occurrences of the same value. The big difference between Lists and Sets in Grasshopper is that Sets are only defined for simple data types that have trivial equality comparisons. Basically: booleans, integers, numbers, complex numbers, strings, points, vectors, colours and intervals. Lists can contain all kinds of data.
Strings. Strings are text. There's nothing more to it. I don't know why early programmers chose to call them strings, but I suppose it's a better description of the memory representation of them. Strings are essentially sequences of individual characters.
Trees. Trees are the way all data is stored in Grasshopper. Even when you only have a single item, it will still be stored in a tree. A tree is a sorted collection of lists, where each list is identified by a path. A specific path can only occur once in a tree, when you merge two trees together, lists with identical paths are appended to each other. Trees are an attempt to losslessly represent not just the data itself, but also the history of that data. Imagine you have 4 curves {A,B,C,D} and you divide each into 3 points {X,Y,Z}. Then, for each of those points you create a new line segment {X',Y',Z'} and then divide each of those line segments again into 5 points each {K,L,M,N,O}. The way data is stored in trees, it should be possible to figure out whether a point M belongs to X' or to Z', and whether that X' or Z' came from A, B, C or D. This is why paths are often quite long after a while, because they encode a lot of history.
Paths. A Path is nothing more than a list of integers. It's denoted using curly brackets and semi-colons: {A;B;...;Z}. A Path should never be empty {} or have negative integers {0;-1}, but it is certainly possible to create a path like this and it probably won't even crash Grasshopper. Paths are 'grown' by components that (potentially) create more than one output value for a single input value. For example Divide Curve. It creates N points for every single input curve. In cases like this a new integer is appended to the end of the path.
In the next release the Path logic in Grasshopper is somewhat different. I fixed a number of obscure bugs (hopefully without introducing new fresh bugs) and special cased certain operations to somewhat reduce the speed at which paths grow. This may well break files that rely on a specific tree layout, but I hope the temporary sacrifice will be worth the long-term benefits.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
si à faire le tri avec Grasshopper et l'outil Points in Brep, comme je pensais. Je suis passé d'environ 400 000 points à uniquement 20 000 points autour de mes 3 rails. C'est très efficace (mais un peu dangereux avec tous ces points).
J'ai interdit au composant CircleFit de faire un cercle, s'il n'y a pas au moins 5 points présents sur la section. Car lorsqu'il y a seulement 3 ou 4 points, il suffit qu'il y en ait un pour que le cercle soit faux, alors qu'au delà, le cercle a plus de chance d'être "bon".
J'ai également créé des "Pipe" (créés à partir de portions de l'axe) au lieu des "Box » de sélection des points pour éviter de sélection trop de points que ne serait pas des points du rail.
J'ai ensuite créé des « panel » pour la moyenne des distances en X et en Y et la moyenne des distances centre à centre.
Tout cela fonctionne bien avec un axe et un tuyau. Mais maintenant j'essaie d'appliquer ça à plusieurs rails en même temps. Je crois avoir compris qu'il faut créer des « path » dans l'imput manager, et faire correspondre le « path » de l'axe et celui du Tuyau.
Dans mon exemple j’ai mis 3 courbes et 21 sections. Au moment où j'utilise les boîtes pour créer les portions des axes, il crée 63 « sous-path » de 1 courbe alors qu'il faudrait qu'il crée 3 "paths" de 21 courbes, enfin si j'ai bien compris.
Car une fois qu’il a créé les points à l’intérieur des « Pipe », il doit les projeter sur les plans correspondant. Et c’est là que le problème se voit. Il ne fait pas correspondre les points à projeter et les plans.
Je vous envoie la version à une courbe et un tuyau (c’est la v5 avec un fichier rhino ou la courbe d'axe est "bakée" pour pouvoir faire un zoom sur la zone plus rapidement) et je vous envoie également, celle avec 3 courbes et 3 tuyaux. Sachant qu’il faudra également attribuer un rayon pour un des tuyaux et un autre rayon pour les deux autres.
Tout ça est bien compliqué, j’espère que je ne vous embête pas trop.
Merci d’avance.…
g "ipy" form the CMD line.
Now what is Numpy good for I wonder? I hear it does big arrays quickly. And do I also have Scipy? Is that a bonafide package? Alas, "import scipy" gives an error:
C:\Users\Nik>ipy
IronPython 2.7 (2.7.0.40) on .NET 4.0.30319.34209
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import scipy
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\scipy\__init__.p
y", line 124, in <module>
File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\numpy\_import_to
ols.py", line 15, in __init__
AttributeError: 'module' object has no attribute '_getframe'
>>>
...and again the rabbit hole is even deeper now. The directory and contents checks out fine except there is no "_import_to" like there is "__init__.py".
So where is Scipy? How do I activate/install it for real?
The above mentioned test gives no error, however:
ipy -X:Frames -c "import scipy"
...yet the same import from within IronPython does give an error.
…
Added by Nik Willmore at 3:06pm on October 11, 2015
ed to? --> probably the globalHorizontalRadiation but how?
You are right. Kglob is Global horizontal radiation from the .epw file, in W/m2.hSl is the sun elevation angle in degrees.
Do you agree that in this case the MRT does not depend on these inputs: location, meanRadiantTemperature, dewPointTemperature and wind speed?
It depends on location, as location determines the sun vector's elevation, zenith and azimuth angles.It does not depend on meanRadiantTemperature, dewPointTemperature and windSpeed.
It does not depend neither on the other bodyCharacteristics like bodyPosture, age, sex, met, activityDuration...?
I think you are correct. It is based on the following assumptions:sex_: malebodyPosture_: standingmetabolicRate_: 2.32 mets (walking 4km/h)
MRT calculated by the TCI-11 method is the mean radiant temperature of a vector pointing vertically with a sky view factor of 100%?
The sun vector depends on the sun elevation angle.If "Sunpath shading" component is not used to account for shading, then yes, the sky view factor of 1 (100%) is used.
It can also be applied to a mannequin thanks to the CumSkyMatrix and thus evaluate the dishomogeneity of radiation exposure.
Yes, the MRT in Thermal Comfort Indices component, threats the subject as a single uniform body. Outdoor Solar Adjusted Temperature Calculator component's feature of being able to evaluate different parts of the body is indeed impressive.
In contrast to the TCI-11, this component distinguishes diffuse and direct radiation and contextualizes the calculation thanks to _ContextShading input, right?
MRT in Thermal Comfort Indices component is based on Man-Environment Heat Exchange Model 2005 by Krzysztof Blazejczyk, one of the authors of UTCI index. MRT MENEX 2005 model has 4 version of solar radiation accounting. I am using the one with global solar radiation. The reason is because it cooperates well with other indices in the component, those that require solar radiation as an input.I implemented the MRT MENEX 2005 version which separatelly takes into account the direct, diffuse and reflected radiation in the attached file below.You can read more about the MRT and the whole MENEX 2005 model in general in the .pdf paper attached below.
The default groundReflectivity is set to 0.25 --> is GroundReflectivity taken into account in the Tground or MRT calculation in the TCI component? If yes, what is the hypothesised groundReflectivity?
The MENEX 2005 model does not provide this information, but I assume that it's possibly 0.2 - 0.25 as you said, which is widely used as urban/suburban default annual average albedo value.
The default clothing albedo of 37% (TCI-11 bodyCharacteristics) corresponds to Clothing Absorptivity of 63%?
You are correct again.
Why such a big difference and which of the result should be plugged into the UTCI calculation component?
This is a complex question.One of the reasons might be the fact that MENEX MRT version is using a simplified formula to calculate the ground temperature, which may significantly affect the final results. It could be beneficial if groundTemperature_ is set as an input.Another reason why this might be is that the study which corrects the Mrt for the influence of local heating of the sunlit parts of the floor, is meant to be used for indoor analysis.It should be said that a number of outdoor indices have been derived from indoor indices and studies, but with edition of its parameters.In this case we are simply applying the same indoor formulas to outdoor analysis. The study itself does not provide any suggestion that this kind of approach may be valid.…
't have time to take on this project but hacked a few bits together that might get you started; enough to see that you're in a world of pain here when it comes to data trees!
To start with, it looks like the code that generates the second set of curves (tangents) is identical to the first except for one extra component? So I disabled the duplicate code and rewired it like this:
Then I noticed that the second point in your desired curve (red arrow below) has not been determined in the GH, either by intersection points or other means. So for now, I skipped that point:
The code on the right (below) is what I added to organize the points to make your curves. Notice the use of 'Merge' before 'MCX'; the results depend on which set of curves is 'A' vs. 'B'.
The result is not too bad (minus that one point in each curve) but there are anomalies in the data that create problems and I don't have time to figure it all out. Sorry.
One of the problems is visible in the panel below, showing the output from 'Weave'. There are 26 curves (0 to 25) and this data is pretty good up through path "{0;0;25;0}". You could either figure out why there is more data than you want, or just ignore (somehow) the rest of the 50 paths/branches in this data tree.
Another problem is that the four points in each branch/path (five when you add the missing point) are in proper sequence for all branches except {0;0;0;0}. Again, you could figure out why or just sort the points by their distance from the center point, as I did.
Sorting is probably better as it would make it easy to merge that second point... OK, I'll add and merge that missing point, and trim the tree. Oops, I did it again. OCD is a terrible thing!
There is still a problem though - curves/pipes 0 through 4 are messed up. See yellow arrows. Well, 21 out of 26 isn't bad, eh?
I REALLY need to step away from this keyboard! I left my 'Tree/List Viewer' tool in the code as it might be useful (it is to me). Good luck.…
Added by Joseph Oster at 12:47pm on March 21, 2017
mers considering extreme sports reject mainstream retailers and like to check out small stores rather of at chains plus malls. Several smaller retailers discuss trends in sports shoe sales. http://skateszone.com/
Though athletic shoes and sports stores and from doorways retailers have reported somewhat uptick in footwear sales due to the increase in extreme sports, the particular beneficiaries inside the trend are independent surf and skate niche stores.
Some West Coast surf and skate shops stated teenagers and even more youthful Generation Xers are not only rejecting traditional sports, but they're also shunning mainstream retailers and malls meant for smaller niche shops transporting hard-to-come-by brands.
Eddie Miyoshi, district manager at Atomic Garage, a 3-store chain situated in Gardena, Calif., stated the soaring recognition of skateboard footwear has boosted the retailer's total footwear business 20-thirty percent this year, rather of '95.
Skate footwear presently represent 80-90 % of Atomic Garage's shoe sales, while couple of years back, Dr. Martens and Timberland drove the retailer's footwear business.
Like many retailers, Miyoshi pointed to Airwalk since the trend's catalyst.
However, if Airwalk broadened its distribution to larger chains, which are frequently located in malls, only a few skate shoe customers adopted. Rather, many youthful males have switched for your skate shops for additional elusive brands like Etnies, Duffs, and Electricity Footwear by Circus. By refusing to market bigger retailers or sports stores, these brands are increasing their cachet among youthful consumers.
"Kids don't want stuff which have been within the shops,In . Miyoshi added.
Searching ahead, Miyoshi forecasted skate shoe sales will remain strong through spring '97 provided "the [hot] vendors don't auction other [non-particularly shop] retailers."
"Skaters and non-skaters are rebelling against mainstream retailers so on to surf and skate shops for many looks," echoed Mark Richards, co-online sources Val Surf, a 3-store chain situated in North Hollywood, Calif. Soaring sales of skate footwear have driven total footwear receipts up 25 percent this year rather of '95.
"The quantity of that increase might be connected while using exposure of maximum games? I am unsure. [Skate footwear] may also be actually the think about the moment,In . Richards acknowledged. And in relation to getting this right look, youthful customers can be very picky.
"Skateboard footwear is a huge category for people, but we're not able to own the brands, Etnies, Duffs, Electricity and Nice, simply because they won't sell us," stated Mark Anderson, buyer at Chick's Sports, a six-store chain in Covina, Calif. "We have people coming every single day requesting them." Consequently, skate footwear have consistently ongoing to obtain about 5 % of Chick's overall footwear business. http://skateszone.com/the-top-8-best-skateboards-for-beginners-reviews-2017/
Nonetheless, some outdoors, niche sports and sports retailers are noting the growing recognition and coverage of maximum sports will receive a modest impact on footwear sales. Trailrunning footwear and approach/outdoors crosstrainers will be the two groups benefiting the very best inside the recognition. Like the skate shoe business, some retailers realize that styling instead of function frequently drives sales of individuals footwear.
"At this time the merchandise is a lot more visual than function," stated Chet James, gm of Super Jock 'N Jill, Dallas, speaking about trailrunning footwear. Still, James noted the current hype over adventure sports helps draw more customer traffic. "The marketing campaigns and media help bring growing figures of people in, nonetheless they frequently occasions day an issue that increases results on their own account,Inch he conceded.
John Wilkinson, executive vp inside the 85-store chain Track 'N Trail, Eldorado Hillsides, Calif., stated the shop has "seen some activity in approach footwear," but he requested the amount of consumers depend in it commercially sport. And, instead of accelerating total footwear business, Wilkinson speculated elevated sales of approach footwear and trailrunners are gnawing away at traditional hiking shoe and boot volume.
But Dan Bazinet, president of Overland Exchanging, a 34-store chain situated in Westford, Mass., believes the company-new looks have breathed existence for the wilting hiking boot category. "[Approach-type footwear] don't represent the lion's participate the hiking market, nonetheless they have elevated the hiking business and provided us extra sales," Bazinet stated.
He designated Timberland's Treeline Series and Rockport's Leadville line as strong performers. Unsurprisingly, he noted the company-new looks are attractive to youthful consumer base than traditional hikers.
For that month of June, sales of men's hikers were up 49 percent at Overland, rather of June '95, while sales of women's hikers were up 17 % for that month. Bazinet also attributed elevated sales that shops walked inside the hiking business, departing that business for that specialists.
Some retailers draw a good example concerning the hiking boom of two yrs ago combined with the current extreme sport phenomenon. "Plenty of bigger chains will get a specific percent in the industry while [extreme] sports remain a fad because they are selling cost-point type gear," described Steven Carre, assistant hard goods buyer at Adventure 16, a six-store chain situated in Hillcrest.
"However individuals [true enthusiasts] will say `we need real gear' and may shown up at us. That will help us after a while. What Size Skateboard good for an 3 4 5 6 7 8 9 10 11 12 13 14 year old
…
option, after downloading check if .ghuser files are blocked (right click -> "Properties" and select "Unblock"). Then paste them in File->Special Folders->User Object Folder. You can download the example files from here. They act in similar way, Ladybug Photovoltaics components do: we pick a surface, and get an answer to a question: "How much thermal energy, for a certain number of persons can my roof, building facade... generate if I would populate them with Solar Water Heating collectors"? This information can then be used to cover domestic hot water, space heating or space cooling loads:
Components enable setting specific details of the system, or using simplified ones. They cover analysis of domestic hot water load, final performance of the SWH system, its embodied energy, energy value, consumption, emissions... And finding optimal system and storage size. By Dr. Chengchu Yan and Djordje Spasic, with invaluable support of Dr. Willian Beckman, Dr. Jason M. Keith, Jeff Maguire, Nicolas DiOrio, Niraj Palsule, Sargon George Ishaya and Craig Christensen. Hope you will enjoy using the components! References: 1) Calculation of delivered energy: Solar Engineering of Thermal Processes, John Wiley and Sons, J. Duffie, W. Beckman, 4th ed., 2013. Technical Manual for the SAM Solar Water Heating Model, NREL, N. DiOrio, C. Christensen, J. Burch, A. Dobos, 2014. A simplified method for optimal design of solar water heating systems based on life-cycle energy analysis, Renewable Energy journal, Yan, Wang, Ma, Shi, Vol 74, Feb 2015
2) Domestic hot water load: Modeling patterns of hot water use in households, Ernest Orlando Lawrence Berkeley National Laboratory; Lutz, Liu, McMahon, Dunham, Shown, McGrue; Nov 1996. ASHRAE 2003 Applications Handbook (SI), Chapter 49, Service water heating
3) Mains water temperature Residential alternative calculation method reference manual, California energy commission, June 2013. Development of an Energy Savings Benchmark for All Residential End-Uses, NREL, August 2004. Solar water heating project analysis chapter, Minister of Natural Resources Canada, 2004.
4) Pipe diameters and pump power: Planning & Installing Solar Thermal Systems, Earthscan, 2nd edition
5) Sun postion and POA irradiance, the same as for Ladybug Photovoltaics (Michalsky (1988), diffuse irradiance by Perez (1990), ground reflected irradiance by Liu, Jordan (1963))
6) Optimal system and storage tank size: A simplified method for optimal design of solar water heating systems based on life-cycle energy analysis, Renewable Energy journal, Yan, Wang, Ma, Shi, Vol 74, Feb 2015.…
he example file to this file so you can give it a try with any version of Honeybee that you're already using. The only requirement is to have OpenStudio installed as the component is using OpenStudio libraries to parse gbXML files. If you're using the latest version available on github the component is also available under WIP tab.
Why?
The main purpose of developing this component is to save time and effort for importing Revit models for energy and daylight analysis. It bothers me to see a lot of smart people spend a lot of time to just come up with solutions just to get the geometry from Revit to Honeybee for analysis. This component is not solving all the issue but is a first step forward. In an ideal world, the future version of Honeybee, which works both under DynamoBIM and Grasshopper should address this issue but that can take some time to be fully ready!
How?
To use this component you need to Export your Revit model as gbXML and then use the file path to load the file into Grasshopper. There are several resources available online on how to prepare the analytical model in Revit and export the gbXML file. Here is an image for importing the Revit 2017 sample model using the default settings. As you can see the model will be just as good as what your original gbXML file from Revit is.
What can be improved?
Well, there are several items that can be improved and they are mostly not on us. To get it started I add what I think are the 3 main shortcomings and my thoughts on how they can be addressed in the future. Feel free to add what you think needs to be added to this list in the comments section.
1. Revit analytical models and as the results gbXML files, by design, are not intended to be clean. Watch this presentation from the Autodesk University to see the logic behind this approach which in short is it doesn't matter for a large scale early stage energy model. Well, This will be quite a problem for studies that you can do with Honeybee. Included but not limited to daylight and comfort analysis.
The best solution that I can think of, until Autodesk fixes their exporter, is to use Revit Rooms and Spaces and generate a clean model from the scratch. We have already tried this approach in Revit but since the Revit API doesn't provide access to Room openings we had a very hard time to get it to work.
That's why that I opened an idea on Revit ideas to get over this issue. With your support we already have 81 votes, but it hasn't been enough to make them to consider the idea for an official review. If you haven't voted already and you think this will be a helpful feature take a moment and vote so we can have it implemented at some point in the future.
2. There is no way (that I know) to export only part of the model. The way export gbXML is set up in Revit is to export the whole model once together. As a result, if you have a huge model with 100 rooms and you want to get one of the rooms into Honeybee using this component you have to export the whole model, which can take some time, and then import them all back into Grasshopper. To partially address this issue I added an input to the component that allows you input a list of names for rooms that you're interested to be loaded into Grasshopper. You can use the name of the room/space in Revit as an input for the component.
3. The component doesn't import adjacencies, loads, schedules and HVAC systems. I wasn't able to export a gbXML file from Revit with any of this data except for the adjacency, but even if you can do that, the component currently can only import geometries and constructions. I hope we get access to 1 and so we don't have to use the xml file approach at all, but if that takes a very long time then we will add these features to the component.
Happy 2017!
Mostapha…