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
- Exception occured during processing of command: Grasshopper Plug-In = Grasshopper Font 'Segoe UI' does not support style 'Regular'. Stack trace: at System.Drawing.Font.CreateNativeFont() at System.Drawing.Font.Initialize(FontFamily family, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont) at System.Drawing.Font.Initialize(String familyName, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont) at System.Drawing.Font..ctor(String familyName, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet) at Grasshopper.GUI.GH_DocumentEditor.InitializeComponent() in C:\dev\Grasshopper\1.0\root\src\GH_DocumentEditor.Designer.vb:line 329 at Grasshopper.GUI.GH_DocumentEditor..ctor() in C:\dev\Grasshopper\1.0\root\src\GH_DocumentEditor.vb:line 1779 at Grasshopper.Plugin.Commands.ShowGrasshopperEditor(Boolean ShowUponLoad) in C:\dev\Grasshopper\1.0\root\src\GH_GrasshopperCommands.vb:line 22 at Grasshopper.Plugin.Commands.Run_Grasshopper() in C:\dev\Grasshopper\1.0\root\src\GH_GrasshopperCommands.vb:line 94 at GrasshopperPlugin.GrasshopperCommand.RunCommand(IRhinoCommandContext context) at RhDN_TemplateCommand<CRhinoCommand,RMA::Rhino::MRhinoCommand>.RunCommand(RhDN_TemplateCommand<CRhinoCommand\,RMA::Rhino::MRhinoCommand>* , CRhinoCommandContext* context) --------------------------- OK ---------------------------
I am using grasshopper 0.8.0050 and Rhino 4 SR8. I tried uninstalling it, and then installing it again. The same. It is interesting that until yesterday, everything was fine. What could possibly be the cause of a problem?
Thank you.…
ce attractors
3- Relation between mathematics and Form
4- Network surface and Paneling
5- Fabrication methods (slice3d, nesting, ...)
6- Structure and Architecture (Millipede)
7-Energy and form
8- Islamic patterns
9- Physics with kangaroo
…
ions are probably reflective of the prevailing humidity conditions (I just had a chat about this with my advisor, who incidentally also happens to be on the committee for LM-83).
The Tregenza sky patches considered in daylighting calculations don't do a good job of incorporating the correct size of the sun into calculations. In the figure below, the sun on the right is the one considered for calculations in Daysim. You can get a more accurate answer by considering a more discretized sky, however, I am not aware if that is possible with Daysim (and therefore HB) right now. Therefore, your direct sun calculations are likely to be off somewhat depending on how much of it there is(I'd say overestimated).
The calculations with humid sky, which are on account of the sky itself (and not the sun alone) are likely to be more relevant.
Regarding your questions about studying weathering effects with LB/HB, I have no idea as that is something that I haven't looked into before. I am sure someone else on this list has a more informed opinion on this issue than I do.
Your project, and your approach to it, seems really interesting and I am glad to be having this discussion :).
Sarith
…
see in my bottom post image there is only one isocurve showing in U and V.
In Grasshopper there's no surface rebuild? Well, the same old Grasshopper Patch command will let you specify spans I guess, to make a surface from a planar curve, but it won't work for things with holes since they will just fill in!
You can recreate a surface painfully by untrimming, adding many UV points, rebuilding from those points, then retrimming with the original surface info, but the retrimming simply fails.
If you make a planar surface from a curve in Rhino, you end up with utterly no point editability:
No wonder my CreatePatch tests were a failure. The starting surface could not be distorted except in the extreme case of moving four corner points!
I have no idea how to successfully rebuild a surface akin to the Rhino rebuild command. It's great to be able to prototype in Grasshopper, but with Python I can rebuild easily ( http://4.rhino3d.com/5/rhinocommon/?topic=html/M_Rhino_Geometry_Surface_Rebuild.htm ;), so I guess I should start a collection, like peter, of little script components for prototyping with.…
Added by Nik Willmore at 6:18am on February 26, 2016