truss right?
2. Trusses are NOT made via lines ... they are made by real-life components like balls, rods and other mysterious (and maybe ominous, he he) paraphernalia.Good news for you: lot's of C# stuff around me that do that (but they are not exactly "entry-level").
3. PRIOR talking to ANY FEA/FIM thingy you need to address clash situations: I mean IF a given node is doable or not (because lines they don't rise clash issues ... but rods/struts/tubes/cones do). Good news for you: lot's of C# stuff around me that do that (but they are not exactly "entry-level").
4. Then you have to use some real-life (or at least some "realistic") components like the ones found in, say, a classic MERO "ball" system (and especially the adapter cones between the balls and the tubes). Or at least "some" of them that outline a "realistic" truss.Good news for you: see above.
5. Then you could validate the whole structure AND the parts VS structural loads: I mean there's absolutely no meaning "doing the whole" without taking into account the load bearing capability of the parts. For instance, say, what happens if the geometry (i.e. the topology) is "capable" but a given bolt is weak? That sort of stuff.
6. Now ... this is Academic ... but following the "abstract" way (I don't care about bolts because I'm a student)... this could teach you the entirely wrong way to use FEA/FIM for validating any structural ability of ... anything. And besides FEA/FIM is used for making the damn thing in the real-world ... and that involves (unfortunately) "some" bolts and nuts.
I can arrange a (rather long) Skype session for a demo of all the above ... but first I strongly advise to post here a finished thing (in terms of 3d component geometry) ... and THEN we can examine the whole strategy: what to export, how and especially what could be an "interactive" (both ways) protocol/strategy in order to give the green light for that truss.
BTW: Kangaroo is a physics engine and as such it's used as an abstract "shape" finder. I have no idea what Karamba does ... but always have in mind: BIM things ... are BIM things (meaning that without a serious BIM umbrella ... don't go out when it rains).…
gns. There were a few issues with your case. I will try to list them, hoping that this can also be helpful to you but also other users in the forum.
1. The Rhino model contained a lot of open polysurfaces. This is a big enemy of meshing and CFD. The way meshing works is that every single open area, that can be reached from your locationInMesh with a polyline, will be included in meshing. Some of your lanscape volumes were open. I have rectified this in the .gh file attached and now they should be ok to mesh.
2. It is strongly suggested to rotate the geometry and not the incoming wind when creating the wind tunnel. This might as well have been the reason for meshing awkwardly, although can't be sure. I have rotated the geometry by 45 degrees to allow your original wind to have a Y+ direction.
3. I could see a decomposition component in your case study although I cannot be sure if this could be the reason of your problems. It was not connected to anything, but perhaps it might have been the culprit for the paralle issues you were having. I have disabled the component so the case would run in single processor, but you can freely enable it and your case will be run in parallel (4 cores).
4. Your post-processing surfaces have large parts inside the building volumes and under the landscape (if included). You will probably get some issues with visualizing some probes, although this will not affect your study in any way. I recommend to only pass probes that you know to be sure will be inside the mesh to OF.
5. If you decide to include the landscape (I have it disabled in the attached .gh file) I strongly recommend to allow for more cells than 2m. 10m would be a good start imo for this case.
6. I did not check, as it will not make your case break, but your grading was a bit imbalanced at first glance. Try and keep some balance, especially in the X-direction, and make sure to visualize the blockMesh and make sure you achieved what you had in mind.
I did not actually run the case btw, I leave that to you. I believe it will run without problems, although I cannot be sure it will not diverge (this is something that is very educational for you to deal with).
Good luck!
Theodore.…
he grouping of the sliders on the remote control panel.
4. Separate viewport(look at picture)
5. Cluster editor new wish
My version grasshopper 0.8.0004
Best Regards,Valentin
Kiev, Ukraine
…
e curve and uses the resulting surface/subdivisions to:
1. Smooth wall surface, varied via the Image Mapper
2. Segmented wall surface, varied via the Image Mapper
3. Populate the surface with spheres (with or without the "wall" surface)
4. Ribbed wall surface (Horizontal and / or Vertical)
5. Protrussions from the surface, driven by Image Sampler
6. Wall of Tubes, driven by Image Sampler
7. Gridded Web Surface
The options have to be enabled/disabled to achieve various results, but the idea is that this script permits a variety of looks, all in one script. See attachments at bottom.
I think this is a decent example file showing a variety of things that can be done using the Image Sampler Component in Grasshopper. This is a working version, so I am sure there are a lot better ways to achieve some of these effects. Hopefully, this will help some of you out and / or inspire some ew idea.
In the script, there is a User Object I downloaded from digitalsubstance. It is a self contained point attractor cluster, super cool, super fun. Link to the site is below.
http://digitalsubstance.wordpress.com/subcode/
If there is interest, I will update this post with an annotated version.
My blog, still in progress
http://thatsnotarchitecture.tumblr.com/
…
oks like the design in the following images:
Concept Images:
Shape:
Design_Request.pdf CR_tower_shape.ghdiagrid.gh
Shape Routine:
Diagrid Routine:
Example and Inspiration:http://www.solaripedia.com/images/large/4226.jpg
Goals:
The goal is to create a grasshopper routine that recreates a modifiable design concept as shown in the concept images. The following parameters should be modifiable
1) The size and elevation of all the basic triangles, circles and the ellipse.
2) The elevation and shape of the opening and the shape and size of the three legs.
3) The shape of the crown. The angle of the tilted ellipse.
4) The loft shape between the edges.
5) The grid size (U,V) of the diagrid.
6) The size of the 2 pipes used for the structure.
Rhino Grasshopper Workflow:
I attempted Boolean difference of a solid (Brep) and the surface in question to create the opening in the surface as shown above but that did not work. What should i do to recreate the concept in grasshopper ? I would appreciate any feedback and advice. Thank you very much !
-Christoph AKA Stoph
…
trying to develop it for my own project.
http://www.grasshopper3d.com/forum/topics/shortest-walk-tapered-branching-script?xg_source=activity&id=2985220%3ATopic%3A1450323&page=2#comments
On this page, he shared few 3D coral difinitions and especially interested in first and second one.
First one( bunny like 3D coral) - posted on February 2, 2016 at 9:43pm
Second one( sofa like 3D coral) - posted on February 6, 2016 at 3:16am
I followed these instructions, succeeded to build Tetgen, placed the built files in C drive directory and tried to run the definition. Then some WindowsError came out as follows which I don't know how to fix.
My working environment is;
OS is Windows 7 Ultimate 64 bit.
Rhino is version 5, 64 bit.
Grashoppper is version 0.9.0076, the latest version at this moment.
It would be great if I can have some help advice / comment.
I appreciate for your attention.
…
when the trimmed shapes (red) are small enough, they just dissapear.
Then, the main shape (green) appears again, but as a trimmed shape (red).
I tested it with other elements, like Solid Difference. It performs pretty well, but I just need the trimmed shapes (red) that are above the trimming shape (blue), and with Solid Difference, the collision also happens inside the trimming shape (blue), and that´s not what I am looking for.
Attached some pictures of what I mean. I hope I made myself clear.
Any suggestions?.
Thanks a lot!
1- Good performance
2- Good performance (Without trimming shape)
3- Left side shows the cut on the main shape, but fail to show the trimmed shape (red)
4- Same on the right side
5- It shows everything but in red colour, as a trimmed shape
…
t sure about my decision.
Let's take a look at the method <createPopulation>:
public static List<List<Point3d>> createPopulation(List<Point3d> cP, int populationCount)
{
List<List<Point3d>> Population = new List<List<Point3d>>(); // 1
for(int i = 0; i < populationCount; i++) //2
{
List<Point3d> individual = cP.ToList(); // 3
Population.Add(individual); // 4
System.Security.Cryptography.RNGCryptoServiceProvider provider = new System.Security.Cryptography.RNGCryptoServiceProvider();
int n = Population[i].Count;
while (n > 0)
{
byte[] box = new byte[1];
do provider.GetBytes(box); // 5
while (!(box[0] < n * (Byte.MaxValue / n)));
int k = (box[0] % n);
n--;
Point3d value = Population[i][k];
Population[i][k] = Population[i][n];
Population[i][n] = value;
}
}
In my algorithm there are lots of declarations like: List<Point3d> = new List<Point3d>(); or Random r = new Random(); these are constant time O(1) right?
i = 0 executes once; i < populationCount executes (N+1) times; i++ N times
this executes M times? because every point needs to be added individually?
this one I don't really know; at msdn it is stated: If P:System.Collections.Generic.List`1.Count is less than P:System.Collections.Generic.List`1.Capacity, this method is an O(1) operation. If the capacity needs to be increased to accommodate the new element, this method becomes an O(n) operation, where n is P:System.Collections.Generic.List`1.Count. Shouldn't it be O(N), because I am adding every individual separately?
can't find any statements about this one either, I am guessing it should be of constant time O(1), because just one random number is being generated?
…
hat, in accordance with this stable release, I have posted an updated version of this outdoor microclimate map example to the same link:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map
1. You will see that, in the new file, I now have a single component that is able to turn a zone into a "ground zone" (similar to a plenum). To clarify, both the plenum and ground zone components set all of the loads of the zone to 0 (no internal heat gain). So this means that any of the characteristics of the default office program will be negated. From your comments, Grasshope, it seems that you understand that the reason why I have a ground zone defined in this model is to account for the variation in ground surface temperatures that can occur with different objects casting shade onto the ground. Therefore, the key property that defines this zone is the construction of the top surfaces, which is now changed based on a number that you input into the Ground Zone component.
2. You are correct in understanding the need for both "set zone construction" components in the old file. Because of the zone's position below the Rhino model origin, the walls and floor are defined as underground surfaces and so I need the extra "Set EP Ground Construction" component. Admittedly, the constructions on the underground surfaces should have a minimal effect on the modeling of the surface temperature above the zone (the roof construction is most important) but it made sense to me that results would be more accurate by setting all of the constructions of the zone to the ground material. The current Ground Zone component ensures that all surfaces of the zone are assigned the ground material construction. It also ensures that all walls and floor surfaces have a ground boundary condition regardless of where they sit in relation to the rhino model origin.
3. The distFromFlrOrSrf input can take either a number representing the distance from the floor of zones at which you would like to build a microclimate map or any surface on which you would like to see temperature variation. So the input is flexible and allow you to both build micro-climate maps quickly or take a longer time building them with more customization. For a visual of what you can do by inputting surfaces into this component, see this thermal animation of a section through a building that I designed for my thesis:
https://www.youtube.com/watch?v=WJz1Eojph8E&list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A&index=3
For an example of a file using a numerical input for the microclimate map, see here:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_Map
4. The component has since been renamed (sometime in early July) to be called "Honeybee_Microclimate Map Analysis". Originally, I developed the component to help me understand thermal diversity within zones but realized after building it out that the same method could be used to give deeper understandings of the outdoor environment. So, at present, it can do both indoor and outdoor microclimate maps. The only shortcoming at present is that the outdoor microclimate map uses EnergyPlus's oversimplified means of accounting for outdoor wind (a simple wind profile that does nto account for obstructions). This shortcoming will be addressed once the first stable release of butterfly is out or I manage to work in components into LB that use the botlzman lattice particle collision method to approximate outdoor wind speeds. Other than this shortcoming, you can trust that all results you are getting from these components are to a high degree of accuracy (meaning that all air temperature and MRT values are accurate).
5. Thanks for pointing this out. This is a mistake in my labeling of the file names and I will fix this before the end of today. When you use the workflow with the PMV recipe, these values are actual PMV/PPD values. When you use the Adaptive comfort recipe, these values are "degrees from neutral temperature" and "Comfortable Or Not" values. When you use the workflow with the UTCI recipe, these values are also "degrees from neutral temperature" and "Comfortable Or Not" values but they are different for UTCI than they are for the adaptive model. Specifically, the neutral temperature and comfort zone for UTCI is defined to be the same as it is in this publication:
https://www.ipma.pt/en/enciclopedia/amb.atmosfera/index.bioclima/index.html?page=utci.xml
Hope this helps and let me know if you have any more questions,
-Chris…