EP output variables are to calculate outdoorAirEnergy?
Thank you very much!
Output variables on the Read EP Results component:[1] totalThermalEnergy=cooling+heating[2] thermalEnergyBalance=cooling (-)andheating (+)[3] cooling= Zone Ideal Loads Supply Air Total Cooling Energy [J](Hourly)=Zone Ideal Loads Supply Air Sensible Cooling Energy [J](Hourly)+ Zone Ideal Loads Supply Air Latent Cooling Energy [J](Hourly)[4] heating= Zone Ideal Loads Supply Air Total Heating Energy [J](Hourly)= Zone Ideal Loads Supply Air Sensible Heating Energy [J](Hourly) + Zone Ideal Loads Supply Air Latent Heating Energy [J](Hourly)[5] electricLight=Zone Lights Electric Energy [J](Hourly)[6] electricEquip=Electric Equipment Electric Energy [J](Hourly)[7] peopleGains=Zone People Total Heating Energy [J](Hourly)[8] totalSolarGain=Zone Windows Total Transmitted Solar Radiation Energy[9] infiltrationEnergy=Zone Infiltration Total Heat Gain Energy (+)andZone Infiltration Total Heat Loss Energy (-)[10] outdoorAirEnergy= ???[11] natVentEnergy=Zone Ventilation Total Heat Gain Energy (+)andZone Ventilation Total Heat Loss Energy (-)[12] operativeTemperature=Zone Operative Temperature[13] airTemperature=Zone Mean Air Temperature[14] meanRadTemperature=Zone Mean Radiant Temperature[15] relativeHumidity=Zone Air Relative Humidity[16] airFlowVolume=[infiltrationFlow] Zone Infiltration Standard Density Volume Flow Rate+[natVentFlow] Zone Ventilation Standard Density Volume Flow Rate+[mechSysAirFlow] Zone Mechanical Ventilation Standard Density Volume Flow Rate+[earthTubeFlow] Earth Tube Air Flow Volume[17] airHeatGainRate=[surfaceAirGain] Zone Air Heat Balance Surface Convection Rate+[systemAirGain] Zone Air Heat Balance System Air Transfer Rate
Output variables on the Read EP Surface Results component:[1] surfaceIndoorTemp= Surface Inside Face Temperature[2] surfaceOutdoorTemp=Surface Outside Face Temperature[3] surfaceEnergyFlow=[opaqueEnergyFlow] Surface Average Face Conduction Heat Transfer Energy+[glazEnergyFlow] Surface Window Heat Gain Energy[4] opaqueEnergyFlow =Surface Average Face Conduction Heat Transfer Energy[5] glazEnergyFlow= Surface Window Heat Gain Energy[6] windowTotalSolarEnergy=Surface Window Transmitted Solar Radiation Energy[7] windowBeamEnergy=Surface Window Transmitted Beam Solar Radiation Energy[8] windowDiffEnergy=Surface Window Transmitted Diffuse Solar Radiation Energy[9] windowTransmissivity=Surface Window System Solar Transmittance…
ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009
and I here is what I have to share:
Thanks! Thank you for being awesome! When I released Ladybug two years ago I could never imagine how this project will take over my life! It has been such an invaluable experience for me so far and it wasn’t possible without you - so thank you so much.
What’s next? Recently I get this question more and more and here is my fairly long answer! Chris is pushing the boundaries with comfort tools. Chien Si is working on HVAC systems integration. Chris, Anton and Alejandra will figure out how to effectively get natural ventilation to be modeled. Patrick, Sandeep, Michal and Boris are working on their developments. I’m working on getting 3 Phase method integrated, and Butterfly will be out at some point, but... they are not going to be what makes the next step. The next step is up to you. It is what you will do with the development. So go ahead and let us know what’s next!
If you can help someone on the group please do! Doing so you are not only helping another person (and potentially yourself) but also the developers. The more you can help each other here the more we will have time for development and documentation.
Best place to send your questions is this group. If you are using the latest version from github then you may want to sent it to github. Please consider emails as the last option. Go back to number 3 again! Thanks.
Don’t be nice to us! Well, I mean don’t just be nice to us. I love your nice comments like anybody else and please keep them coming ;) but what we also need next to nice comments is your critiques, wishes and insight. I feel that recently we are getting less wishes and critiques than what it used to be. You can post them here in the group or on github and either way we will know about it. Thank you to all of you who has already done this.
Thanks again! Before I let you go I want to specially thank all of you who contributed to the project by your development, thoughts and support. You are great and I can’t thank you enough.
David Weinberger in his book “Too Big to Know” says: “When an expert network is functioning as its best, the smartest person in the room is the room itself.” Reading some of the discussions on the group gives me the feeling of staying inside a smart room. Thank you and let’s keep the room growing!
Cheers,
Mostapha
PS: To avoid sending another post, I just post the updates about the two upcoming workshops here:
I will lead a workshop in LA next Friday (Feb. 6) and there is still few seats left. If you want to learn more about energy and daylighting simulation with Honeybee here is your chance. Here is more information who to register: (http://www.facadesplus.com/technology-workshops/).
Chris will lead a 3 days intense and comprehensive Ladybug and Honeybee workshop in Mexico City this March. You have probably watched Chris’s tutorials and already know what you can expect from a workshop with Chris so I don’t have to speak for that! I would take this workshop if I was around that area. If you are around Mexico City or know a friend who might be interested please let them know. Here is more information about the workshop: (https://www.facebook.com/LadyBugforGrasshopper/photos/a.442320969114095.107084.413910668621792/919318878080966).
…
ipants from 12 countries to attend lectures and technical seminars furthering their understanding of digital design and fabrication in architecture. This year LaN extends the workshop with parallel intro sessions in all LAN ports–Barcelona / Boulder / Brooklyn / Bozeman (Aug 10-12). In 2009, you choose your modules.
Register Online
*please note, participants who have previously attended a LaN workshop automatically get a discount of total price.
Key Dates:
June 1, 2009: Workshop Launch - Applications Open @ 10% off price
June 19, 2009: Workshop Applications Open at 5% off
July 10, 2009: Applications open
August 7, 2009: Applications Closed
August 10-12, 2009: PHASE I - Modules [North America and Barcelona]
August 16-22, 2009: PHASE II - Modules [Barcelona @ IaaC / Institute for advanced architecture of Catalonia ]
August 24-30, 2009: PHASE III - Urban Drifts Workshop [Barcelona @ IaaC / Institute for advanced architecture of Catalonia]
*please note: all Rhino courses will be taught by a Rhino Certified Trainer
PHASE I: Aug 10-12
Phase I will be conducted in parallel in BARCELONA / BOULDER / BROOKLYN / BOZEMAN and are meant to familiarize participants with software and techniques. Phase I registration is inclusive of both module 1 & 2.
1. Rhino Introduction - 12hrs
2. RhinoFab: Rhino + Fabrication - 12hrs
PHASE II: Aug 17 - 22
Phase II modules will take place at the Institute for Advanced Architecture of Catalonia [IaaC] in Barcelona, Spain and will deal with scripting, parametric design and fabrication provided by FabLab BCN.
3. RhinoScript - 20hrs
4. Parametric Modelling in Rhino: Grasshopper - 20hrs
5. Introduction to Digital Fabrication - 20hrs
6. Machining Processes- 20hrs
PHASE III: Aug 24-30 ‘Urban Drifts’ Workshop - 40hrs
Register Online
Contact: bcn2@livearchitecture.net
More Information: http://www.livearchitecture.net…
, but at the lowest level computers only manipulate ones-and-zeros according to exact and unambiguous rules. As a result of this it is actually impossible to generate true random numbers using a computer. Computers use algorithms that create sequences of pseudo random numbers, numbers that appear to be random, but in fact are created by the application of a deterministic algorithm.
One of the major benefits of pseudo random numbers over actual random numbers is that it's easy to reproduce a sequence of numbers. If you generate the first 50 numbers in the pseudo-random sequence with seed=5 they will be exactly the same as when you did it last week. If you want different random numbers, you have to use a different seed. In Grasshopper I thought it important that the same random numbers are always generated, as that minimizes the 'surprise'. However, since the default numbers might not be to your liking, you can always play around with the seed value until you find a pseudo random sequence that suits you.
If you generate 8 random numbers between 1 and 10, you might get a sequence like this:
{5, 8, 2, 4, 2, 7, 3, 10}
The pseudo random number generator guarantees that the spread of the numbers in the sequence is equal everywhere, but only when you generate an infinite amount of numbers. Since every sequence you care to generate in one human lifetime will not be infinite, there will always be some 'clumping' of values. A small stretch along the number line that is somewhat more densely populated by random numbers than the adjacent stretch.
There is also absolutely no guarantee that you won't get the same number more than once. Obviously this is impossible if you were to generate 50 values between 1 and 10 (there are only 10 possible unique numbers), but even if you generate only 2 values between 1 and 10 you might still get the same number twice.
Indeed in my example above the value 2 occurs twice, whereas the value 1 doesn't occur at all. If you want a range of numbers without overlaps, it's better to not use the Random component, but instead generate all the numbers using a Range or Series component and then Jitter the list, thus randomizing the order of the values, but not the values themselves.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
rder to deal with the contents of the MERO structure (like glass, panels, polycarbonate). That is what the C# does already.
3. Vectors (a la "Umbrella" sticks) in order to place correctly your MERO nodes (the "hexagon" brackets - so to speak). That is what the big C# (the one that I've send to you some time ago) does already.
4. Calculations (lengths, angles) for each node against the other related nodes and the points derived from dividing the MERO square "tubes". For a given node these points are variable (from 2 [when in the "bounds" of mesh] to 6 ["typical" middle point, so to speak].
5. Demo block instances in order to see first hand what GH can actually do (that's WOW stuff: you slide a slider and "several" real-life components are placed in 3d space in real-time, he he).
6. Node connectivity data for the obvious (assembling the MERO on site).
7. Some assembly "simulation" capability (we do this today and this tomorrow ...)
So forget the single carrot (plenty carrots for you soon) for a while and answer to the most critical question: Based on what you've displayed to me (Skype) what is your policy against the MERO node itself?
I mean: we don't deal with a classic MERO ball type here (meaning variable drilling axis per ball). Meaning that the "hexagon" bracket (if I may use the term) IS VARIABLE. Meaning: you need a "module" that can being adapted against "every" possible (logical) angle value? (and compose the bracket?) Or you gonna fabricate the "brackets" on a per node basis?
And what if we had a planar glazing system? (same principle, more expensive, 100 times more WOW).
BTW: The best man in the world to do "similar things" with "hinged" custom aluminum systems (like doing the blue facade that you've displayed to me with some semi structural/structural system) he's a very close friend of mine. He's based in Dubai UAE.…
rder in which these polylines are drawn is not important (correct me if this is not the case).
2. We explode the polylines. This outputs all the line segments and all the endpoints (both groups with duplicates inside them). So we have 204 lines (including duplicates) and 246 points (including duplicates). We flatten both outputs in order to get 2 simple lists.
3. We use [dupPt] to remove all duplicates from the points list. So we get a list of all the nodes with each node contained one time, so we have 108 points.
3a. We can use [pointList] to display the index of each node on screen.
4. For each line segment we find the 2 endpoints and put them together in a list. So we have 204 lists with 2 points each. (We graft the list of lines so that the endpoints of each one will be in a different branch/list)
5. We use [closestPoint] and so for each endpoint we get the index number of the corresponding node. So we have 204 lists with 2 indices each.
6. We get each couple of indices and join them as text with a comma separator. (We flatten the data so that we have a single list with 204 texts)
7. BUT some of these 204 texts are duplicates (because they originate from duplicate lines), so we use [cSet] which returns the unique values from a list. So we end up with a list of 180 texts (one for each unique line). Instead of using [cSet] you could also eliminate duplicate lines using kangaroo's [dupLn] (which is the equivalent of [dupPt] but for lines) before step 4.
Hope it is more clear like this. I am not sure I understand what you mean by "But they are not connected in the order to form the tessellation.". If you still have problems with the definition please explain this a little better.
cheers, Nikos
…
ate):
1) go to: https://github.com/mostaphaRoudsari/ladybug/2) click on "clone or download"/Download ZIP
3) Download and extract the folder wherever you want on your machine
4) Open the folder and open "userObjects"
5) you'll see something like this
6) open Grasshopper/File/Special Folders/User Object Folder
7) Select and delete all Ladybug components
8) Drag all components of the point 5) into the canvas of Grasshopper wherever you want or inside the "User Object Folder"... it is the same thing.
And it should be fine.
Let me know if it works.
Best
Antonello
…
requiredKeys_ input of the "OSM Shapes" component. This is not the source of your problem though, but still I mentioned it in case you solve your issue, and afterwards want to use the "OSM Shapes" component.
The current (Win32Exception): WindowsError is the very same error message that you reported back in February.For some reason, your Windows is not allowing the Gismo "OSM Shapes" component to delete C:\MapWinGIS_installation_folder\gdal-data\osmconf.ini file.
You previously solved it by allowing the full access control to it, so I am not sure why it is not working now.Windows 10 seems to be the most overprotected operating system among other Windows versions, at least judging by the questions people asked so far.
Maybe you can try to turn off all the services which prevent users from changing certain files, like UAC or maybe even your antivirus?
Try this:
1) Close your Grasshopper and Rhino.2) Restart your PC3) When it boots up again, in your Start menu's search box type: "UAC". Click on it, and a new User Account Control Settings window will open. Set the bar on the left to "Never notify".4) Completely turn off your Antivirus.5) Check once again if your access control to the C:\MapWinGIS_installation_folder\gdal-data\osmconf.ini file is still set to the values you previously reported in this post.6) Right-click on "Rhino 5" icon and then choose: "Run as administrator".7) When Rhino boots up, run Grasshopper, and open the newest create_3dbuildings_trees_streets.gh file from here.If none of this helps, maybe you have some other application which deals with access to files on your system? Malware removal application or similar? Try turning it off too.…
Added by djordje to Gismo at 9:10am on April 3, 2017