/intralattice
User Docs: http://intralattice.com/userdocs
The current version is an early Beta release. As such, things may break without warning. If you happen to find bugs/issues, please leave a comment below or contact support@intralattice.com
The generative process is split into 3 main modules, each of which has a selection of various components, for a total of 16 components.
We first begin with a cell component, which will generate a unit cell. This unit cell is the basis for the lattice topology.
The next stage involves a frame component, which will populate a design space with the unit cell, based on various parameters.
The final stage involves a mesh component, which will convert the lattice wireframe (a list of curves) to a solid mesh, which can be 3D printed.
The mesh components are inspired by Exoskeleton, an assembly by David Stasiuk & Daniel Piker. I've extended functionality to curves, modified various aspects of the algorithm and encapsulated the process with a data structure. A huge thanks to them for making their work open-source.…
one bug on our end.
First, you set the natural ventilation setpoint to be only one degree greater than the heating setpoint. This frequently causes the building to expend heating energy reaching the setpoint only to throw away this heat a few minutes later when the indoor temperature rises by one degree. Generally, I would leave at least 3 degrees between these two setpoints unless you are using some special types of schedules that ensure this conflict does not happen.
Second, I do not know what you were trying to do with so many solve adjacency components but, when you hook up only one zone to this component and set "removeAdjacencies" to true, you will over-write all of the previous boundary conditions that you set in the surface-by surface method. These were the boundary conditions that you were sending into EnergyPlus in the file you uploaded:
As you can see, you were blowing your heating load out of proportion by getting rid of your originally-set adiabatic walls. In the attached GH file, I use just one solve adjacencies component and these are your resulting boundary conditions:
Finally, there was a bug in the function that checks the normal direction of surfaces input to the energy model and Mostapha just fixed this one this past week (https://github.com/mostaphaRoudsari/Honeybee/issues/365). This was causing the solar gain calculation to be incorrect in your model, which, admittedly, is the major reason why the heating loads between the north and south facades were not different. As you see in the attached GH file, you now get very different heating loads for the north and south facades:
I hope that all of this helped and, again, sorry for the delay.
-Chris…
d to be thrown away. Their area center often lies within the solid even if they are outside since after splitting with a curved mesh they can form a bowl. Checking many points of a fragment may be slow too, I imagine.
A simple obloid takes under a minute but the bunny mesh takes ten minutes. Then again the resulting model is also hard to manipulate in Rhino, so really is huge.
An email from the Tetgen developer is encouraging, so I can switch back to faster Tetgen Voronoi one day, but the slow step is the Boolean intersection of the mesh turned into a NURBS polysurface (brep) with all the cells that extend out to an overall bounding box. Tested in Rhino, it's indeed slow. Tetgen will likely not be providing clipped Voronoi output, ever, I imagine, though I put in a request. Actually, it's rather easy to test for outer/inner fragments after splitting Tetgen Voronoi cells since the outer ones are open instead of closed so when split have either one open edge loop or two.
"Hi Nik Willmore,Thank you for your bug report.I will check it and fix it in the next release version.For the -O option, it currently only supports numbers from 1 to 9.The current implementation for the -O option may not be suitable to use a larger number.It needs to be improved in the future.By the way, the grasshopper3d project seems very interesting.Thanks againHang Si /span>si@wias-berlin.de>"
Enclosed is the update that now has a rather short script.
Turning off Grasshopper preview mesh at the right of the toolbar can save lots of time when tweaking parameters since that's a lot of preview meshes to create from NURBS breps.…
Added by Nik Willmore at 3:37am on February 15, 2016
u, love you guys), naturally they get outdated time to time and I update them with Update Ladybug component. Same here but this time I stumbled upon some errors.
After the update all the LegendPar components returned error, this happened before and could be fixed by deleting the problem component with newly updated one (if memory doesn't play wacky tricks on me, I remember Mostapha explained that this could happen when the old component had different amount of plugs with the source code, since only the code is being updated, correct me if I'm wrong), but it didn't work this time.
As you can see on the image below, the red one is the original component and the new one is placed above it. Although the red component is connected, SunlightHours doesn't "see" it and show the analysis in fifty shades...ghmm, sorry, in gray shades, which is very hard to distinguish sometimes.
Error balloon says:
1. Solution exception:name 'decimalPlaces_' is not defined
When I connect new LegendPar component SunLightAnalysis gives me this:
Error balloon says:
1. Solution exception:index out of range: 9
At this time analysis diagram says bye bye and nothing works. I tried to change and reconnect all the wires and dance around the computer but nothing worked, is it possible that this is a bug? Or am I doing something cool?
Sorry for the amount of letters here, have a good day.…
tter to call them bug. Yes because when I run Galapagos to solve the problem it sometimes solve the problem completely but other times just in part. The problem is that with this kind of exercises that I'm doing you can check that there is a problem, but I'm studying it for my thesis and the goal will be to optimize a building in a ecological way, and the inputs will be more and sure will be hard to understand if Galapagos is working in the right way or not.
Therefore, what I want to ask is if someone can maybe check my files that I will upload and tell me if it run in the right way, maybe also trying it different times because like I said sometimes works in the right way and others not, leaving an element outside the calculation.
The simulation to run in the files are two, in the first there are 4 squares which I calculate the sommatory of the areas using the REGION UNION and doing it Galapagos should optimize the value giving me the minimum area between the squares. Sometimes it calculate it leaving apart one square. Anyway the right results should be to overlap all the squares.
The second one I have a catenary curve and 3 points and moving some slides Galapagos should adapt the curve to this 3 points. This simulation didn't give me any problem, so the problem should be the first.
Here is the definition of both the simulation.
I hope someone can solve my problem.
I also hope this exercises could be usefull for someone that is also starting to use Galapagos!
Thanks for your time and I will wait for your answers.…
ByFloorArea is set as False, the caption for the zone heating loads visualization still shows "floor normalized heating energy" (see image 1 and 2) below
2. When I try to visualize "zone windows total heat gain energy" normalized by floor area, the caption shows "average" instead, and the color legend is not changed to floor normalized values. (see images 3 & 4 below)
Hope you and bee-bug-lovers can kindly advise!
Thanks!
…
I said to myself : post (again) something in the errors/bugs category. But then I said (also to myself) : why ? everybody knows that ... post something fun(?) in the examples that can(?) guide(??) people out of the rabbit hole.
And here we are : 4 test surfaces, 4 paneling methods, 2 profile "classes", 2 orientation options, 3 methods to skin a cat, 2 methods to find intact panels (in "any" surface - trimmed or not with or without holes), 2 presentation alternatives, 7 gates, 2 filters, 1 Branch controller(?), 1 secret component (related with sardines) = let me make the maths : about 123,45 Loft examples (a bit primitive to indicate the main issue).
NOTE: GH quite frequently (a) fails to internalize data (b) internalizes them and reports the data as "null". Use Rhino file if this is your lucky day.
NOTE: Lunchbox is required
NOTE: Proper Named Views were defined ... but then components are moved ... blah blah: make your own.
best, Peter
…
r reference, I uploaded a testfile with labels A to F that shows this issues.
When selecting some objects and pressing the middle mouse button, a button for clustering appears. The inputs and outputs of clusters created with this immense useful function cannot be tagged.
1.
Set up a cluster like in A with inputs/outputs, tag the inputs/outputs with double click, cluster it, the inputs of the clusters B are correctly labeled.
double-click the cluster to edit it, double-click the input to edit the label, edit, save-and-close cluster - the new label doesn't appear at the input. Maybe I'm doing something wrong?
2.
select the objects to be clustered like in C, middle-mouse-button, cluster selection, the result can be seen in D. Again, double-click the cluster to edit it, edit the labels - nothing happens.
3.
This has to do with the visibility of clustered components. E shows two clusters that cannot be displayed, no matter if they are set to visible or not (it's the same component imported from my library, copied, disentangled and made inside visible one time). I believe I created it like method C.
I tried different cases (that's why there are so many differently visible variations in the file), but cannot reproduce this error.
best regards, Laurenz…
ut I don't know it safely...it could be a bug. David, we need you!
And only to point it out (because I think that it could help), this is the tree guide that David give us while testing the pre-release version:
Data Matching has changed because (A) there was a bug under certain conditions and (B) I wanted to make it more economical with regards to data path growth. The new logic is roughly as follows: First a master input parameter is identified. At the moment, it is the parameter with the longest path length. The amount of paths doesn't matter. Input parameters that have Tree access are never Master parameters (unless absolutely no other parameter is available) and List parameters have lower priority than Item parameters. In future versions it will probably become possible to assign a custom input as master. This however is an expert user function and I want to post-pone adding it as long as possible in order for the default behaviour to be tested and improved. If all input parameters are list parameters, output paths are no longer grown. I.e. The Reverse List component should output the exact same data tree structure as it gets. The master parameter might not be the parameter with the most branches. It is therefore possible that we run out of defined paths before the component is done computing. If this happens, the last index of the last available path in the master parameter is incremented on each iteration: Input A = {0;0} {0;1} {0;2} Input B = {0;1;0} Output C = {0;1;0} {0;1;1} {0;1;2} A has a maximum path length of 2, B has a maximum path length of 3, B is therefore the Master parameter. However we need three unique output paths since A provides three paths, so {0;1;1} and {0;1;2} are made up on the spot. It is also no longer possible to apply 'Shortest List' and 'Cross Reference' options to components. Old components that had these options set still work like they did before, but that should be considered legacy support. Instead, there are now three components in the Sets tab, List panel called 'Cross Reference', 'Short List', 'Long List' that basically provide the old functionality with a lot of additional flexibility and options.
…
n be moved to the appropriate place. The files are sensitive, but I can email them directly to you if you like.
1/ Contouring (and also Brep/Plane Intersection) generates non-closed curves from a closed brep (the screenshot actually shows a surface instead of a brep, but the same thing happens):
2/ Contour generates non-planar curves (one is also open, see below). This is very disturbing because it cannot be used to create a 'boundary surface'.
3/ Offset doesn't return all results. This seems like more of a rhinocommon problem. It always returns a valid result, but often not the one I want. Better would be to return all results and let me choose what I want.
4/ Fillet issues. See image below, the fillet component works fine up to a certain radius and then the one on the right disappears completely (presumably the radius is too large so it gives up). However, if I use the FilletAtParameter component, the fillet works at each of these points but it won't do all of the fillets at once (regardless of how I arrange the data tree). My work around at this point is to get it to fillet each of the sharp bits separately and then RegionUnion all the curves together, which is incredibly slow.
5/ There is no ExtrudeTapered component, so I wrote a quick VB.Net component to expose this functionality. Firstly: I cannot for the life of me figure out what the "Base Point" input does. This seems to have no impact on the result and the documentation is missing. Secondly: giving it a non-unitized vector does very strange things to the result.
Thank you for your help!
Steven
…