TB of RAM. I think I'm going to start a GoFundMe campaign to buy one for myself :)
2- The server's cost is about $13 an hour. I get free access to supercomputer through my university and xsede.org because I earned an NSF Honorable mention last March, however, the supercomputers available through both resources are a little complicated for me to use, as opposed to the one available from amazon that has Microsoft server 2012 already installed.
3- I wanted to run 400 annual glare simulations for 400 different views.
4- I tried a to perform annual glare simulation for one view on my Dell XPS that has Intel Core i7-6700HQ processor and 16GB of system memory. The simulation took 2 hours to complete. Radiance parameter ab was set to 6.
5- I wanted to obtain the batch file for each view so I can run them on the server. So I used the fly component to run all 400 simulations and closed the cmd windows, that wasn't bad ( for me at least) because I asked my son to this job for me, he was just glad to help me :)
6- I created one batch file using this cmd command:
dir /s /b *.bat > runall.bat
This created a file with the path to each .bat file. I edited this file in Notepad++ to include the word "start" at the beginning of each line. This was done using the "find and replace" dialogue box.
7- I split my newly created batch file into 3 batch files, each one has about 130 file names and " start" before the file names.
8- installed radiance on my server
9- Ran the first batch file on the server, this started 130 cmd windows performing my simulations, CPU usage was anywhere between 90% to 100% and about 105 GB of RAMs were used.
10. It took about 5 hours to complete all 130 simulations, I expected to run all in 2 hours but can't complain because this would've taken about 260 hours to run on my laptop. After the simulations done I ran the second and then the third batch files ( total of about 15 hours).
11. I got 400 valid dgb files. Couldn't be happier!
…
he time to work with it.
the project is about facade strips which turns along height. the top angle is
parallel to the facade and the bottom is max. 90 degrees twisted, but the strips
should turn diffrently to achieve more dinamic look.
first i have tried to achieve this by calculating distance between the rotation angle from points of the grid and a single point.
then i have tried to ad some more effecting points and used the distance to the divided surface (the circles are just to control the area of effection):
i manually lofted it.
the result is a bit annoying becouse the points that effect the angle are always visible:
i have triend to solve this by drawing a line and divided it to recieve points along the bottom of the geometry. the result is not working properly:
Anyway,
there must be a better/smoother way to achieve this. i would like to effect the twist of the surfaces by distance to a spline, but im just lost. can you help me please?
the problems im encountering:
0- distance spline to grid to effect the angle
1- list of x/y coordinates and angle of rotation for each point of the grid
2- export points to excel
3- lofting lines in one direction only (x1, x2, x3...)
4- reduce the list data to 2 decimal (0,00)
5- maybe angle from radian to degrees
thx…
answer further on Friday.
The "ghdoc" variable and rhinoscriptsyntaxThe ghdoc variable is provided by the component if you select it as "target".You might ask yourself: "why do we need it"?Its use comes from the very design of the established RhinoScript library. This library is imperative, which means it is build from a set of procedures or functions that act on various geometrical types. Additionally, there is one level of indirection: most of the time, the user does not work with the geometry itself in the variable, but rather with Guid of geometry that is present in a document. This is exactly what ghdoc is: it is the document that the RhinoScript library always implicitly targets with all AddSomething() calls (for example, AddLine()).
Based on this comment...RhinoScript use within GhPython may be less idealThat comment is from a previous version of this component that did not have the ghdoc yet.With the ghdoc variable, the standard Rhino document target of RhinoScript is replaced, therefore we can use Grasshopper while leaving the Rhino document unchanged. This saves uncountable Undo's, and makes it easy to structure ideas through the definition graph
...is the rhinoscriptsyntax target irrelevant if using solely RhinoCommon classesYes. If you create class instances (objects), you will need to create also your own collection objects to store them (mostly lists, trees). You can imagine the ghdoc as being an alternative to them, just that you do not access data by index (number), but by Guid. So you can use the RhinoScript or the RhinoCommon libraries independently or mix them. The RhinoScript implementation in Rhino is open-source and is all written in RhinoCommon. Also the ghdoc implementation is open-source, and is here.
RhinoScript and/or RhinoCommon objects which are not recognized as valid Grasshopper geometryYes, sure, Grasshopper handles only a portion of all available types. Basically, unhandled types are all the types that do not exists in the 'Params' tab. For example, there is no textdot and no leader, so on line 149 there is a throw statement and all TextDot calls (about line 350) are commented out. When/if Grasshopper one day will support these types, these calls will be implemented.
DataTreeHere is a small sample. However, I think that 80% of the times it is not necessary to program for DataTrees, as the logic itself can be applied per-list and Grasshopper handles list-iteration.
I hope this helps,
- Giulio_______________giulio@mcneel.comMcNeel Europe…
ger at the scale of rooms, walls and atria, but that of cells, grains and vapour droplets. Rather than the flow of people, services, or construction schedules, the focus becomes the flow of light, vapour, molecular vibrations and growth schedules: design from the inside out.
The sg2012 challenge, Material Intensities, is intended to dissolve our notion of the built environment as inert constructions enclosing physically sealed spaces. Spaces and boundaries are abundant with vibration, fluctuating intensities, shifting gradients and flows. The materials that define them are in a continual state of becoming: a dance of energy and information.Material potential is defined by multiple properties: acoustical, chemical, electrical, environmental, magnetic, manufacturing, mechanical, optical, radiological, sensorial, and thermal. The challenge for sg2012 Material Intensities is to consider material economy when creating environments, micro-climates and contexts congenial for social interaction, activities and organisation. This challenge calls for design innovation and dialogue between disciplines and responsibilities.sg2010 Working Prototypes strove to emancipate digital design from the hard drive by moving from the virtual to the actual in wrestling with the tangible world of physical fabrication. sg2011 Building the Invisible focused on informing digital design with real world data. sg2012 Material Intensities strives to energise our digital prototypes and infuse them with material behaviour. They have the potential to become rich simulations informed by the material dynamics, chemical composition, energy flows, force fields and environmental conditions that feed back into the design process.
More information can be found at http://www.smartgeometry.org
sg2012 take place at Rensselaer Polytechnic Institute, Troy, in upstate New York from 19-24 March 2012. The Workshop and Conference will be a gathering of the global community of innovators and pioneers in the fields of architecture, design and engineering.
The event will be in two parts, a four day Workshop 19-22 March, and a public conference beginning with Talkshop 23 March, followed by a Symposium 24 March. The event follows the format of the highly successful preceding events sg2010 Barcelona and sg2011 Copenhagen.…
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
…
te some cut sheets, but not to optmize material, rather define some cut lines. Everything that I am cutting is made of planar wood elements, but there are very specific geometries (mostly straight lines) and I have to put tolerances and radiasas at the corners in order to cut on the cnc mill. Spending time to figure out how to automate is necessary, but I am stuck!
One thing the definition is doing is taking my brep modeled components in rhino and makking them into 2d close curves and laying them side by side. It works...not ideal as its not layed out in a sheet, but that is not the most important part.
Another particular problem is that you will see some notches in the curves, which other pieces will slip into, so different slots need different specific offsets (making them larger) as a toelrance to allow for material play. This I don't even know how to set up so maybe it will just have to wait.
THE MAIN QUESTION, and super important would be, LIFESAVER:
At all 'inward' corners...which I think will always mean concave corners (most are 90 degrees, but are within to sides, instead of a corner sticking out). I'm sure its obviousy, but the reason being the outward corners a circular dril bit can cut, but inward ones need an arc profile extended beyond where the corner of the other piece will fit into. The drill bit i am using is 6mm, so 6mm diamters arcs is what i'm working with.
I have managed to put such an arc at every vertices of each cut piece. The problem being some stick outward isntead of cutting into the piece. So each one needs to be orieneted correctly. Ideally they would also only draw into inward corners, but I can always delete them out. I think maybe I am missing a more logical mathematical way of defining?
For these geometries it is not very important which side the half circle arc in on in the inward corners, but I also have some geometries that I will have to control where the circles face according to the rest of the cut piece.
The cutouts in the middle of the pieces that are curves do not need such corners obviously.
The picture is an example drawn
I hope this isn't too specific and long. in general though automating fabrication, and controling pracitcal math and orientation problems like this is itnersting to me!
THANKS…
perienced with grasshopper, but so far I've managed to combine the following:
Giulio Piacentino's "Catenary arch from height" script
Pirouz Nourian's "Mobius" script (Obtained from a friend)
End Result:
Here's where I'm stuck: I want the mobius twist to revolve around the midpoint of the arch, but the script uses the input values to determine the endpoints, resulting in a weird sinuous shape when viewed from above. Also, the secondary end points (generated by the mobius script, determining the width of the surface) are generated by default along the z axis, resulting in an arch that only touches the "ground" at two points. I attempted to work around this issue by trying to force the zHeight parameter to correspond with the y axis (thus rotating the arch 90 degrees so it would lay "flat"), but the script interprets the third point as a value and not as an actual point to bisect. I thought this might be an issue with the C# component that I obtained from Giulio Piacentino's script, so I attempted to tinker around with the source code. Unfortunately, I'm not fluent in C# so I only managed to mess everything up (I've since recovered the code from the cache). Anybody got some ideas? -BC …
onsidered period.
Even if the end of July for the mediterranean climate is not the best period to perform an adaptive comfort analysis (it's just a pretest to define a LB model) I want to refine the Adaptive comfort Chart (AC) by changing the external air temperature data imported from the .epw file with that of monitored data as reported here below:
Where the monitored ext air temperature are in this form (green panel below):
I have used the comfortPar component to set the following parameters:
Adaptive chart as defined by EN 15251
90% of occupants comfortable
the prevailing outdoor temperature from a weighted running mean of the last week
fully conditioned space (even if it is not properly in line with AC as already discussed)
The question is this: the AC component could correctly apply the code below if there is only a list of external temperature data for a restricted period (without indication about the limits of this period) and not for an entire year?
else: #Calculate a running mean temperature. alpha = 0.8 divisor = 1 + alpha + math.pow(alpha,2) + math.pow(alpha,3) + math.pow(alpha,4) + math.pow(alpha,5) dividend = (sum(_prevailingOutdoorTemp[-24:-1] + [_prevailingOutdoorTemp[-1]])/24) + (alpha*(sum(_prevailingOutdoorTemp[-48:-24])/24)) + (math.pow(alpha,2)*(sum(_prevailingOutdoorTemp[-72:-48])/24)) + (math.pow(alpha,3)*(sum(_prevailingOutdoorTemp[-96:-72])/24)) + (math.pow(alpha,4)*(sum(_prevailingOutdoorTemp[-120:-96])/24)) + (math.pow(alpha,5)*(sum(_prevailingOutdoorTemp[-144:-120])/24)) startingTemp = dividend/divisor if startingTemp < 10: coldTimes.append(0) outdoorTemp = _prevailingOutdoorTemp[7:] startingMean = sum(outdoorTemp[:24])/24 dailyRunMeans = [startingTemp] dailyMeans = [startingMean] prevailTemp.extend(duplicateData([startingTemp], 24)) startHour = 24
…
th one element which is a list of 10 numbers?
I can flatten it and get (I think) a list of 10 elements (even though when I hover over the output of "Flatten" it says "Tree(T) as tree"). I'm surprised I can flatten at all what would appear to common sense to be a simple list of 10 numbers.
I'm hoping that if I can get this answered it will become obvious why we have trees of lists rather than just lists of lists as you would in most computer languages. That's my real goal - to understand the purpose of adding what seems like an unnecessary complication - trees - to the concept of lists in GH. It seems to me as though a "tree" is just a list of other "trees" until you get to the leaves where you can have "lists" which are identical to trees but can have something other than a tree in them. Whether you can have lists of trees or trees with no lists I'm unclear on. Do the leaves of trees have to be lists? Do lists have to be contained in trees? It would appear from the series example where a tree is produced for no obvious reason to contain the list that this is the case but given that you can flatten it, I guess not - or is the "List" I see in the param viewer just another type of "tree"?
I've found many tutorials that talk about how to manipulate trees and lists and I've managed to get along fairly well with them so far, but nothing seems to explain the reasoning behind the existence of trees and the philosophy for how and when they should be used and when lists should/could be used and precisely what the difference is between them.
Sorry to be long winded but I'm so confused!
Darrell Plank
P.S. I've seen David Rutten's diagram with the colored leaves in Grasshopper Primer 2 and that seems helpful. It would appear that trees can only have lists at their leaves and lists can't have trees although I'm not sure that it comes out and says that directly but at least there are no examples of this shown in his tree diagram. I thought I had it down pretty much so decided to test myself. Apparently I'm as confused as ever:
It certainly appears to me that this tree has two levels - a first level with one limb and a second with 10 limbs - and that I should be able to index it with {0;0} and retrieve a tree with one item in it - the list {0}. The panel data seems to confirm this with indices of {0;0;0}, etc. so I put this path in with quite a bit of confidence that it would work and...bust. The error reads "Path {0;0} does not exist within this tree". Huh? Again, I'm just so confused.…
Added by Darrell Plank at 12:17am on January 20, 2015
try now to integrate Geco in an interdisciplinary architectural engineering studio: hoping we can show you some nice applications of your tool, I'll keep you update and sending now details by e-mail. Here the file (very welcome to be shared). It most probably contais trivial errors by me, thanks for helping and giving some tip! Gr. Michela
FILE:
Ok, right, I see the outputs update correctly. Origin of problems must be in some different mistake I do:
- Incident radiation: I am not sure I understand what is going on: why I get so many 'not a number' ? (The Galapagos report is full of NaNs).
Bio-Diversity: 0.887 Genome[0], Fitness=NaN, Genes [89% · 44%] { Record: Too many fitness values supplied } ...
Genome[7], Fitness=NaN, Genes [74%] { Record: No fitness value was supplied } ....
Genome[9], Fitness=NaN, Genes [37% · 11%] { Record: Genome was mutated to avoid collision Record: Too many fitness values supplied }
- Daylight calculations: the geometry accumulates withouth deleting the previous models. As a consequance, results almost do not change after few varations (so, outputs get updated but do not vary). In current daylight definition: the first object being imported is the one where the grid has to fit; its setting makes it cancelling all the other objects during import. All the others, do not delete anything when imported. When running loops (manual or GA) that vary parameters, the entire geometry do not get cancelled - so I guess the loop does not pass back by the cancelling step, but imports only the geometry which has been varied by the parameters using the setting of that import component only? I will then try again by changing the order of the operations, but if you have specfic tips, let me know.
THANKS!
…