he "return" is comment out as shown below?
After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:
Then the blockMesh component gives the following error: seems I have to manually start OF first..
so, as the error message suggested, I open OF by Start_OF.bat:
Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:
... and the blockMesh finished successfully:
... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:
... up to the simpleFoam component, I got the error again:
The warning message is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.
So, my questions are:
1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
2. what might be the cause of the unsuccessful run of simpleFoam in the end?
Hope you can kindly advise! Thank you!
- Ji
…
been covered since 0051 (correct me if I'm wrong):
1) Shoot for the moon first -- "Control Panel Mode" which allows for advanced interface design. See Max/MSP for example of modal function. I spent a lot of time laying out control panels so they are nice for clients and team members to look at. I spend a lot of time disabling wire display and dragging sliders and panels and graphs around into nice little clusters. Could be something as simple as a mode that disables the view of all component handles, cleans up graph objects, sliders, etc. I know the Remote Control Panel has been requested over and over again since it disappeared, but honestly it wouldn't be much use to me unless it was a full blown customizable interface. In the meantime I'll stick to my own "Canvas Control Panel" methods. (See below...)
2) More control over graph objects. Right now the bar graph for instance automatically sets the lowest and highest value displayed. Would be nice to be able to set extents manually so that you can compare apples to apples on two different lists that have different extents. Also would love to force the bar graph to show all values along x axis, not just first and last. Same goes for showing the numbers of instances for each value. Now it only shows instance numbers in oddball cases. Would like to force them to show for statistical purposes. Love percentages, but usually I also want accurate tallies. I tend to use a member index sets to generate my own lists.
3) Color input for Vectors -- there are fakey fake workarounds but none that are as versatile as simply having a color input.
4) COLOR INPUT FOR TEXT TAGS -- sorry to yell... this one really frustrates me. I often build interactive feedback systems that involve a lot of different types of data, and it is difficult to convey that input when all text is red (or green when selected).
5) Ability to justify text tags using paragraph controls -- currently default is left-justified. Would like to be able to center text horizontally and vertically, among other things.
6) Ability for text tags to handle multi-line text. Not sure the best way to implement this, but often I find myself wanting to attach 3 items of information to a particular object, and I have to string it all together in one line. Would be great if I could insert a "^M" character that stands for carriage return and have that display as multiline text (used in conjunction with above justification controls).
7) More control over Text panels. Thank you for including justification options... but sadly now it begs the question for margin and header control. Text slammed up against the left edge is pretty unsightly. Moreover, if you have labeled a text box, the drop shadow from the title bar tends to overshadow the first line of text if you have Path display turned off. Would like to add some header space to fix the problem and create a cleaner look.
8) Easier access to text font size. Buried in a Special Font... menu. I want to be able to up up down down (left right left right select start) if you know what I mean.
I guess that's it for now... just the things on the top of my head in this category. Looking forward to installing the new release, have to wait until this major project is over though.
Cheers,
Marc
…
hours/day (40 hours) Future University in Egypt (FUE) Department of Continuing Education(DCE) ________________________________________ The aim of this workshop is to teach participants how to create a parametric housing model which can be associated with day lighting and thermal analysis. Moreover, participant will get the opportunity to develop passively design envelope. The workshop is highly interactive giving different examples that develop a strong understanding of Grasshopper Workflow & different passive strategies using the performance simulation tool (DIVA). The participants are divided into groups to study the different orientations and the final outcomes of each group are presented thus concluding the recommendation strategies for each orientation. At the end of the workshop, each participant will receive a Certificate of Attendance from Future University in Egypt. Target Participants: ‐Professional architects. ‐Master and PhD students. ‐ Last year of undergraduate students (ONLY). Prerequisite: -None, however, a basic Grasshopper & Rhinoceros knowledge is preferred. Used Software:(will be provided by the instructor). ‐Rhino 5 SR 3 ‐Grasshopper 0.90066 ‐DIVA Version 2.1.0.3 ________________________________________ Workshop Outline: 1st DAY (Wednesday 29 Jan): 1.Introduction to passive design strategies (efficient envelope) 2.Introduction to parametric design logic 2nd DAY (Thursday 30 Jan) : 1.Developing technical tools based on reverse engineering technology. 2.Examples for parametric facade design 3rd DAY (Saturday 1 Feb): 1.Enforcing the parametric logics with Grasshopper 2.Introducing the performance simulation tool (DIVA) 4th DAY (Sunday 2 Feb): 1.Facade design using grasshopper ‐Studio work. 2.Associative techniques – Day lighting and thermal simulation 5th DAY (Monday 3 Feb): 1.Final optimization and final results 2.Group work presentation ________________________________________ Participants are required to bring their own laptops. To register: 1.Fill in the application form found in this link: https://docs.google.com/forms/d/18OrcwwDks5-vd0irZITC430bjMVb8I8pdw0i5OefyMg/viewform 2.Kindly pay the workshop fees at FUE DCE Admission or in the Bank account Number of participants is a minimum of 20 and a maximum of 24 ________________________________________ Workshop Trainers: Ayman Wagdy Mohamed Ibrahim Researcher at Sustainable Design research group | AUC Lecturer at Parametric design | AUC M.Sc. Architecture – Architecture and Building Technology| Politecnico Di Milano Haitham Salah Ali Mahmoud Teaching Assistant of Design course | AASTMT Head of design team | YBA Architect Principal and cofounder | Arkan Architect ________________________________________ For any questions or info please do not hesitate to contact us at : Mob. : 01003220017 - 01008551772 Email : Fue_ppd@outlook.com…
Added by ayman wagdy at 12:12pm on January 17, 2014
eroberfläche des Grasshopper Programms
Funktionsprinzip eines grafischen Algorithmus-Editors (Datenfluss)
Unterscheidung von Parametern (Datentypen) und Komponenten (Datenverarbeitung)
Erzeugung, Bearbeitung und Analyse von Geometrie-Typen: Punkte, Vektoren, Linien, Kurven, Flächen (surfaces, brep) und Netze (meshes)
Strukturierung der Daten anhand von Listen und Bäumen
unterschiedliche Verknüpfungsmöglichkeiten von Parametern (data matching)
praxisnahe Grundlagen der Geometrie und Vektorrechnung für generatives Design
effizienter Aufbau von parametrischen Modellen anhand Übungsaufgaben
Auszug von Daten aus Modellen für die Fertigung; Daten aus Tabellen (Excel, CSV) importieren, exportieren
Einsatz von benutzerdefinierten Komponenten (custom components)
Vorkenntnisse: Rhinoceros3d Benutzeroberfläche der Software: Englisch Unterrichtssprache: Deutsch
Details und Anmeldung:
www.vhs-sha.de
click: SUCHE
Kurstitel: GRASSHOPPER
(auch: Kurstitel: RHINO)
Trainer: Peter Mehrtens
Kursdauer: 3 Tage / 8 Stunden pro Tag
Donnerstag, 19.07.2012, 08:00-17:00 Uhr Freitag, 20.07.2012, 08:00-17:00 Uhr Samstag, 21.07.2012, 08:00-17:00 Uhr Ort: Volkshochschule Schwäbisch Hall, im Haus der Bildung
Teilnahmegebühr: 299,00 € Teilnehmerzahl: 5-10 Personen
…
tura significa confrontarsi con l’architettura ‘free-form’, in cui indagare liberamente la generazione di forme, a prescindere da ogni principio compositivo, statico o costruttivo.Il workshop di costruzione è un momento di sperimentazione didattica sulle strutture resistenti per forma, un'occasione per confrontarsi con problemi costruttivi reali, per superare la dicotomia tra progetto e realizzazione, forma e struttura.
Lecture >> 26/04 >> info qui
Dialogo tra architetture organiche nel segno della sostenibilità: il panorama italiano contemporaneo a confronto.
Laboratorio di progettazione >> 27-29 aprile >> + Laboratorio di costruzione >> 4-6 maggio >> info qui …
with Mesh machine (target edge length 8 at 60 iterations).
I had the variable pipes running through cocoon last night, expecting already several hours of calculation time, but unfortunately, my Graphics Card ran out of memory as I clicked the cocoon component. No so clever to click it though, but I realized that I have to furher reduce either the lines (why cant tetgen have a minimum edge length flag? In the manual it reads you must specify a .var File to do that.
A .var file allows you to specify maximum area constraints on facets and maximum length constraints on segments. They are used for mesh refinement.
This however is really unuseful since you cannot just say "No tet can have an edge length shorter than "xx" (somewhat like Meshmachine with the target edge length) but as I understood, works only for specified areas (in the var file).
So I looked at cocoon to simplify the Marching cubes settings. I tweaked them to be not quite rough so that MM can just make it pretty enough to use.
The result is quite pleasing and very close to what I was looking for:
Another approach would be to skip the "Pipe Variable" and replace it by a Curve Charge with all the lines AND several Radii plugged into it. A while ago I noticed you can plug several Radii in, but I couldn't replicate my findings from back then today. However, it seems that the brep charge is super-slow compared to the curve charge.
…
ing on a project that has been left alone for a few months, when I couldn't get it just right and I'm finding myself thoroughly stumped. It was originally manually built in Rhino (see steps below) but I was hoping I could use GH to create better surfaces.
So, what I'm basically asking is if I can build this well using GH, and what approach I should use. It's basically a "c" shape, with a twisted octagonal surface of a varying diameter, but the files are attached.
I built this in Rhino using the following steps:
Drew my two outline curves, used tween curves to create a central line
Arrayed points at equal distances along the central curve, and drew perpendicular lines from these points to the outline curves
Created polygons (8 sided) using the line end points and added curve fillets
Manually rotated each polygon, by +15 degrees each time
Drew 2 edit point curves using opposite points on each polygon, connecting them all in a similar was to lofting
Used Sweep2, with the two twisted curves as the rails, and polygons as the cross sections
Extract isocurves, tweak, rebuild, use end polygon, split by isocurves, to sweep between each set of two isocurves
Tweak, rebuild, tweak, rebuild etc
My issue is that the surfaces this have produced can be a little tight/warped/loose/twisted/generally bad... And I was hoping someone on here could give me a little insight on how you'd approach this problem in GH. I know this is long, and rambling, but it someone could just point me in the right direction I'd be so grateful. I don't need a step-by-step, as I think it'd actually be good for me to figure it out by myself.
Thanks for taking the time to read all this! And any help is so appreciated!…
the displayed geometry is being cut from top and bottom.
How can I solve this issue? I attached image for explanation and grasshopper file.
For display I use following code:
private void RunScript(Point3d point, ref object A) { //Calling trail function to limit "pts" list. trail(); //Incrementing point list pts.Add(point); //Adding points to polyline variable pline.Clear(); pline.AddRange(pts.ToArray()); } // <Custom additional code> //Variables List<Point3d> pts = new List<Point3d>(); Polyline pline = new Polyline(); int limit = 2550; //Function to limit the size of points public void trail(){ if(pts.Count > limit){ pts.RemoveAt(0); } } //Display public override void DrawViewportMeshes(IGH_PreviewArgs args) { args.Display.DrawPolyline(pline, Color.Black, 8); }…
where originally where the polysurface edges (pink in the attached picture) because they are intersecting with the cells as well.
who can help me with an idea how i can prevent from getting the intersection with those edges?
i have used a simple form for demonstration but my real polysurface has alot of sharp edges because initially it was created from mesh.
maybe i can manipulate the initial mesh somehow?
thank a lot for all the rightchess people
…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…