si à faire le tri avec Grasshopper et l'outil Points in Brep, comme je pensais. Je suis passé d'environ 400 000 points à uniquement 20 000 points autour de mes 3 rails. C'est très efficace (mais un peu dangereux avec tous ces points).
J'ai interdit au composant CircleFit de faire un cercle, s'il n'y a pas au moins 5 points présents sur la section. Car lorsqu'il y a seulement 3 ou 4 points, il suffit qu'il y en ait un pour que le cercle soit faux, alors qu'au delà, le cercle a plus de chance d'être "bon".
J'ai également créé des "Pipe" (créés à partir de portions de l'axe) au lieu des "Box » de sélection des points pour éviter de sélection trop de points que ne serait pas des points du rail.
J'ai ensuite créé des « panel » pour la moyenne des distances en X et en Y et la moyenne des distances centre à centre.
Tout cela fonctionne bien avec un axe et un tuyau. Mais maintenant j'essaie d'appliquer ça à plusieurs rails en même temps. Je crois avoir compris qu'il faut créer des « path » dans l'imput manager, et faire correspondre le « path » de l'axe et celui du Tuyau.
Dans mon exemple j’ai mis 3 courbes et 21 sections. Au moment où j'utilise les boîtes pour créer les portions des axes, il crée 63 « sous-path » de 1 courbe alors qu'il faudrait qu'il crée 3 "paths" de 21 courbes, enfin si j'ai bien compris.
Car une fois qu’il a créé les points à l’intérieur des « Pipe », il doit les projeter sur les plans correspondant. Et c’est là que le problème se voit. Il ne fait pas correspondre les points à projeter et les plans.
Je vous envoie la version à une courbe et un tuyau (c’est la v5 avec un fichier rhino ou la courbe d'axe est "bakée" pour pouvoir faire un zoom sur la zone plus rapidement) et je vous envoie également, celle avec 3 courbes et 3 tuyaux. Sachant qu’il faudra également attribuer un rayon pour un des tuyaux et un autre rayon pour les deux autres.
Tout ça est bien compliqué, j’espère que je ne vous embête pas trop.
Merci d’avance.…
onsider:
Identify the aspect of calculations that consumes the most amount of time and resources: Based on what I have understood till now about the parametric workflow within the Grasshopper environment I don’t think it is Rhino/Grasshopper that consumes the maximum amount of time/resources (unless you are handling complex geometry and using native rendering). So, if you could identify the part of your iterations that consumes the maximum amount of resources we can look into parallelizing/optimizing that. It could be something like (RhinoModelling-15%, E+-40%,Radiance-45%)… If there is no way to keep track of that right now in Grasshopper, let me know, I might be able to write a custom script that records the timestamp for each part of the calculation.
Parallelizing Grasshopper: I have no idea of how to do this so I think the best resource/forum would the Grasshopper/Honeybee discussion board. I think at the very least, to make Grasshopper run on remote computers, you’d have to install Rhino/Grasshopper on those computers as well.
Parallelizing EnergyPlus/Radiance: Based on what I understand from reading Mostapha’s source code and also talking to him on this issue, Honeybee typically creates batch files ie radiance or e+ instructions which are then used to run EnergyPlus and Radiance. Radiance runs can be parallelized to a great extent, however, owing to the modular nature of how calculations are setup for grid point calculations , image rendering and some of the new matrix based calculations, there is no single answer to parallelizing Radiance calculations. One can look into optimizing a certain type of calculation and then code instructions for implementing those. E+, which I have only been using for the past month or so, doesn’t seem to have a native way of setting up parallel runs. One can, however, set up multiple separate runs of E+ and direct them to separate processors. I think there was some discussion E+ in the Honeybee forum so you might get a better answer from there on this issue.
Clustering computers and GPU based calculations: One way of implementing the kind of parallelizing that you are referring to, ie. utilizing unused desktops is to cluster computers. Penn State has a dedicated, text-only, Linux-based cluster system which I have been tinkering with for the past year or so. A single node of this cluster has 60 parallel cores and close to 300GB or RAM. Each node, in turn, was created by linking a bunch of computers together. Implementing such a cluster would require an active participation from IT systems admins in your firm. Another option is to use Accelerad for Radiance which parallelizes Radiance . Radiance doesn’t have a limitation regarding the number of cores you could use. I think the 8 processors that you mentioned is more a function of the currently available desktop computer configurations than Radiance’s ability to handle more processors(i7 for example, has 8 processors). In the past, I have run parallel renderings with up to 20 processors. Radiance code is optimized to run on Linux systems so the performance on Windows systems is likely to be somewhat slower.
Finally, unless there is a pre-existing platform to handle such parallel processing, some scripting effort would be required to direct calculation files outwards into different systems/processors and then fetch and consolidate results from those calculations into a single location and then visualize those results on an interface like Mostapha’s Design Explorer.
Sarith…
ing ways to leverage simulation results from ladybug and inform design of building envelops with benefits that can be modeled. Given 20 percent of the cost of a project typically goes to the facades, and maybe a half of that goes to the openings, there is a good enough reason to question how to materialize that 10 percent, which can result in 10-30 percent difference in total energy comsumption.
I think ideally radiation analysis, natural ventilation and daylight analysis on floors should all inform opening sizes and placements, as well as the building sections at large. However natural ventilation seems to be the most complicated one because it couples airflow and thermo dynamics. I have a definition setup so that I can batch simulations for radiation analysis and daylight analysis, but natural ventilation is the missing link. So for what I am doing now I will select a handful of design that seem to work the best based on the two available analysis and convert all the geometry into CAD files so that I can run them in an evaluation copy of autodesk simulation CFD. So for now I can do this in 2 stages.
But for the future, given the possibility of actually have that as a part of grasshopper feature, which would be lovely, I want to understand the science behind it and share some links.
(http://www.wbdg.org/resources/naturalventilation.php) In this link the author outlines quite a few general principles and variables to consider for natural ventilated buildings.
For example, how stack effect works.
Qstack = Cd*A*[2gh(Ti-To)/Ti]^1/2, where
Qstack = volume of ventilation rate (m³/s)Cd = 0.65, a discharge coefficient.A = free area of inlet opening (m²), which equals area of outlet opening.g =9.8 (m/s²). the acceleration due to gravityh = vertical distance between inlet and outlet midpoints (m)Ti = average temperature of indoor air (K), note that 27°C = 300 K.To = average temperature of outdoor air (K)
The thing about natural ventilation is that not only the sizes and positioning of openings of the facade facing predominant wind matter, but also the openings on the other side matter. The vertical distance between the inlets and outlets also need to be taken into account. The author suggests that naturally ventilated buildings should be no wider than 45 feet.
and in this pdf presentation it discusses CFD for natural ventilation and illustrates why it is not easy
http://isites.harvard.edu/fs/docs/icb.topic882838.files/L17.6205Airflow-Modeling_Ibarra.pdf
and in this pdf briefly outlines the approach taken by designbuilder
http://isites.harvard.edu/fs/docs/icb.topic472869.files/DesignBuilder%20Simulation%20Training_HSD.pdf
Lastly a wide spectrum of environmental analysis works by e3lab
http://www.e3lab.org/research
http://www.e3lab.org/green-buildings
If I make progress on a way to tie the three analysis together (radiation, daylight and natural ventilation), I wont forget to post it on this thread.
Thanks.…
nergy plus silulation and this is the error text:
Current document units is in MetersConversion to Meters will be applied = 1.000Duplicate surface name! Name is changed to: Pelle_Sopra_DupDuplicate surface name! Name is changed to: Pelle_Nord_Dup[1 of 8] Writing simulation parameters...[2 of 8] No context surfaces...[3 of 8] Writing geometry...[4 of 8] Writing Electric Load Center - Generator specifications ...[5 of 8] Writing materials and constructions...[6 of 8] Writing schedules...[7 of 8] Writing loads and ideal air system...[8 of 8] Writing outputs......... idf file is successfully written to : C:\Users\Personal\Desktop\TESI\x006\THOR001\EnergyPlus\THOR001.idf
Analysis is running!...C:\Users\Personal\Desktop\TESI\x006\THOR001\EnergyPlus\eplusout.csv......
Done! Read below for errors and warnings:
Program Version,EnergyPlus, Version 8.3.0-6d97d074ea, YMD=2016.01.05 20:08,IDD_Version 8.3.0
************* IDF Context for following error/warning message:
************* Note -- lines truncated at 300 characters, if necessary...
************* 160 ScheduleTypeLimits,
************* indicated Name=ANY NUMBER
************* Only last 2 lines before error line shown.....
************* 161 ANY NUMBER, !- name
************* 162 ScheduleTypeLimits, !-
** Severe ** IP: IDF line~162 Invalid Number in Numeric Field#1 (Lower Limit Value), value=SCHEDULETYPELIMITS, in SCHEDULETYPELIMITS=ANY NUMBER
************* IDF Context for following error/warning message:
************* Note -- lines truncated at 300 characters, if necessary...
************* 258 ScheduleTypeLimits,
************* indicated Name=ANY NUMBER
************* Only last 2 lines before error line shown.....
************* 259 ANY NUMBER, !- name
************* 260 ScheduleTypeLimits, !-
** Severe ** IP: IDF line~260 Invalid Number in Numeric Field#1 (Lower Limit Value), value=SCHEDULETYPELIMITS, in SCHEDULETYPELIMITS=ANY NUMBER
** Warning ** IP: Note -- Some missing fields have been filled with defaults. See the audit output file for details.
** Severe ** IP: Possible incorrect IDD File
** ~~~ ** IDD Version:"IDD_Version 8.3.0"
** ~~~ ** Version in IDF="8.3.0" not the same as expected="8.3"
** ~~~ ** Possible Invalid Numerics or other problems
** Fatal ** IP: Errors occurred on processing IDF file. Preceding condition(s) cause termination.
...Summary of Errors that led to program termination:
..... Reference severe error count=3
..... Last severe error=IP: Possible incorrect IDD File
************* Warning: Node connection errors not checked - most system input has not been read (see previous warning).
************* Fatal error -- final processing. Program exited before simulations began. See previous error messages.
************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.
************* EnergyPlus Sizing Error Summary. During Sizing: 0 Warning; 0 Severe Errors.
************* EnergyPlus Terminated--Fatal Error Detected. 1 Warning; 3 Severe Errors; Elapsed Time=00hr 00min 0.30sec
thanks for any help
Lhor…
os3D + Grasshopper3D + Maya + Advanced Plugins & Demo Toolkits]
// Level
Basic, Intermediate & Advanced
(Previous parametric design knowledge not obligatory - Studio is adaptive to basic & advanced users)
// Agenda
The workshop aims to provide a detailed insight to ‘parametric design’ and embedded logics behind it through a series of design explorations using Rhinoceros & Grasshopper platforms, along with understanding of data-driven design strategies. An insight to Computational Design and its subsets of Parametric Design, Algorithmic Design, Generative Design and Evolutionary Design will be provided through presentations, technical sessions & studio work. Studio work will be focusing on modulation of geometry and iterative form using Parametric Design methods that will lead to explorations of spatial geometries that can be articulated as architectural constructs or abstract artistic interventions. There will be a demonstration of Fluid Form Modelling using Autodesk Maya on Day03.
The 1st batch of workshop in London took place in January 2020 with an exploratory learning output for ~20+ participants that travelled from different parts of the world to be a part of 3-day workshop titled Parametric Modulations. V2.0 is the evolved workshop with new toolkit add-ons for the 2nd batch and demonstrative tools & examples for future use of participants to get a deeper understanding of Computational & Parametric Design.
// Methodology
The 3-day studio / workshop shall focus on inculcating the following aspects as a part of curriculum:
Computational Design Techniques & Parametric Design
Data, Mathematics & Geometry
Geometry Rationalization
Iterative Form Development
Digital simulation of forces
Environmental Analysis (Tool-kits & Example files for future use)
Collaborative Design Exercises to understand application of the learnt tools
Documentation and Presentation
Hands-on Demonstration of Maya (Polygonal Mesh Modelling)
The workshop is suitable for beginners, intermediate as well as advanced users of these tools and very helpful for anyone planning to start their Masters in UK as this 3-day workshop would serve as a bootcamp to kick-start anyone's journey in Computational Design.
…
giornata inaugurale sarà dedicata alla free-lecture introduttiva finalizzata alla realizzazione di un modello d'architettura complesso attraverso l'utilizzo di comandi e tecniche avanzate di rappresentazione con Grasshopper (plug-in parametrica di Rhinoceros) e 3dsMax. Sarà illustrato inoltre il potenziale di V-ray per 3dsMax realizzando un rendering concettuale. Durante il mini-corso dell' openDAY verranno mostrate le caratteristiche e le potenzialità degli strumenti per far luce sui nuovi valori assunti dalla modellazione 3D. La modellazione 3D sta interessando un pubblico sempre più vasto inserendosi in una nuova fase di ampia disponibilità per conoscenze, software, hardware di prototipazione e modelli. Pur mantenendo tutti i suoi valori già noti la questione si è talmente ampliata fino ad interessare norme giuridiche (diritti sui modelli ,concorrenza con offerte di servizi apparentemente simili, informazioni deformate e onfusione nei media) Makers University[http://www.makersuniversity.com], in collaborazione con parametricart, vi propone un punto di vista ampio e sintetico su queste tematiche.
Al termine della free-lecture, sarà illustrata l'offerta formativa [CLICCA QUI] di parametricart riferita ai corsi che si terranno nei mesi di Gennaio e Febbraio 2013 inseriti all'interno della più ampia programmazione della Makers University. SONO PREVISTE TARIFFE PROMOZIONALI PER COLORO CHE SI ISCRIVERANNO AI CORSI durante l'OpenDAY.
La lezione e la presentazione si terranno nel nuovo spazio co-working il PEDONE.
PROGRAMMAZIONE
- I temi della Makers University [Leo Sorge];
- Modellazione della parametricTower (concept di architettura complessa) utilizzando Grasshopper, applicativo per la modellazione parametrica [VIDEO] [Michele Calvano];
- Modellazione di una copertura reticolare 3D a completamento della parametricTower con 3dsMax utilizzando tecniche di modellazione mesh complesse [Wissam Wahbeh];
- Rendering con V-ray per 3dsMax illustrando la nuova interfaccia nodale [Wissam Wahbeh].
- Question Time per chiarimenti sugli argomenti illustrati.
COME
L'openDAY sarà aperto a tutti gli interessati,completamente gratuito e sarà replicato in tre sessioni di uguali contenuti organizzate nei seguenti orari:
Sessione [1] 11,30 - 13,30
Sessione [2] 15,30 - 17,30
Sessione [3] 17,30 - 19,30
Per necessità di organizzazione è importante la prenotazione all'evento utilizzando il form in fondo alla pagina specificando nella stringa apposita, il nome dell'evento e la sessione (es. open day sessione 1) oltre agli altri dati richiesti.…
f objects with the main ring body, and that cannot be done in parallel since you are modifying the item once at a time, algorithmically.
The original example of a cylinder and sphere are textbook failures of the Rhino 5 dumb algorithm, since that combination features kissing surfaces that confuse Rhino about where they are intersecting since really in tolerance values they are overlapping along a ribbon instead of a sharp line.
Normally you would slightly move or rescale one of the pair to create a single loop intersection curve that doesn't wander around in jerky fashion trying to combine two surfaces that fail to actually plunge through one another.
Your main Boolean union is 116 prongs with a ring base, and that's slow because Rhino bogs down as the model gets more an more complicated with each internal step, I imagine.
The speed is not all that slow either, only 21 seconds for the Booleans themselves.
If you turn of Grasshopper preview meshing via the toolbar menu it should be significantly faster while you are tweaking the design.
To troubleshoot the slow Boolean, I went into Rhino and tried merely splitting the ring body with the prongs and that itself was just about as slow as the Boolean union, so Rhino is not being badass about it. Then I exploded the ring body and tried splitting just that with the prongs and it was *much* faster to operate on just that single surface! The black box reveals itself a bit.
In kind, splitting the prongs with that single surface was about the same speed as splitting it with the whole ring body, so no speed gain there.
But, to speed up your script, since we *cannot* in fact use parallel processing, we can instead manually create that prong surface by doing our own splits and using Grasshopper's natural order of parts, hopefully consistent, to get rid of the junk.
That prong surface is item 4 of an exploded object.
So I will mutually split them and tease out the good parts from the junk and then rejoin the parts, no Boolean union component needed.
First, I went into your prong cluster and removed the capping, so I have merely an open revolution surface instead of a polysurface, letting me access the surface trim command after quickly finding the BrepBrep intersection curves between the prongs and the single ring surface.
For that Boolean union step I'm down from 11 seconds to 4 seconds, but confusingly we added a second to the Boolean difference that follows:
It's fast since we are manually selecting junk instead of Rhino having to sort which is which, I imagine.
We still have a slow Boolean subtraction of the gems and holes from the finished ring body.
That's not simple so will remain slow and cannot be parallel processed since again there's a single main ring body being modified in each step, and nor are there simple pairs of split object to select from manually to discard junk.
…
long as the component runs, the list gets generated (screenshot below). It's based on a process explained by James Ramsden here.
However, the list is only generated after all inputs are defined, so for components that have certain inputs without default values, the user has to set these inputs before the list gets generated. Is there any way to force the component to generate the list even before the component has been given all input values? Here is sample code for the issue; the list is only generated after input1 has been defined:
using System; using System.Collections.Generic; using Grasshopper.Kernel; using Rhino.Geometry; using System.Drawing; namespace IntraLattice { public class MyComponent1 : GH_Component { GH_Document GrasshopperDocument; IGH_Component Component; public MyComponent1() : base("MyComponent1", "Nickname", "Description", "Category", "Subcategory") { } protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddLineParameter("Input1", "Input1", "An input", GH_ParamAccess.list); pManager.AddIntegerParameter("Input2", "Input2", "The list selection input", GH_ParamAccess.item, 0); } protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddLineParameter("Output", "Output", "Dummy output", GH_ParamAccess.item); } protected override void SolveInstance(IGH_DataAccess DA) { // 0. Generate input menu list Component = this; GrasshopperDocument = this.OnPingDocument(); if (Component.Params.Input[1].SourceCount == 0) TopoSelect(ref Component, ref GrasshopperDocument, 1, 11); // 1. Retrieve/validate input var input1 = new List<Line>(); int input2 = 0; if (!DA.GetDataList(0, input1)) { return; } if (!DA.GetData(1, ref input2)) { return; } var nodes = new List<Point3d>(); var lines = new List<Line>(); // Some dummy code, that will set the output depending on the value selection list // create first point Point3d pt1 = new Point3d(0, 0, 0); Point3d pt2; // set output depending on value list selection if (input2 == 0) pt2 = new Point3d(5, 0, 0); else pt2 = new Point3d(0, 5, 0); // create pt2 Line line = new Line(pt1, pt2); DA.SetData(0, line); } /// The 'index' input represents the input index (first input is index 0) /// The 'offset' parameter is the vertical offset of the menu, to help with positioning /// </summary> public static void TopoSelect(ref IGH_Component Component, ref GH_Document GrasshopperDocument, int index, float offset) { //instantiate new value list var vallist = new Grasshopper.Kernel.Special.GH_ValueList(); vallist.ListMode = Grasshopper.Kernel.Special.GH_ValueListMode.Cycle; vallist.CreateAttributes(); //customise value list position float xCoord = (float)Component.Attributes.Pivot.X - 200; float yCoord = (float)Component.Attributes.Pivot.Y + index * 40 - offset; PointF cornerPt = new PointF(xCoord, yCoord); vallist.Attributes.Pivot = cornerPt; //populate value list with our own data vallist.ListItems.Clear(); var items = new List<Grasshopper.Kernel.Special.GH_ValueListItem>(); items.Add(new Grasshopper.Kernel.Special.GH_ValueListItem("Choice 0", "0")); items.Add(new Grasshopper.Kernel.Special.GH_ValueListItem("Choice 1", "1")); vallist.ListItems.AddRange(items); // Until now, the slider is a hypothetical object. // This command makes it 'real' and adds it to the canvas. GrasshopperDocument.AddObject(vallist, false); //Connect the new slider to this component Component.Params.Input[index].AddSource(vallist); Component.Params.Input[index].CollectData(); } protected override System.Drawing.Bitmap Icon { get { return null; } } public override Guid ComponentGuid { get { return new Guid("{ebc17377-4900-4e14-b33e-0b1c66ef2ade}"); } } } }
Thanks in advance…
he plug-in supports intuitive design of paneling concepts as well as rationalize complex geometry into a format suitable for analysis and fabrication. The plug-in is closely integrated with Rhino 7 and is widely used for architectural and other building designers.
Download
The new PanelingTools for the new Rhino 7.2 is now available. You can access Rhino 7 evaluation and upgrades from here…
Documentation
For documentation and examples, please check:
PanelingTools Manual for detailed description of commands and options.
PanelingTools for Grasshopper Manual includes tutorials and description of PT-GH components.
Paneling Scripting page has a listing of paneling methods for RhinoScript.
Paneling Tutorials page has links to video tutorials.
Paneling Short Clips page has short video tutorials that covers the core functionality of PanelingTools.
Paneling Gallery page has users projects with PanelingTools.
Videos
**NEW** PanelingTools Webinar Course - December 2014 learn how Paneling tools works and how best to integrate it into your design process.
Paneling Tools Webinar - February 11, 2011
Paneling Tools Webinar on Vimeo
Feedback
Please tell us what you think and how you are using PanelingTools to help shape future development.
Join the PanelingTools Group in Rhino Forum and post photos, news and discussions. Make sure to tag with keyword “PanelingTools”.
For questions and feedback, contact the developer.
Source: McNeel Wiki
Keshia C. Stich
Grid Paneling Group
…