you working on a PV system which will power a domestic hot water boiler?
To answer your questions:1) Each grasshopper component (ghpython being one of those too) is using grasshopper's data matching algorithm. This algorithm takes care of complex issues which may arise from combining lists with single items, data trees with different number of items per branch and so on.I think there is a way of introducing a call to other processor's threads per each inputted surface, but this will be a very difficult job, as it will require writing a custom data matching algorithm. I do not think I am up to that task.Instead I tried to introduce the multithread only to the final part of the PVsurface component and one of its time consuming parts: calculation of sun angles, solar radiation and ac/dc power output.I attached the test file below, but sadly it didn't go well: the multithreaded version mostly runs at the same time as the regular version.I do not think I am qualified enough to answer why is that so, but I think that it may have something to do with the type of the function that the multithreading is applied to: the code is suppose to run few separate functions a couple of thousand times, and work with a couple of lists. From my experience, the multithreading works the best when a single list or two are supplied to a single function. I may be wrong on this.I am very sorry to say that I can not implement this feature.2) I am not familiar if open source PV modules database has been released.But one can always download the data for specific modules from producers websites. It can then easily be transferred to a .csv file or other text file.Ladybug Photovoltaics are based on NREL's PVWatts model.In comparison with other commercial software applications, PVWatts offers a more generalized system model, with some of the values and characteristics being assumed or embedded.The Fuentes empirical thermal model we are currently using follows the same logic: it generalizes the Module characteristics. The following characteristics are only editable: module efficiency, temperature coefficient and module mount type.It may be possible to replace Fuentes with some other, less generalized 5 parameter thermal model. But as an architect, I would definitively need help on this.
Sorry if my reply did not fulfill your expectations, and thank you for the kind words!…
r graphics get saved as 24x24 pixel images before they are put into the grasshopper application, which means the icons look like crap when you zoom in. This is the aforementioned problem that needs to be addressed in GH2. There have historically been two approaches to this issue:
Provide pixel images with several sizes.
Render vector graphics directly.
Option 1 is common for apps that do not have variable levels of zoom, such as Windows Explorer. When explorer shows file icons it either shows them in 16x16, 32x32, 48x48, 96x96, or these days, various HUGE sizes. As a result *.ico files allow you put in different images for all these target sizes. Since Grasshopper has variable zoom levels, this is not an ideal solution. Also, it requires a lot more work per icon.
Option 2 is becoming more and more popular as increased graphics speed now allows for the real-time rendering of vector graphics. Yet, you still need a renderer that knows how to draw vector geometry crisply at low sizes. All vector renderers I know just interpolate the geometry linearly and if a line happens to end up 'between pixels' it's just fuzzy.
I don't have hard and fast rules for the icons, but I try to adhere to at least these:
Keep a border of 2 pixels free around the icon content. So basically only use the inner 20x20 pixels rather than the 24x24 you're allowed. This is needed because the drop shadow needs to go there.
Only draw silhouette edges around shapes, not inner creases. Typically a 1-pixel line will do. I prefer to use a dark version of the fill colour rather than black for edges.
Loose curves can be drawn in 1 or 2 pixel thicknesses, depending on how important the curve is.
Try to avoid text in your icons (not always possible).
Stick to 1 colour family per icon, preferably per icon family. You can add highlights with another colour if you must, but too many hues make an icon hard to read (for the example the [Voronoi] icon, it has red, green and blue and it's a bit of a mess, on the other hand [Colour Wheel] has the full spectrum and seems to work quite well...).
Very roughly speaking, if there's both black and red geometry in an icon, it means the red is component input and the black is component output.
Drop shadows are pixel effects, applied to the 24x24 image. They have a blurring radius of 2 pixels, a horizontal offset of 1 pixel to the right, a vertical offset of 1 pixel to the bottom and they are 65% black.
When you use high contrast shapes (for example black edges on a light background) the anti-aliasing provided by vector renderers such as Xara or Illustrator won't be enough to make it look smooth. I'd recommend avoiding high contrast if at all possible, but if not possible then draw a 1-pixel line around the dark bits in 95% transparent black. This effectively extends the anti-aliasing range from 1.5 to 2.5 pixels and it helps make things looks smoother.
--
David Rutten
david@mcneel.com…
ve Intermediate Insight of Computational Design Strategies While Exploring Rangoli Art form in 2 Dimension and 3Dimesion in which Participants will not only be trained to Digitally Design using Parametric software's but they will also be trained to Fabricate them in reality.
This Course will be explored in manner where Participants will understand inter-dependency of Rhinoceros3D & Grasshoper3D through a unique Hybrid Teaching Method While Exploring Rangoli Geometry .
The course will also take participants through Topics such as - Computational Thinking, - Computational / Parametric Design, - Computational Rangoli Exploration, - Digital Fabrication, - 3D Visualization ( Rhino3D 6), - Making Info-graphics & Design Diagrams ( Rhino3d 6 ).
Participants will also be doing a Project at the last Leg of Workshop in which they will implement the skill they gained in first Few Weeks.
{ Tutor } Nitant Pixelkar (Computational Artist / Designer, Mumbai)
Nitant Hirlekar A.k.a. Pixelkar, is a Computational Artist. He graduated from Rachana Sansad school of Interior Design 2011, Mumbai. In Academics He Bagged Two Gold and One Silver Medal on National Level.
In his post academic days, he came across the Emerging Computational Techniques in Design industry in which Algorithm serves as a main Functional part. He uses Algorithms to Deconstruct the Captured images in Pixelated form using the Grid of the Desired Indian Art Forms.
He Heads Collective Group Named "Mutation Lab” which is a multidisciplinary Design & Art Cell. Where they Explore Computational Approach while Designing Various Scales Spatial Installation, Digital Fabrication, Interactive Installations and Computational Consultancy for Various Architects.
He has exhibited his first artwork in Kalaghoda Arts Festival for in 2014 And further in 2016 and 2017.In 2015 he exhibited in Dharavi Biennale” organized by Wellcome Trust,London & Sneha Organisation, Mumbai Which was internationally acclaimed. In 2016 he got Featured on a TV show - The Creative Indian's as an Absolut Creative Indian of the Week.
Academically he is been involved in Many Computational Design Workshops / Elective Studios for School of Interior Design (Rachna Sansad), LS Raheja College of Architecture & Rat-Lab (Delhi).
{ Participants } The Course is aimed at Architecture, Interior Design, Product Design,Furniture Design & Fashion Design Students and Professionals. However we would be thrilled to have any Interdisciplinary Artist / Creator/ Maker to join the Course as well.
{ Level }
Intermediate
{ Timing } Monday To Friday - 6:00 PM to 9:00 PM (15 Hours/ Week = 5 Week X 15 Hours = 75 Hours )
{ Dates } Registration Ends - 24th April 2020 **Subejct to Availablity
{ Workshop Dates } 4th May 2020 To 5th June 2020
{ Venue } Lower Parel,Mumbai ( Details To Be Announced )
{ Schedule }
{Registration Form}…
well, very similar input data must result in wildly different hashes. For example, imagine we have an algorithm which computes hashes of text, and the hashes it computes are all numbers between 0 and 999. We then apply this algorithm to a piece of text:
"When Spring comes back with rustling shade" = 385
So far so good. Now imagine we change the text slightly, for example by removing a single "l":
"When Spring comes back with rusting shade" = 973
Minor change -> very different hash. There are of course way more unique texts than there are numbers between 0 and 999. This must therefore mean that a lot of text will result in the same hash. For example "When Spring brings back blue days and fair." may also result in a hash of 385. Because of the pigeonhole principle, there is nothing to be done about this.
Now for the tricky bit. Hashes are often used to validate executable code. Say your friend James at MI6 sends you a small program that will allow you to eavesdrop on Angela Merkel, and -over the phone- he tells you the hashcode for that application. You can then hash the application yourself, verify that it indeed results in the same hashcode and then you know you can trust the executable.
But now Jack from the FBI intercepts the email and adds a few sneaky lines of code to the original application allowing him to determine from your internet search history with up to 95% accuracy whether you like extra cheese on your pizza. The application has now been tampered with, it can no longer be trusted and you should be able to figure this out as it will no longer result in the same hash code.
But wait! Some hashing algorithms are more secure than others. MD5 is now officially considered to be 'hacked' and it is no longer recommended for doing naughty spying. Specifically, Jack will be able to inject his own code in such a way that it does not result in a different hash. Instead, the SHA family of hashers are to be used, as it is not yet known how to trick these hashers.
This is where the problem comes in, because apparently the US government has forcefully disabled the use of MD5 for all purposes. This is a shame because I use it to quickly compare bitmap icons for identicalness so I only have to store an icon in memory once. There is no security hole due to this, because I'm not hashing secure data. MD5 is somewhat faster than SHA, and since I have to hash several hundred icons on Grasshopper start, I opted for the faster one.
(Very) long story short; you're hosed. Grasshopper uses MD5; USgov does not like; Grasshopper does not run on USgov computers.
I'll do some testing to see if I can switch to SHA and then we can see whether or not that solves the problem. This however will take a while as I'm going on a business trip next week and have yet to prepare my presentations.
--
David Rutten
david@mcneel.com…
Added by David Rutten at 12:06pm on March 31, 2014
hopper) and High Definition visualizations (V-Ray) and exploring its scientific innovations supporting the users' platform philosophical ideas.
SESSIONS: 5 sessions of 8 hours (40 hours total)
E-MAIL: educacion@chconsultores.net
REGISTRATION: (55) 56 62 57 93
TECHNICAL INFO: 044 (55) 31 22 71 83
INSTRUCTORS: Have past experience working at Gehry Technologies, and participated at studios with Eric Owen Moss and Tom Wiscombe at SCI-Arc (Southern California Institute of Architecture).
Day 1: Introduction to MAYA tools, 3D exercise start.
Day 2: Continue 3D exercise.
Day 3: Original 3D architecture design.
Day 4: Grasshopper optional application on 3D architecture design.
Day 5: V-Ray Application on 3D architecture design.
30 DAY TRIAL SOFTWARE DOWNLOAD:MAYA 2012: http://www.autodesk.com/products/autodesk-maya/free-triaRHINO 4: http://s3.amazonaws.com/files.na.mcneel.com/rhino/4.0/2011-02-11/eval/rh40eval_en_20110211.exe3DS MAX 2010: http://www.autodesk.com/products/autodesk-3ds-max/free-trialVRAY FOR 3DS MAX: http://www.vray.com/vray_for_3ds_max/demo/thankyou.shtml#thankyouPHOTOSHOP e ILLUSTRATOR: https://creative.adobe.com/apps?trial=PHSP&promoid=JZXPS
www.helenico.edu.mx
www.scifi-architecture.com/#!workshops/c1wua
LIKE US ON: www.facebook.com/scifiarchitecture
…
size component supported only ground PV panels and angled roof PV panels.
Download the newest PV SWH system size component from here (Click on "View Raw" to download it. Then move the downloaded .ghuser file to File->Special Folders->User Objects Folder, an confirm to overwrite it with previously located one).
Just a few opinions on the project you are currently working on:This kind of fixed, non-transparent (overhang) PV panels attached to a building facade are vert convenient for locations with higher latitudes.The reason for this is because they (fixed overhang PV panels) are dimensioned according to the sun position at summer solstice. Elevation angles on summer solstice at higher latitude locations are lower, than those of lower latitude locations.Due to Incheon's low latitude (37), you will get rather short length of the PV panels* : less than 10 centimeters (0.097 meters in the attached .gh file below). As you have mentioned, Galapagos needs to be used too.I will just mention some of the good and bad ways in which the upper issue could be somewhat avoided:1) Increasing the vertical distance between PV panels (PV panels appear above every second window).2) Increase the tilt angle. This will increase the length of PV panels also, but will decrease the final annual AC energy output.An example of this solution has been applied at FKI building in Seoul (latitude: 37N):I already did some tests (with tilt angles: 40, 45, 55) and this does not seem like a good solution, though.3) Shrinking the "sun window" by using the minimalSpacingPeriod_ input. In Photovoltaics, a planner is suppose to make the 9h to 15h part of the sun window free of any obstructions. If you try to decrease the "sun window" to 10 to 14h, the length of your PV panels will increase. You can try to experiment a little bit with this (set your minimalSpacingPeriod_ to 21th of June 10 to 14hours). In general, shrinking the sun window on summer solstice is not a good principle during planning.4) Using tracking PV panels, not fixed ones. But Ladybug Photovoltaics components do not support this kind of PV systems. They only support fixed ones.I would personally go with the first option. You can also experiment with the second and third one.Comment back if you have any other questions.-----------------------* By "length of the PV panels" I mean the: tiltedArrayHeight_ input of the PV SWH system size component.…
ed file and code below:
Color ColorAt(Mesh mesh, int faceIndex, double t0, double t1, double t2, double t3) { // int rc = -1; var color = Rhino.Display.Color4f.Black;
if( mesh.VertexColors.Count != 0) { // test to see if face exists if( faceIndex >= 0 && faceIndex < mesh.Faces.Count ) { /// Barycentric quad coordinates for the point on the mesh /// face mesh.Faces[FaceIndex].
/// If the face is a triangle /// disregard T[3] (it should be set to 0.0).
/// If the face is /// a quad and is split between vertexes 0 and 2, then T[3] /// will be 0.0 when point is on the triangle defined by vi[0], /// vi[1], vi[2]
/// T[1] will be 0.0 when point is on the /// triangle defined by vi[0], vi[2], vi[3].
/// If the face is a /// quad and is split between vertexes 1 and 3, then T[2] will /// be -1 when point is on the triangle defined by vi[0], /// vi[1], vi[3]
/// and m_t[0] will be -1 when point is on the /// triangle defined by vi[1], vi[2], vi[3].
MeshFace face = mesh.Faces[faceIndex];
// Collect data for barycentric evaluation. Color p0, p1, p2;
if(face.IsTriangle) { p0 = mesh.VertexColors[face.A]; p1 = mesh.VertexColors[face.B]; p2 = mesh.VertexColors[face.C]; } else { if( t3 == 0 ) { // point is on subtriangle {0,1,2} p0 = mesh.VertexColors[face.A]; p1 = mesh.VertexColors[face.B]; p2 = mesh.VertexColors[face.C]; } else if( t1 == 0 ) { // point is on subtriangle {0,2,3} p0 = mesh.VertexColors[face.A]; p1 = mesh.VertexColors[face.C]; p2 = mesh.VertexColors[face.D]; //t0 = t0; t1 = t2; t2 = t3; } else if( t2 == -1 ) { // point is on subtriangle {0,1,3} p0 = mesh.VertexColors[face.A]; p1 = mesh.VertexColors[face.B]; p2 = mesh.VertexColors[face.D]; //t0 = t0; //t1 = t1; t2 = t3; } else { // point must be on remaining subtriangle {1,2,3} p0 = mesh.VertexColors[face.B]; p1 = mesh.VertexColors[face.C]; p2 = mesh.VertexColors[face.D]; t0 = t1; t1 = t2; t2 = t3; } }
/** double r = t0 * p0.FractionRed() + t1 * p1.FractionRed() + t2 * p2.FractionRed(); double g = t0 * p0.FractionGreen() + t1 * p1.FractionGreen() + t2 * p2.FractionGreen(); double b = t0 * p0.FractionBlue() + t1 * p1.FractionBlue() + t2 * p2.FractionBlue();
ON_Color color; color.SetFractionalRGB(r, g, b);
unsigned int abgr = (unsigned int)color; rc = (int) ABGR_to_ARGB(abgr); **/ var c0 = new Rhino.Display.Color4f(p0); var c1 = new Rhino.Display.Color4f(p1); var c2 = new Rhino.Display.Color4f(p2); float s0 = (float) t0; float s1 = (float) t1; float s2 = (float) t2;
float R = s0 * c0.R + s1 * c1.R + s2 * c2.R; float G = s0 * c0.G + s1 * c1.G + s2 * c2.G; float B = s0 * c0.B + s1 * c1.B + s2 * c2.B; color = new Rhino.Display.Color4f(R, G, B, 1); } } return color.AsSystemColor(); }
…
ort and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about "import geometric data".
However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and "Template" (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). "Templates" are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).
Both "Component " and "Template" are allowed to be imported and exported by using "Import / Export library data" command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).
In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:
1. GH(HB+GB) --> gbXML (both geometric and "Component " and "Template" information) --> DB
This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.
(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25/page,viewtopic/p,13755/#13755)
2. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and "Template" information only) --> DB
If the first way doesn't work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.
I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?
In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?
Thank you again for all your help!
Best,
Ding
DB import
DB export
Template libraries
Component libraries
…
y using the Honeybee_Update Honeybee component.
The video below (best viewed in full-screen mode) provides an idea of what these components are capable of being used for:
The video below shows how these components can be used in an existing Honeybee project (for additional links please open this video in youtube):
I have uploaded two examples as Hydra files that show how these components can be used for grid-point and image-based simulations:
Example1 : Grid Point Calculations
Example2: Image based simulation
Finally, a more esoteric application is demonstrated in this video:
These components are still in the beta-testing stage. Some of the limitations of the components are:
1. Only Type C photometry IES files are supported at present.
2. Rhino is likely to get sluggish if there are too many luminaires (i.e. light fixtures) present in a scene.
3. Due to the spectral limitations of the ray-tracing software (RADIANCE), simulations involving color mixing might not be physically realizable.
Additional details about photometric and spectral calculations are probably an overkill for this forum. However, I'd be glad to answer any related questions. Please report any bugs or request new features either on this forum or on Github.
Mostapha, Leland Curtis, Reinhardt Swart and Dr. Richard Mistrick provided valuable inputs during the development of these components.
Thanks,
Sarith
Update 16th January 2017:
An example with some new components and bug fixes since the initial release announcement can be found here
…
bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Matrix transforms and persistent constraints: I don't think this is true. The parts can have mates to other parts that preserve geometric relationships like 'coincident' , 'aligned' etc. These are essentially bi-directional. GH's algorithmic approach does not do relationships in the same / flexible way. In GH, the 'relationship' has to be part of the generation method that dependent on the creation sequence. I.e. draw line 2 perpendicularly from the end of point of line 1. If you are thinking about parts or assemblies sharing, or referencing parameters as part of the regen process, this is also possible. iLogic does this, and adds scripting. So does Catia. Inventor/iLogic can also access Excel and have all the parameter processing done centrally, if required.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
I wouldn't be too hasty here. Yes, you are right about compartmentalisation. I think this needs to happen with GH, in order to deal with scalability/everyday interoperability requirements. Confining projects to one script is not sustainable. MCAD apps have been doing this for ages with 'Relational Modeling'.The Adaptive Components placement example illustrates that it is beneficial to be able to script some 'hints' that can be used on placement of the component. Say, if your component requires points as inputs, then its should be able to find the nearest points to the cursor as it moves around. I think Aish's D# / DesignScript demo'd this kind of behaviour a few years ago. Similarly, Modo Toolpipe reminds me how a lot of UI based transactions can be captured as scripts (macro recorder etc). Allowing this input to be mixed in and/or extended by GH I think will yield a lot of 'modeling efficiency' around the edges. This is a (mis)using GH as an user-programmable 'jig' for placing/manipulating 'dumb' elements in Rhino. It may even give the 'dumb elements' a bit more 'intelligence' by leaving behind embedded attributes, like links to particular construction planes etc.Even if we confine ourselves to scripting. GH is a visual or graphic programming interface. A lot of 'insert and connect' tasks can be done more easily using graphic methods. If we need to select certain vertices on a mesh as inputs for, say, a facade panel, its going to be quicker to do this 'graphically' (like the AC example), then ferreting out the relevant indices in the data tree et al. The 'facade panel' script would then have some coding to filter/prompt the user as to what inputs were acceptable, and so on.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
Not sure what you mean here. If the i-parts are built up using sketches /profiles or other more rudimentary features (like Revits' profile/face etc family templates) then reuse should be fairly straight forward. I suppose you could make it like GH scripting, if you cut and paste or include script snippets that generate the desired Inventor features.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
I don't think this is true. Look at the automotive body design apps, which are mostly Catia based. All of the body parts are pretty much 'generative' and generated from splines, in a procedural way, using very similar approaches to GH. Or sheet metal design. It's not always about configuration of off-the-shelf items like bolts. And, the constraints manager is available to arbitrate which bit of script fires first, and your mundane workaday associative dimensions etc can update without getting run over by the DAG(s) :-)
…