an almost planar tissue (your case) can cause a variety of issues up to the undo able state (metal parts/components grow in size as well for no reason). See forces estimated by FF below.
2. Therefor I strongly suggest to consider Plan B (a) mastermind a secondary "anchor" capability in order to achieve a far more stable system (b) use a mount design that can support this (and comply with the attractor concept of yours). Here's a variable mount custom system (mostly machined AND not cast) that is suitable for the scope (Rhino reads the stp file OK .... but makes a colossally big file - thus I attach here the original).
3. On first sight lot's of things in this system appear "odd". For instance: is it stable? Why these double cables are used? How far can be adjusted? (that's a classic case for feature driven parametric design - not doable with Rhino).
4. This concept (strut axis exported only) is tested in FORMFINDER and some other far more complex membrane apps that I use quite often (not RhinoMembrane). Here's is what FF tells us about:
Observe a different kind of "stress" when this is converted to radial type:
5. If you insert the stp file to the Rhino file provided (exactly as exported from FORMFINDER - no mods of mine of any kind) you'll see what goes where (and why). That way the usage of double cables is rather obvious (and a lot other things - for instance the way that the struts achieve "equilibrium", see the slots in the base mount plate.
6. If this approach is worth considering your definition requires some serious rethinking (far more simpler/manageable with the drawback that the real parts they are "static" they can adjust only as far this particular solution allows them to do - controlling them parametrically is clearly impossible with the current state of R/GH capabilities).`
All in all: this case works because the cables push the anchor points downwards and the struts push them upwards.
more in a while
…
d of interpenetrating surfaces somewhere:
Now all links (except a possible single ball on the very end of odd numbered ball series) are four balls long, including the jostled ones. Without that step, those items simply don't appear in the output, leaving way too big of gaps to ignore, eventually leaving huge gaps at later stages of segment doubling:
So if I turn the jostling multiplication factor way down it should work imperceptibly:
Ta-dah! The jostling strategy WORKS! Granted, only in this special case where I know I'm dealing with adjacent pairs of worms along a curve, not generic objects arranged in space by some artist.
Now I just need to wrap the multiple Python script components I'm stringing together into one script.
How long does the full 2400 balls take, finally? It took 12 Python scripts that merge pairs, to achieve this breakdown: 2400 -> 1200 -> 600 -> 300 -> 150 -> 75 -> 38 -> 19 -> 9 -> 5 -> 3 -> 2 -> 1. Time was 2 minutes 50 seconds, so there is some extra struggle for 2X as many balls as 1200 that took 1 minute 20 seconds, but only ten more seconds.
…
Added by Nik Willmore at 9:06pm on February 17, 2016
hacia donde crecerán las venas, y tenemos otro conjunto de puntos 'N' que son los que forman el patrón de venas.
1. Por cada 's' perteneciente a S, buscamos el 'n' perteneciente a N más cercano. Ese 'n' va a "moverse".
2. Por cada 'n' que se mueve, hacemos un vector dirigido a todos los 's' hacia los que se mueve.
3. Calculamos el vector medio de todos los vectores del paso 2, movemos 'n' con ese vector y lo añadimos a V.
4. Si algún 's' está muy cerca de algún 'n', ese 's' se elimina.
5. Se repite el proceso.
Esto es para formar venaciones abiertas sin autocrecimiento (como la siguiente imagen, hecho con Visual Basic).
Para las cerradas (las reticuladas que forman algo como células, como en la imagen tuya), el paso 1 y 4 son distintos y no sabría decirte cómo hacerlo. En ese pdf explica un método usando delaunay pero es muy lento, además gh no tiene ese algoritmo en 3d (entonces solo se podría hacer este patrón en 2d), por lo que estoy buscando otras vías, solo he logrado llegar a esto:
Es más complicado de lo que parece.
No obstante, si te conformas con menos, hay muchas formas de crear raíces y patrones similares, con SortestWalk, Anemone, etc... Hay ejemplos en este foro.
Si realmente quieres conseguir ese patrón, deberías aprender a programar porque para añadir distintos radios a las venas es necesario que las venas tengan topología y eso se complica demasiado desde gh. Nervous System para su "Hyphae" usó C++ con la librería CGAL, que es una muy poderosa librería de algoritmos de 3d.
…
d work exactly as the physical model. In the model, we have a curved surface which can be analysed into squares. These squares are filled with two kind of units which are connected with each other and create a grid that follows this curved surface.
We have managed to analyse this curved surface into a planar surface consisted of squares and we painted the squares with colours to represent the kind of unit that "fills" each square. So, now in rhino I have managed to build the curved surface that I want it to be filled with the two types of units.
I also have the planar surface built in Gh with the squares split into two lists, each one for each kind of unit. Because these units are mambranes, I used kangaroo to make them act like mambranes.
I hope I described the problem clearly. The point is to keep the dimensions of the units
the same and make it work in Kangaroo. Do you have anything in mind that I should look up or any advice ? Thank you in advance and i m sorry for the extended description.
*Pic 1: the curved surfaces that has to be filled with the units
*Pic 2: The binary system that shows which square is occupied by which unit
Blue=2 , Red=1, White= Blank
*Pic 3: unit 1
*Pic 4: unit 2
*Pic 5: a point of view of the physical model (not the final curve at the surface)
…
e.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map
Thank you very much in advance!
1. why the underground zone representing the ground is defined as a plenum zone? By default, an office zone program is assigned. Will this affect the outside surface temperature of the ground plenum zone and affect, in turn, the outdoor microclimate map calculation?
2. I assume the construction GroundMaterial composed of five layers of 200mm concrete materials as assigned to the ground plenum zone is to assimilate a ground surface composed of thick concrete. But why this construction is assigned to this zone using both the Set EP Zone Construction and Set EP Zone Underground Construction components? Will the surfaces of this zone automatically recognized as underground surfaces based on their positions in relation to the default xy plane?
3. why a brep is connected to the input node distFromFloorOrSrf on the Indoor View Factor Calculator component which is expecting a number according to its annotation?
4. why the outdoor comfort analysis recipe is used for the indoor comfort analysis component?
5. why the OutdoorComfResult and DegFromNeutralResult are 2 csv files with PPD and PMV values if PMV/PPD thermal comfort model is only applicable to indoor air-conditioned space?
…
the following image of a hut.
I do not have experience using kangaroo to simulate forces, but I have made a test using multiple random components on a flat surface to fake the effect I'm going for. See image below.
The main issue I'm having is that the original file used for my test surface used box morph and the variable pipe command. Box morph is a bit touchy on a curved surface and it is not as elegant as I would like it to be (ie. I want all the hair diameters to be perfectly circular and uniform in size). Variable pipe also does not align the base of the hair with the existing surface, which means I have to offset the surface and then trim the excess of my pipe.....leading to heavy code and the file crashing.
So I'm trying to rebuild the "hairs" using a new method:
1) Subdivide the surface
2) Find the midpoint of each surface and then create a straight line that is perpendicular
3) Move a point along the on the straight line (between the start and end points) in the z direction, and then create a nurbs curve using this point and the start and end points
4) create a circle at the base of each crv, and then two more circles: one at the point in the middle point (I think I set it to .9) and the end of the curve
5) The problem: Now I am trying to sweep along these three circles and the nurbs curve to create a bent hair/pipe that is flush with the conic surface, but it does not work.
If someone can help that would be amazing. I've included my original surface test file and my new file where I am rebuilding using the sweep command. Below is a drawing of what I'm trying to achieve.
…
ing the maps to the broader community.
At the moment, there are just a few known issues left that I have to fix for complex geometric cases but they should run smoothly for most energy models that you generate with Honeybee. Within the next month, I will be clearing up these last issues and, by the end of the month, there will be an updated youtube tutorial playlist on the comfort tools and how to use them.
In the meantime, there's an updated example file (http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_Map) and I wanted to get you all excited with some images and animations coming out of the design part of my thesis. I also wanted to post some documentation of all of the previous research that has made these climate maps possible and give out some much deserved thanks. To begin, this image gives you a sense of how the thermal maps are made by integrating several streams of data for EnergyPlus:
(https://drive.google.com/file/d/0Bz2PwDvkjovJaTMtWDRHMExvLUk/view?usp=sharing)
To get you excited, this youtube playlist has a whole bunch of time-lapse thermal animations that a lot of you should enjoy:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A
To give a brief summary of what you are looking at in the playlist, there are two proposed designs for completely passive co-habitation spaces in New York and Los Angeles.
These diagrams explain the Los Angeles design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJM0JkM0tLZ1kxUmc/view?usp=sharing)
And this video gives you and idea of how it thermally performs:
These diagrams explain the New York design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJS1BZVVZiTWF4MXM/view?usp=sharing)
And this video shows you the thermal performance:
Now to credit all of the awesome people that have made the creation of these thermal maps possible:
1) As any HB user knows, the open source engines and libraries under the hood of HB are EnergyPlus and OpenStudio and the incredible thermal richness of these maps would not have been possible without these DoE teams creating such a robust modeler so a big credit is definitely due to them.
2) Many of the initial ideas for these thermal maps come from an MIT Masters thesis that was completed a few years ago by Amanda Webb called "cMap". Even though these cMaps were only taking into account surface temperature from E+, it was the viewing of her radiant temperature maps that initially touched-off the series of events that led to my thesis so a great credit is due to her. You can find her thesis here (http://dspace.mit.edu/handle/1721.1/72870).
3) Since the thesis of A. Webb, there were two key developments that made the high resolution of the current maps believable as a good approximation of the actual thermal environment of a building. The first is a PhD thesis by Alejandra Menchaca (also conducted here at MIT) that developed a computationally fast way of estimating sub-zone air temperature stratification. The method, which works simply by weighing the heat gain in a room against the incoming airflow was validated by many CFD simulations over the course of Alejandra's thesis. You can find here final thesis document here (http://dspace.mit.edu/handle/1721.1/74907).
4) The other main development since the A. Webb thesis that made the radiant map much more accurate is a fast means of estimating the radiant temperature increase felt by an occupant sitting in the sun. This method was developed by some awesome scientists at the UC Berkeley Center for the Built Environment (CBE) Including Tyler Hoyt, who has been particularly helpful to me by supporting the CBE's Github page. The original paper on this fast means of estimating the solar temperature delta can be found here (http://escholarship.org/uc/item/89m1h2dg) although they should have an official publication in a journal soon.
5) The ASHRAE comfort models under the hood of LB+HB all are derived from the javascript of the CBE comfort tool (http://smap.cbe.berkeley.edu/comforttool). A huge chunk of credit definitely goes to this group and I encourage any other researchers who are getting deep into comfort to check the code resources on their github page (https://github.com/CenterForTheBuiltEnvironment/comfort_tool).
6) And, last but not least, a huge share of credit is due to Mostapha and all members of the LB+HB community. It is because of resources and help that Mostapha initially gave me that I learned how to code in the first place and the knowledge of a community that would use the things that I developed was, by fa,r the biggest motivation throughout this thesis and all of my LB efforts.
Thank you all and stay awesome,
-Chris…
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
tives for low-dimensional, or highly continuous problems. Having a somewhat faster way to trigger a galapagos run would also be beneficial."
I found a post on the 'hoopsnake/forum' describing the very same problem I am trying to solve, and looked into using HoopSnake (without satisfaction so far):
Double loop and hydrostatics?
I don't want to wait until G2 so will re-state some of what I posted earlier, then offer a template for an ideal "fast solver" component ('B-Solve') that could be widely useful. I am ready to accept that it might be written in Python, C, or VB - as long as it's open source or built in to standard GH. If there is a GH plugin that will do this, I'd like to know that too, though prefer a lightweight solution rather than a big toolbox.
QUESTION: Is there a FAST (binary search speed) GH way to "solve" toward a goal by "moving" a single slider?
CONTEXT: I have a boat hull of a given displacement at rest. I rotate the hull to an arbitrary angle ("heel" caused by wind in the sails) and want to adjust a 'Z-offset' slider so the displacement is the same as it was at rest.
I can adjust the slider manually, zooming in for better control, and with a dozen tries or so, in a very short time, narrow in with a binary search method and get very close to matching the value.
When I hook up Galapagos, it runs on and on forever, trying values that are "obviously" further away instead of closer to the goal. When I can solve it manually faster than Galapagos, a different solution is needed.
OBJECTIVE:
I want a FAST solution that doesn't need any manual input. Ideally, it would respond like any other component and re-calc whenever its inputs changed. At worst, a 'start/reset' trigger, "soft input" so it can be used inside a cluster.
It doesn't need to control a slider, they just happen to be handy for defining a range and precision of values.
Using Galapagos: HydroSolve_2015_Sep8a.gh (attached)
An extremely stripped down version of the problem using Grasshopper.
NOTE: One obvious problem here is that by using absolute value ('abs()') for the 'difference' here, Galapagos doesn't know whether it's too high or too low!
Instructions:
Start with 'Roll=0', 'Volume=1543.943'
Adjust 'Roll' to ~35 degrees
"Solve" 'Z-offset' value to return to 'target' (original) volume of 1543.943
Using 'B-Solve': HydroSolve_2015_Sep8b.gh (attached)
'B-Solve' is the proposed fast solver component. Its 'solution' output is always in the range of zero to one, which is remapped by the green group as -5 to 5 and used as the 'Z-offset' for 'Pitch-Roll-Z'.
Starting value ('Reset') for 'solution' is 0.5, and 'B-Solve' tries different 'solution' values to make 'result' (the 'Volume') and 'goal' match. An efficient uphill(?) or binary searcher could be very fast.
Does this sound feasible? Can anyone implement 'B-Solve'?
Two at once?
The post noted earlier, Double loop and hydrostatics?, brings up a complication that's worth considering from the start... Depending on hull shape, the center of buoyancy may move fore and aft, away from the center of gravity, as the hull rolls. This induces a change in pitch so a second 'B-Solve' component could be used in the same model to adjust pitch, which of course changes 'Volume' again... Not quite sure how the two would get along?
Thanks.
Note: the hull in these examples is a really poor shape!…
Added by Joseph Oster at 1:30pm on September 9, 2015
rring to the above image)
Area
effective
effective
Second
Elastic
Elastic
Plastic
Radius
Second
Elastic
Plastic
Radius
of
Vy shear
Vz shear
Moment
Modulus
Modulus
Modulus
of
Moment
Modulus
Modulus
of
Section
Area
Area
of Area
upper
lower
Gyration
of Area
Gyration
(strong axis)
(strong axis)
(strong axis)
(strong axis)
(strong axis)
(weak axis)
(weak axis)
(weak axis)
(weak axis)
A
Ay
Az
Iy
Wy
Wy
Wply
i_y
Iz
Wz
Wplz
i_z
cm2
cm2
cm2
cm4
cm3
cm3
cm3
cm
cm4
cm3
cm3
cm
I have a very similar table which I could import to the Karamba table. But I have i_v or i_u values as well as radius of inertia for instance.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
dimensjon
Masse
Areal
akse
Ix
Wpx
ix
akse
Iy
Wpy
iy
akse
Iv
Wpv
iv
Width
Thickness
Radius R
[kg/m]
[mm2]
[mm4]
[mm3]
[mm]
[mm4]
[mm3]
[mm]
[mm4]
[mm3]
[mm]
[mm]
[mm]
[mm]
L 20x3
0.89
113
x-x
4,000
290
5.9
y-y
4,000
290
5.9
v-v
1,700
200
3.9
20
3
4
L 20x4
1.15
146
x-x
5,000
360
5.8
y-y
5,000
360
5.8
v-v
2,200
240
3.8
20
4
4
L 25x3
1.12
143
x-x
8,200
460
7.6
y-y
8,200
460
7.6
v-v
3,400
330
4.9
25
3
4
L 25x4
1.46
186
x-x
10,300
590
7.4
y-y
10,300
590
7.4
v-v
4,300
400
4.8
25
4
4
L 30x3
1.37
175
x-x
14,600
680
9.1
y-y
14,600
680
9.1
v-v
6,100
510
5.9
30
3
5
L 30x4
1.79
228
x-x
18,400
870
9.0
y-y
18,400
870
9.0
v-v
7,700
620
5.8
30
4
5
L 36x3
1.66
211
x-x
25,800
990
11.1
y-y
25,800
990
11.1
v-v
10,700
760
7.1
36
3
5
L 36x4
2.16
276
x-x
32,900
1,280
10.9
y-y
32,900
1,280
10.9
v-v
13,700
930
7.0
36
4
5
L 36x5
2.65
338
x-x
39,500
1,560
10.8
y-y
39,500
1,560
10.8
v-v
16,500
1,090
7.0
36
5
5
I have diagonals (bracings) which can buckle in these "non-regular" directions too, and they do. If I could add those values then in the Karamba model I could assign specific buckling scenarios..... I can see another challenge which will be at the ModifyElement component, I will not be able to choose these buckling lengths, in these directions.
Do you think this functionality can be added within short, or should I try to find another way to model these members?
Br, Balazs
…