e case pictured already: don't bother how this truss is made and never mind that the def attached looks like an "add-on" (no components) - because it could be (so don't get stuck on that, it's irrelevant). In fact since the critical part (the 99% of the whole) if only doable with code ... it makes sense to do the rest with code as well (but that's my personal preference anyway, he he). Note: Balls are excluded from the demo.
You can toggle what "class" of struts is gonna being made with these booleans:
You can vary the sliders and if the code thinks that you make a valid input ... it obeys, he he.
But the big questions are:
1. Can you work with this in some interactive way? I mean vary any slider and ... wait ... for some change. Although the MERO components here are created ONCE and then placed around (minus obviously the tubes) ... they are placed as copies of the "donor" object (not instance definitions) creating a vast "pool" of "unnecessary" data.
2. What happens if you bake these little thingies? What file size you get? Is it OK?
But the bad news are that as I said ... this is ... NOT a task for a novice ... nor you can handle this get-a-truss-and-make-a-MERO-thing goal with half-measures: either you should do it properly ... or abandon ship.
NOTE: Load R file first (nothing is internalized).
Moral: even if this was made with components ... it wouldn't serve much.
best, Peter…
akes the linear regression of the Schroeder integral over 30 dB worth of decay. Whether it is T-15 or T-30, they all seek to estimate the RT, which is always always the time it takes for sound to decay 60 decibels.
The website has benchmarks, for your reference. You can find them under the 'Pachyderm' drop down menu, under 'Benchmarks'.
Your model may well require millions of rays to be accurate. It sounds like a very large space. I'm sorry if that is an unpleasant answer. Sometimes it does help to have a computer with more cores to help with this. I have gotten up to 90% processor usage on a 12 core machine before.
Arthur…
hat differ in shapes, sizes and height the facade would be a mess. Some spaces need some light while other can't have any. I would like to have full freedom of creation inside the building, to make it as functional as possible. Thats why i decided the parametric "skin" solution would be best. Since the location has industrial past (factories made of brick) i decided that brick would give interesting result.
I tried creating the definition on my own but since i lack skill in GH i got some problems (especially multiplication of bricks and the diffrence between each "level" (half a brick on y axis) caused problems for me.
I post my simple sketch explaining the idea of definition i would like to create (sorry about quality):
1 - Brep - I would like to use 25x12x6cm (classic brick) but as well experiment with diffrent shapes - like the one on the right with hole inside - that would give more light. Thats why i think the best solution would be using brep for this definition.
2- Multiplication - biggest problem for me - I don't know how tall the wall would be, what will be the final shape of Brep (brick) and that's why i would like to manipulate this with sliders as well. All the walls are flat (maybe it would be easier to use surface?). As i managed to multiply the bricks easy way i don't know how to gain control over height of the wall - for example that it is 30 bricks high, but has each second row moved on x axis by the distance of 1/2 brick. I tried using Series but with no success. Could you help me with that please?
3 - Rotation - i would like to use image sampler for that so i can "paint" where i want more sun and where i dont need it at all (black and white). The rotation has to be limited to 180 degrees as well. Obviously i didn't get here yet, but i never used image sampler so if you could give me some advice how to use component and how to create such images i would be really grateful.
4 - More of a concept thing - since the connection angles differ from 90 degrees i will have to figure out how to connect the parts of the wall at sides ;).
I would like to ask you for help with the defintion, since i am totally stuck at step 2. I post what i came up with so far. Thank you for your time and help!
PS. I post an image that is pretty similar to one of options i would like to check for my building.
…
oCommonSDK, I modified a working C# component that does something similar (ReduceMesh, written by Andrew Heumann). Both scripts are attached.
Aside from changing the component name and eliminating the P parameter, I made two modifications to the script:1) changed line 87 from private void RunScript(Mesh M, double P, ref object A) to: private void RunScript(Mesh M, ref object A)2) changed line 93 from: Rhino.RhinoApp.RunScript("_-ReduceMesh _ReductionPercentage " + Convert.ToString(P) + " _Enter", false); to: Rhino.RhinoApp.RunScript("_-MatchMeshEdge " + " _Enter", false);When I run the ReduceMesh component, the mesh object I feed it gets baked, the ReduceMesh command is run, the temporary object is deleted, and the reduced mesh result is returned. (Thanks, Andrew).When I run the MatchMeshEdge component, the mesh object I feed it is baked, the MatchMeshEdge command is run, but the temporary object is not deleted and no result is returned. The runtime error reads: "Sequence contains no elements (line 0)". I have a feeling that the command line string I am handing to RunScript is incomplete. When I enter it manually on the Rhino command line I see that it wants a mesh and three parameters. Of course I can hit Enter to accept the default values, but when you invoke a command through RunScript do you have to supply all parameters regardless? Also, where would I find details on the argument types that the command wants? For example, the last parameter reads "RatchetMode=On" or "RatchetMode=Off". How do I know if the type is Bool or the literal string "On" or "Off"?I am a complete novice at this so any help you can provide would be greatly appreciated! …
st sampled into data trees (if not we must "add" them "manually" == code: get this item from Rhino and put it there) into collections.
2. Then we must perform some kind of selection(s) on a per individual item basis and THAT is in 99% of cases "manual" (== code) or on a per "global basis" (hard or soft clusters et all == code). If clusters are hierarchical and some kind of dendrogram is required ... this obviously means ... er ... more code.
3. Doing the 2 we use some kind of input by means of sliders (say pairs of 2: for branches and items) and therefor MAY their values cause slider control issues (== code). For instance IF this slider yields a x event > do this and that to some other sliders.
4. Then perform the "histogram" required and obviously treat this as just a variant (i.e. a possible solution out of a given collection witch is variable) meaning ways to "store" this into parameter(s) (as persistent data). This also requires code.
In a nutshell (and oversimplified): given a collection of "shapes" pick some make the histogram, store the result (or do something with that and store the outcome as well) recall some other for any reason, modify it, stored it ... and then repeat until the end of time (or worst: until you are out of espresso).
As I said: NOT a task for a novice AND NOT a task for someone not familiar with code matters (But I guess that you qualify in both areas, he he).
I do this type of things day in day out (but for real-life AEC purposes) therefor I could make a "simple demo" (add some "" more) but ... well ... you are warned, he he
But in case that you take the wrong decision (you are warned) we must use Skype a bit.…
mplex the models are. If we are running multi-room E+ studies, that will take far longer to calculate.
Rhino/Grasshopper = <1%
Generating Radiance .ill files = 88%
Processing .ill files into DA, etc. = ~2%
E+ = 10%
Parallelizing Grasshopper:
My first instinct is to avoid this problem by running GH on one computer only. Creating the batch files is very fast. The trick will be sending the radiance and E+ batch files to multiple computers. Perhaps a “round-robin” approach could send each iteration to another node on the network until all iterations are assigned. I have no idea how to do that but hope that it is something that can be executed within grasshopper, perhaps a custom code module. I think GH can set a directory for Radiance and E+ to save all final files to. We can set this to a local server location so all runs output to the same location. It will likely run slower than it would on the C:drive, but those losses are acceptable if we can get parallelization to work.
I’m concerned about post-processing of the Radiance/E+ runs. For starters, Honeybee calculates DA after it runs the .ill files. This doesn’t take very long, but it is a separate process that is not included in the original Radiance batch file. Any other data manipulation we intend to automatically run in GH will be left out of the batch file as well. Consolidating the results into a format that Design Explorer or Pollination can read also takes a bit of post-processing. So, it seems to me that we may want to split up the GH automation as follows:
Initiate
Parametrically generate geometry
Assign input values, material, etc.
Generate radiance/ E+ batch files for all iterations
Calculate
Calc separate runs of Radiance/E+ in parallel via network clusters. Each run will be a unique iteration.
Save all temp files to single server location on server
Post Processing
Run a GH script from a single computer. Translate .ill files or .idf files into custom metrics or graphics (DA, ASE, %shade down, net solar gain, etc.)
Collect final data in single location (excel document) to be read by Design Explorer or Pollination.
The above workflow avoids having to parallelize GH. The consequence is that we can’t parallelize any post-processing routines. This may be easier to implement in the short term, but long term we should try to parallelize everything.
Parallelizing EnergyPlus/Radiance:
I agree that the best way to enable large numbers of iterations is to set up multiple unique runs of radiance and E+ on separate computers. I don’t see the incentive to split individual runs between multiple processors because the modular nature of the iterative parametric models does this for us. Multiple unique runs will simplify the post-processing as well.
It seems that the advantages of optimizing matrix based calculations (3-5 phase methods) are most beneficial when iterations are run in series. Is it possible for multiple iterations running on different CPUs to reference the same matrices stored in a common location? Will that enable parallel computation to also benefit from reusing pre-calculated information?
Clustering computers and GPU based calculations:
Clustering unused computers seems like a natural next step for us. Our IT guru told me that we need come kind of software to make this happen, but that he didn’t know what that would be. Do you know what Penn State uses? You mentioned it is a text-only Linux based system. Can you please elaborate so I can explain to our IT department?
Accelerad is a very exciting development, especially for rpict and annual glare analysis. I’m concerned that the high quality GPU’s required might limit our ability to implement it on a large scale within our office. Does it still work well on standard GPU’s? The computer cluster method can tap into resources we already have, which is a big advantage. Our current workflow uses image-based calcs sparingly, because grid-based simulations gather the critical information much faster. The major exception is glare. Accelerad would enable luminance-based glare metrics, especially annual glare metrics, to be more feasible within fast-paced projects. All of that is a good thing.
So, both clusters and GPU-based calcs are great steps forward. Combining both methods would be amazing, especially if it is further optimized by the computational methods you are working on.
Moving forward, I think I need to explore if/how GH can send iterations across a cluster network of some kind and see what it will take to implement Accelerad. I assume some custom scripting will be necessary.…
d the workshop PDF from this link: http://goo.gl/bcvRNH Download event poster from this link: http://goo.gl/Q0KWCM Brief: Cairo is filled with barriers controlling people movements, suppressing them as well as detaining green and public spaces to the extent that most people have been taking these spaces for granted. Public spaces have been for a while the periphery of our daily life. We will explore in this workshop how we can manipulate and alter people’s perception and direct their attention to how these spaces are integral for city life. This exploration will be backed up by intensive technical tutorials introducing computational design and fabrication techniques and tools mainly Rhino, Grasshopper, Geco and Ecotect. Not only will this be the typical technical workshop, but rather you will also have the chance to be guided step by step on how these tools are used through out different design stages in a real world scenario. Design prototypes will be produced through 3D printing, the main workshop output will be a fabricated one to one functional model for one of the designs using our new in-house CNC machine. Tutors (check the PDF for bio): Olga Kovrikova, MArch DIA Alexandr Kalachev, MArch DIA Karim Soliman, MArch DIA Islam Ibrahim, MArch DIA Sherif Tarabishy, B.Sc. AAST Application: Application deadline 1 September 2013 ** For students (undergrad / Master), teachers and PhD proof of status is required (university ID with a date or a certificate of enrollment) to apply for the students package. Packages (choose one of the following in the application form): 1. Standard registration Course fee is 4250 EGP For Students 3500 EGP 2. Early bird registration discounted fee For Professionals 3750 EGP For Students 3000 EGP ** Early bird offer ends on 14 August 2013 3. Group registrations discounted fee (5 or more) For Students 20% off - You will have to fill out an application form here: http://goo.gl/0QxAga - You will need to submit your CV and Short Portfolio (max. 10 MB) to info@morph-d.com, email subject: “Morphing Norms Application” (we will decide if you are eligible for an early bird discount or not based on the date of your email submission) - We will confirm receiving emails from all applicants. Successful applicants will be contacted 5 days after each deadline (early bird/final) and will have to confirm participation within 3 days, if they fail to do so, places will be given to others on the waiting list. - A maximum of 30 applicants will be selected.
…
ou will see all of the available components on a ribbon at once so there is no need to keep clicking drop down menus.
It's all about discoverability with GH. What if you're a beginner and don't know about the Create Facility (dbl click canvas) how can you find Extr?
Even if you hover over every component or use the drop down lists you will not see the name Extr appear anywhere.
Sure it makes sense that Extr is short for Extrude but it's also the Nick Name of Extrude to Point component
So you can easily miss the fact that one has a Distance Input verses a Point Input.
I think I made the move to Icons around about the move from version 0.5 to 0.6, possibly before. I initially thought that I would go back to text because I loved the mono chromatic look of the text but I soon realised that Icons were the way forward. The greatest benefit is speed. You don't need to digest and decipher every component (which is written 90 degrees to the norm).
I'm not saying you should move to Icons forthwith but at least consider that once you have a better knowledge and understanding of GH, Icons will set you free.
My top ten tips that I would highly recommend to anyone wanting to better themselves with GH.
1) Turn on Draw Icons
2) Turn on Draw Fancy Wires
3) Turn on Obscure Components
4) Use the Create Facility like a Command Line eg "Slider=-1<0.75<2" or "Shiftlist=-1"
5) Use Component Aliases to customise your use of the Create Facility eg giving the Point XYZ component an alias of XYZ will bring it up as the first option on the Create Facility as opposed to the other possibilities.
6) Try to answer other people's questions even if it's not relevant to your own area. By looking into solving a problem outside of your comfort zone and then posting your results it is very rewarding but it also lets you see the other approaches that get posted in a new light.
7) Take the time to understand Data/Path structures.
8) Buy a second monitor - There is nothing that can compare to real estate when working in Grasshopper.
9) Read Rajaa Issa's Essential Mathematics
10) Pick a panel in a tab on the ribbon and get to know every component inside and out and then move on. Start with the Sets Tab > List Panel…
till quite rough.
I went through your attached log but it seems to be a successful run, perhaps the error log wasn't attached. In any case, I believe we have identified this issue. The goal of the update fvSchemes component was to apply schemes to finalized meshes in an automatic way. While this is useful for new users it is also a dangerous thing to do in CFD studies.
The component works by relating mesh quality to the mesh non-orthogonality, which the checkMesh component reports. While non-orthogonality is one of the important criteria of mesh quality it does present difficulties on some kind of meshes, especially like the simple cases that BF has been meshing so far.
The example case of simple box buildings in a wind tunnel above for instance will appear as a good quality case for even the lowest of cell-count meshes, simply because it is an orthogonal geometry. That means that checkMesh will probably report low values (imagine an empty blockMesh of 10m blocks has a non-orthogonality of 0) which in turn means that higher order schemes might be paired with actually low quality meshes. This I believe is causing problems.
I posted a possible solution to this here https://github.com/mostaphaRoudsari/Butterfly/issues/57. The idea is that Buttefly provides additional options to the users, enabling them to choose between first-order (faster, more robust, but lower quality schemes) and second-order (slower, less robust, but more accurate) schemes depending on mesh quality, stage of assessment, etc. In cases like the above mesh quality a first-order scheme might provide a better option. To test this I am attaching an fvSchemes file you can use by replacing yours in the /system folder of the case.
As a note however, I would like to stress there is so much that a tool like Butterfly can provide in this area. Meshing is a quite complicated and demanding part of the process, involving a lot of trial and error. Sometimes the problem is just the mesh and not the solution options (GIGO stands true in CFD as well). It does however get easier with experience. The safe advice is the simplest one: when changing solution options doesn't help, refine mesh and run again.
Kind regards,
Theodore.…