, Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation. Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address:
2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component. Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii:
3) A new terrain source has been added: ALOS World 3D 30m. ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range. With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input.
4) 9 new components have been added:
"Address To Location" - finds latitude and longitude coordinates for the given address.
"XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates. "Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates. "Z To Elevation" - finds elevation for particular Rhino point. "Rhino text to number" - convert numeric text from Rhino to grasshopper number. "Rhino unit to meters" - convert Rhino units to meters. "Deconstruct location" - deconstructs .epw location. "New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new developers, even if you contribute a single component to Gismo! "Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it.
5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!!
Basically just forget about this yellow panel:
This panel is not valid anymore, so just use any unit you want.
6) A number of bugs have been fixed, reported in topics for the last couple of weeks. We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!! Apologies if we forgot to mention someone.
The version 0.0.2 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
And example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
Any new suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 5:13pm on March 1, 2017
oftware connections built from the initial seed of the project. As always you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts.
This release is also special since today it is just about 3 years (3 years and 2 weeks) from the first release of Ladybug. As with any release, there have been a number of bug fixes and improvements but we also have some major news this time. In no specific order and to ensure that the biggest developments do not get lost in the extensive list of updates, here are the major ones:
Mostapha is re-writing Ladybug!
Ladybug for DynamoBIM is finally available.
Chris made bakeIt really useful by incorporating an export pathway to PDFs and vector-based programs.
Honeybee is now connected to THERM and the LBNL suite thanks to Chris Mackey.
Sarith has addressed a much-desired wish for Honeybee (Hi Theodore!) by adding components to model electric lighting with Radiance.
Djordje is on his way to making renewable energy deeply integrated with Ladybug by releasing components for modeling solar hot water.
There is new bug. Check the bottom of the post for Dragonfly!
Last but definitely not least (in case you’re not still convinced that this release is a major one) Miguel has started a new project that brings some of Ladybug’s features directly to Rhino. We mean Rhino Rhino - A Rhino plugin! Say hi to Icarus! #surprise
Before we forget! Ladybug and Honeybee now have official stickers. Yes! We know about T-Shirts and mugs and they will be next. For now, you can deck-out your laptops and powerhouse simulation machines with the symbology of our collaborative software ecosystem.
Now go grab a cup of tea/coffee and read the details below:
Rewriting Ladybug!
Perhaps the most far-reaching development of the last 4 months is an effort on the part of Mostapha to initiate a well structured, well documented, flexible, and extendable version of the Ladybug libraries. While such code is something that few community members will interact with directly, a well-documented library is critical for maintaining the project, adding new features, and for porting Ladybug to other software platforms.
The new Ladybug libraries are still under development across a number of new repositories and they separate a ladybug-core, which includes epw parsing and all non-geometric functions, from interface-specific geometry libraries. This allows us to easily extend Ladybug to other platforms with a different geometry library for each platform (ie. ladybug-grasshopper, ladybug-dynamo, ladybug-web, etc) all of which are developed on top of the ladybug-core.
Without getting too technical, here is an example of a useful outcome of this development. If you want to know the number of hours that relative humidity is more than 90% for a given epw, all that you have to code (in any python interface) is the following:
import ladybug as lb
_epwFile = r"C:\EnergyPlusV7-2-0\WeatherData\USA_CO_Golden-NREL.724666_TMY3.epw"
epwfile = lb.epw.EPW(_epwFile)
filteredData = epwfile.relativeHumidity.filterByConditionalStatement('x>90')
print "Number of hours with Humidity more than 90 is %d "%len(filteredData.timeStamps)
Compare that to the 500 + lines that you would have had to write previously for this operation, which were usually tied to a single interface! Now let’s see what will happen if you want to use the geometry-specific libraries. Let’s draw a sunpath in Grasshopper:
import ladybuggrasshopper.epw as epw
import ladybuggrasshopper.sunpath as sunpath
# get location data form epw file
location = epw.EPW(_epwFile).location
# initiate sunpath based on location
sp = sunpath.Sunpath.fromLocation(location, northAngle = 0, daylightSavingPeriod = None, basePoint =cenPt, scale = scale, sunScale = sunScale)
# draw sunpath geometry
sp.drawAnnualSunpath()
# assign geometries to outputs
...
Finally we ask, how would this code will look if we wanted to make a sunpath for dynamo? Well, it will be exactly the same! Just change ladybuggrasshopper in the second line to ladybugdynamo! Here is the code which is creating the sunpath below.
With this ease of scripting, we hope to involve more of our community members in our development and make it easy for others to use ladybug in their various preferred applications. By the next release, we will produce an API documentation (documentation of all the ladybug classes, methods and properties that you can script with) and begin making tutorials for those interested in getting deeper into Ladybug development.
LADYBUG
1 - Initial Release of Ladybug for Dynamo:
As is evident from the post above, we are happy to announce the first release of Ladybug for Dynamo! You can download the ladybug package from Dynamo package manager. Make sure to download version 0.0.6 which is actually 0.0.1! It took a number of trial and errors to get it up there. Once you have the file downloaded you can watch these videos to get started:
The source code can be find under ladybug-dynamo repository and (as you can already guess) it is using the new code base. It includes a very small toolkit of essential Ladybug components/nodes but it has enough to get you started. You can import weather files, draw sunpaths and run sunlighthours or radiation analyses.
There are two known issues in this release but neither of them is critical. You need to have Dynamo 0.9.1 or higher installed which you can download from here (http://dynamobuilds.com/). It is recommended that you run the scripts with ‘Manual’ run (as opposed to ‘Automatic’) since the more intense calculations can make Dynamo crash in automatic mode.
To put things in perspective, here is how we would map Ladybug for Dynamo vs Ladybug and Honeybee for Grasshopper on the classic ‘Hype graph’. The good news is that what we learned a lot from the last three years, making development of the Dynamo version easier and getting us to the plateau of productivity faster.
We should also note that the current development of the Dynamo interface is behind that of the Ladybug-Core, which means there are a number of features that are developed in the code but haven’t made their way to the nodes yet. They will be added gradually over the next month or two.
If you’re interested to get involved in the development process or have ideas for the development, follow ladybug on Facebook, Twitter and Github. We will only post major release news here. Facebook, github and twitter will be the main channels for posting the development process. There will also be a release of a new ladybug for Grasshopper soon that will use the came Ladybug-Core libraries as the Dynamo interface [Trying hard not to name it as Ladybug 2].
2 - New Project “Icarus” Provides Ladybug Capabilities Directly in Rhino
Speaking of expanded cross-platform capabilities, the talented Miguel Rus has produced a standalone Rhino Plugin off of the original Ladybug code that has been included in this release. After writing his own core C# libraries, Miguel’s plugin enables users to produce sunpath and run sunlight hours analyses in the Rhino scene without need of opening Grasshopper or engaging the (sometimes daunting) act of visual scripting.
This release includes his initial RHP plugin file. It is hoped that Miguel’s efforts will extend some of the capabilities of environmental design to individuals who are unfamiliar with visual scripting, casting the network of our community into new territory. We need your help spreading the word about Icarus since the people who will benefit the most from it have probably not read this far into the release notes. Also, as the project is in the early stages, your feedback can make a great difference. You can download the current release from this link.
Once you download the zip file. Right click and unblock it. Then extract the files under C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\ folder. Drag and drop the RHP file into Rhino and you should be ready to go. You can either type Icarus in the command line or open it via the panels. Here is a short video that shows how to run a sunlighhours analysis study in Rhino.
3 - BakeIt Input Now Supports a Pathway to PDF +Vector Programs
As promised in the previous release, the BakeIt_ option available on Ladybug’s visual components has been enhanced to provide a full pathway to vector-based programs (like Illustrator and Inkscape) and eases the export to vector formats like PDFs.
This means that the BakeIt_ operation now places all text in the Rhino scene as actual editable text (not meshes) and any colored meshes are output as groups of colored hatches (so that they appear as color-filled polygons in vector-based programs). There is still an option to bake the colored geometries as light meshes (which requires smaller amounts of memory and computation time) but the new hatched capability should make it easier to incorporate Ladybug graphics in architectural drawings and documents like this vector psychrometric chart.
4 - Physiological Equivalent Temperature (PET) Now Available
Thanks to the efforts of Djordje Spasic, it is now possible to compute the common outdoor comfort metric ‘Physiological Equivalent Temperature’ (PET) with Ladybug. The capability has been included with this release of “Thermal Comfort Indices” component and is supported by a “Body Characteristics” component in the Extra tab. PET is particularly helpful for evaluating outdoor comfort at a high spatial resolution and so the next Honeybee release will include an option for PET with the microclimate map workflow.
5 - Solar Hot Water Components Available in WIP
Chengchu Yan and Djordje Spasic have built a set of components that perform detailed estimates of solar hot water. The components are currently undergoing final stages of testing and are available in the WIP tab of this release. You can read the full release notes for the components here.
6 - New Ladybug Graphic Standards
With the parallel efforts or so many developers, we have made an effort in this release to standardize the means by which you interact with the components. This includes warnings for missing inputs and the ability to make either icons or text appear on the components as you wish (Hi Andres!). A full list of all graphic standards can be found here. If you have any thoughts or comments on the new standards, feel free to voice them here.
7 - Wet Bulb Temperature Now Available
Thanks to Antonello Di Nunzio - the newest member of the Ladybug development team, it is now possible to calculate wet bulb temperature with Ladybug. Antonello’s component can be found under the WIP tab and takes inputs of dry bulb temperature, relative humidity, and barometric pressure.
8 - New View Analysis Types
The view analysis component now allows for several different view studies in addition to the previous ‘view to test points.’ These include, skyview (which is helpful for studies of outdoor micro-climate), as well as spherical view and ‘cone of vision’ view, which are helpful for indoor studies evaluating the overall visual connection to the outdoors.
HONEYBEE
1 - Connection to THERM and LBNL Programs
With this release, many of you will notice that a new tab has been added to Honeybee. The tab “11 | THERM” includes 7 new components that enable you to export ready-to-simulate Lawrence Berkeley National Lab (LBNL) THERM files from Rhino/Grasshopper. THERM is a 2D finite element heat flow engine that is used to evaluate the performance of wall/window construction details by simulating thermal bridging behavior. The new Honeybee tab represents the first ever CAD plugin interface for THERM, which has been in demand since the first release of LBNL THERM several years ago. The export workflow involves the drawing of window/wall construction details in Rhino and the assigning of materials and boundary conditions in Grasshopper to produce ready-to-simulate THERM files that allow you to bypass the limited drawing interface of THERM completely. Additional components in the “11 | THERM” tab allow you to import the results of THERM simulations back into Grasshopper and assist with incorporating THERM results into Honeybee EnergyPlus simulations. Finally, two components assist with a connection to LBNL WINDOW for advanced modeling of Glazing constructions. Example files illustrating many of the capabilities of the new components can be found in there links.
THERM_Export_Workflow, THERM_Comparison_of_Stud_Wall_Constructions
Analyze_THERM_Results, Thermal_Bridging_with_THERM_and_EnergyPlus
Import_Glazing_System_from_LBNL_WINDOW, Import_LBNL_WINDOW_Glazing_Assembly_for_EnergyPlus
It is recommended that those who are using these THERM components for the first time begin by exploring this example file.
Tutorial videos on how to use the components will be posted soon. A great deal of thanks is due to the LBNL team that was responsive to questions at the start of the development and special thanks goes to Payette Architects, which allowed Chris Mackey (the author of the components) a significant amount of paid time to develop them.
2 - Electrical Lighting Components with Enhanced Capabilities for Importing and Manipulating IES Files
Thanks to the efforts of Sarith Subramaniam, it is now much easier and more flexible to include electric lighting in Honeybee Radiance simulations. A series of very exciting images and videos can be found in his release post.
You can find the components under WIP tab. Sarith is looking for feedback and wishes. Please give them a try and let him know your thoughts. Several example files showing how to use the components can be found here. 1, 2, 3.
3- Expanded Dynamic Shade Capabilities
After great demand, it is now possible to assign several different types of control strategies for interior blinds and shades for EnergyPlus simulations. Control thresholds range from zone temperature, to zone cooling load, to radiation on windows, to many combinations of these variables. The new component also features the ability to run EnergyPlus simulations with electrochromic glazing. An example file showing many of the new capabilities can be found here.
Dragonfly Beta
In order to link the capabilities of Ladybug + Honeybee to a wider range of climatic data sets and analytical tools, a new insect has been initiated under the name of Dragonfly. While the Dragonfly components are not included with the download of this release, the most recent version can be downloaded here. An example file showing how to use Dragonfly to warp EPW data to account for urban heat island effect can also be found here. By the next release, the capabilities of Dragonfly should be robust enough for it to fly on its own. Additional features that will be implemented in the next few months include importing thermal satellite image data to Rhino/GH as well as the ability to warp EPW files to account for climate change projections. Anyone interested in testing out the new insect should feel free to contact Chris Mackey.
And finally, it is with great pleasure that we welcome Sarith and Antonello to the team. As mentioned in the above release notes, Sarith has added a robust implementation for electric light modeling with Honeybee and Antonello has added a component to calculate wet bulb temperature while providing stellar support to a number of people here on the GH forum.
As always let us know your comments and suggestions.
Enjoy!
Ladybug+Honeybee development team
PS: Special thanks to Chris for writing most of the release notes!…
en la práctica de nuevos métodos de diseño y fabricación utilizando herramientas digitales. Estos procedimientos emergentes están cambiando radicalmente la manera en que nos aproximamos al proceso de diseño en términos de concepción y producción. Los participantes serán introducidos en el uso de softwares de modelado 2d y 3d para la generación de geometrías que serán posteriormente mecanizadas in situ en una máquina de control numérico CNC de 3 ejes.
¡AL FINAL DEL CURSO TE LLEVAS TU LÁMPARA A CASA!
Profesores: Equipo MEDIODESIGN* + TOOLINGROUP*
*Official Rhino Trainners. Acreditación otorgada por McNeel, desarrolladores del software Rhinoceros.
Lugar: Mediodesign. Pallars 85-91 5-2 BCN
Duración: 16 / 20 horas
Fecha: sábado 9 / domingo 10 julio de 2011
Horario: de 10h a 14h / de 16h a 20h
Plazas: 20 participantes
REQUISITOS
< Dirigido a estudiantes y profesionales de la arquitectura, diseño y profesiones afines.
< Ordenador portátil.
< Softwares instalados. En el momento de la inscripción, los participantes recibirán las instrucciones para la descarga e instalación de versiones gratuitas (trials) de los softwares.
CONTENIDOS
< Introducción al diseño avanzado y la fabricación digital.
< Entorno Rhinoceros y sus plug-ins.
< Herramientas y estrategias de trabajo CNC.
< Materiales y sus características.
< Planteamiento del ejercicio: diseño de una luminaria
< Desarrollo del archivo de RhinoCam para el mecanizado CNC.
< Mecanizado y post-producción.
< Entrega de propuestas: Presentación en formato digital del proceso de diseño y fabricación (pdf, powerpoint, etc…) y del prototipo de luminaria realizado.
INSCRIPCIONES
Precio: 199 € Materiales incluidos.
Forma de pago: mediante transferencia bancaria.
Límite fecha de inscripción: lunes 4 de julio 2011
Se otorgará certificado de asistencia. …
sando las nuevas tecnologías de la información en la arquitectura para la gestión del conocimiento de sistemas que desarrollen estructuras sustentables, desde los procesos de diseño generativos o algorítmicos. Donde se contempla la P.O.O. (programación orientada a objetos) como nuevo lenguaje de expresión para el arquitecto-diseñador en el siglo XXI.Los talleres están pensados para sigan un hilo conductual en el que al mismo tiempo que se enseña se investiga y experimenta. Por primera vez se contará con diversos miembros de SEED como docentes de forma presencial y por video conferencia, logrando de esta forma acercar a los especialistas que se encuentran en Europa a los asistentes de los talleres sin encarecer los costos.+info:http://www.studioseed.net/ adn-methodology/
Los talleres están dirigidos a personas que tengan o quieran conseguir un perfil alto de innovación, creatividad, flexibilidad: profesionales con actividades de dirección, gerencia, proyectistas, investigadores, así como a estudiantes a partir de 5to semestre en adelante. Cada taller abarca perfiles diversos de profesionales, mientras unos están más orientados a directivos y gerencias, otros más a proyectistas.
LOS TALLERES:FAB DIG I / ITESM – CEM / Estado de México / 20 hrs / 8 – 11 al de diciembre 2011 (En este taller no se aplican descuentos ni becas)PARAMETRIC GREEN HOUSING / Colegio de Arquitectos del estado de Jalisco (Por confirmar Sede) / Guadalajara / 20h + 5h proyecto / 30 enero 2012 al 4 de diciembre 2012FAB DIG II / ITESM – CEM / Estado de México / 30h + 5h proyecto / 8 a 12 febrero 2012TERCERA REVOLUCIÓN INDUSTRIAL: TIC`s + SOSTENIBILIDAD. Procesos y paradigmas emergentes / Querétaro / 20 hrs / 15 al 18 de febrero 2012INTRODUCCIÓN AL DISEÑO GENERATIVO / UAM-azc / DF / 8hrs / 13, 14 de enero (Costo representativo $650, máximo 40 personas, mínimo 15 personas)INTRODUCCIÓN A: SCRIPTING CON GRASSHOPPER ( Python) Y PLUGINS / Estudio SEED México / Estado de México / 30 hrs / 23, 24, 25 febrero y 1,2, 3 de marzo 2012…
Added by SEED studio at 3:30am on November 24, 2011
ding is not for the faint of heart and is quite a significant understanding. However, I don't know what your dealing with, so that may be the way to go about it.
Your component if its "finished" has to supply some sort of results that are then used downstream. AFAIK there isn't a way to "prevent" down stream components from calculating until your finished. They have to get some sort of information or else they'll just be waiting. Considering how the results of those components are likely to be invalid until the information gets calculated, it may be better off supplying them with nulls until you have some actual information to give them.
Anyway, I think that you should think very closely about the structure of your routine, and specifically how it will interact and update itself. The way I'm thinking about it now is that there really isn't anything that's done in the "solve instance" function if you will. Essentially the "solve instance" function would either A) start the reading of the file if no data is found, or B) output some data if it is found. This is an extreme undersimplification, but the simpler you keep this the more likely this will work. Here are a few more "details", i guess, of how I could see this potentially working...
Thread A - Initial call to Solve Instance function
+ Check and see if there are any results that exist from reading your file - at this point there shouldn't be. These results should be stored in some sort of class variable that is accessible to both threads. It might also be a good idea to have some boolean flag that will also be accessible that represents whether your reading/writing those variables.
+ Fire a function in another thread that begins the read process. Note that you'll likely have to do this through a delegate and an invoke call, but I'm not 100% sure
+ Fill in some null values for the variables you must supply
+ Output the nulls, thus finishing the Solve Instance function
Thread B - File Read Function running in separate thread
+ Open up the file. Note that its probably a good idea just to pass the file path (as a string) between the different threads. Leave the creation of the file/text stream to the one thread that's using it.
+ Perform all the necessary reading from the file
+ Copy all your data to the variables that are accessible to both threads.
+ Expire either the solution on either the component in question or (at last resort) the whole canvas. I know expiring the whole canvas is defenitely possible, but it should be possible to just expire the one component that's doing the reading.
Thread A - "Second" call to Solve Instance after being manually expired
+ Check and see if there are any results that exist from reading your file, which there now should be.
+ Output those shared results
+ Clear the last results (or cache them in some way) so that the next time the Solve Instance function is fired, you don't find any results and reread the file.
I think there are a few variations to this that could happen too, including having a separate function for reading and writing through the data that's called using its own delegate/invoke call to make sure that its extra safe.
If you haven't already, you should really look into event driven programming, delegates, and asyncronous messaging. These are going to be the 3 things that you'll need to have a decent hold on to make sure this things works. Just to let you know, debugging these things can be a bitch.…
ght on why this is, and some ideas I have for how to improve things going forward.
MeshMachine grew out of some scripts I started developing over 3 years ago (described here), originally just with the aim of achieving approximately equal edge lengths on a smooth closed triangulated mesh.
As time went on, I kept adding things, such as ways of keeping boundaries and sharp edges fixed, different ways of controlling edge lengths that vary across the surface, and different ways of pulling to surfaces.
I was also still experimenting with different rules for the core remeshing operations, such as valence driven vs angle driven edge flips.
All of these things meant many variables in the script. I wanted to share the work so others could play with it, but not really knowing exactly what people might use it for made it difficult to simplify the interface, so I just exposed most of these variables I was using (actually there were originally even more, but I felt a component with 20+ inputs was excessive, and combined some of them and fixed others to default values).
I've never been happy with that component, but some people want a component that you can just feed a surface and get a mesh with 'nice' triangles, without too much fuss or needing to know anything about how it works, while other people want to be able to vary the density based on proximity to the border, and curvature, and attractor points and see the intermediate results, and model minimal surfaces without pulling to any underlying surface, and...
Since then I did the rewrite from Kangaroo to Kangaroo2, and through that process, and associated conversations with Steve Baer, David Rutten and Will Pearson, my ideas about how to structure libraries and make cleaner more flexible Grasshopper components changed. Much of this centres around using interfaces (in the specific programming sense, not to be confused with UI), because they allow separating code into multiple components, while still allowing to edit parts of it within Grasshopper, and other parts in a proper IDE (because I find the GH code editor is not conducive to writing large amounts of well structured object oriented code).
Towards the end of last year, Dave Stasiuk and Anders Deleuran invited me and Will Pearson over to CITA for a few days of mesh and physics coding and beer drinking. During this time I made the first steps to restructuring MeshMachine to be more modular and interface based like Kangaroo2, instead of one giant script. One of the main motivations for doing this was to make it easier to combine the K2 physics library with the remeshing. However, at the time I hadn't yet released K2, so it didn't make sense to post examples that used those libraries. After the launch of K2, this restructured MeshMachine development has been a bit on the back-burner, but this discussion and Dave Stasiuk's work with Cocoon is inspiring me to pick it up again.
Seeing how you are combining the Cocoon and MeshMachine, and how Dave is also using interfaces in his recent work suggests to me it might be possible to integrate them more smoothly...
…
Thermal Comfort Indices incoming long wave radiation uses Ångström clear sky conditions emissivity coefficient, with Maykut and Church cloudiness factor so that it accounts for cloudy sky conditions. So basically this corrections creates the cloudy (all) skies emissivity coefficient.
I was not aware of the fact that .epw files have been shipped with the horizontalInfraredRadiation. Thank you for posting this information!I took a look at EnergyPlus horizontalInfraredRadiation page.In there they state that: "If it is missing, it is calculated".I am pretty much certain that in Serbia, government weather stations do not record the long-wave radiation data.So I thought that this data is probably recorded in more developed countries, definitively in USA.I replicated the formula provided by mentioned bigladdersoftware.com page in cases when "Horizontal Infrared Radiation Intensity is missing".This is the same Clark and Allen (1978) formula mentioned in upper attached Survey of Sky Effective Temperature Models.pdf, Table 3.Once I checked the differences between the Clark and Allen formula and the horizontalInfraredRadiation from the epw file, they were not actually really close, but the same.I checked for a couple of locations in USA, but also outside of it, for different climates. The results were again the same:
I attached the file below.I must admit that there are also hours when -1/+1 difference Wh/m2 exists, but my guess is that this is due to rounding of the values which is performed by EnergyPlus as shown in the example at bigladdersoftware.com page (0.036, 0.815, 340.6).
So it's either the Clark and Allen formula is super precise and can predict the long wave radiation to be exactly the same as the physically measured value, or .epw weather files are in fact not using physically measured values but calculated ones.My assumption would be that it is the second case.
It seems that the only major difference between the two is that the Maykut and Church model seems to be overestimating the long wave radiation loss to the sky in very cold conditions. Otherwise the models show fairly good agreement
Based on upper assumption, I do not think that we can distinguish whether either of these two incoming long-wave radiation methods is more precise or if the other one overestimates the La values.Thank you too for the knowledge and the shared information!!…
ly 26-27-28-29 (digital fabrication)
The third edition of digitalMed Workshop is structured as a design laboratory. Participants will learn the challenging process of producing ideas, projects and research analysis that are to be developed through specific software and concepts that emerge through the use of mapping, parametric design and digital fabrication.
The workshop will take place in the city of Salerno (Italy) and it will last 11 days structured into 3 intensive weekends: July 13-14-15 (mapping); July 19-20-21-22 (parametric design); July 26-27-28-29 (digital fabrication).
Goals and Objectives:
We aim to make clear the theoretical and technical knowledge in the approach to parametric and generative design and digital fabrication. (From collection and data management, to the manner in which these inform the geometries, to the fabrication of prototypes.)
Participants will also have the opportunity to practice the new knowledge gained in the design laboratory through project work.
Project Theme:
"Urban Field" Identify, study and analyze the system of public spaces in the urban area of the city of Salerno.
Connection, mutation, generation and evolution are the themes to be followed in project work.
Brief Description of Topics:
- Mapping. Our reality, in all its forms, has studied through concepts of the theory of Complex Systems. The techniques that will be used to study events and places of reality, will work for the management, manipulation and visualization of data and information. These will form the basis for project management and driven geometry, conducted during the second phase of the workshop.
- Parametric Design. Introduction to Rhino* and Grasshopper. Specifically, we will explain the concepts with which to work with the software of parametric design and how they function. Through these tools, we will arrive at the definition of systems of mathematical and / or geometrical relationships that are able to generate and govern patterns, shapes and objects that will inform the final design.
- Digital Fabrication. In this phase, participants of the workshop are organized into working groups. Participants have access to materials and conceptual apparatus that will take them directly to the fabrication of the geometries of the project, with the use of software CAD / CAM interface and the use of machines for the digital fabrication.
The DigitalMed workshop is organized by Nomad AREA (Academy of Research & Training in topics of Contemporary Architecture), in collaboration with the City of Salerno, the Order of Architects Province of Salerno and the National Institute of Architecture In / Arch - Campania.
Interested parties may download the Notice of Competition at the address www.digitalmedworkshop.com and fill the pre-registration no later than July 10th 2012.
PRESS OFFICE
Dr. Francesca Luciano
328 61 20 830
fra_luciano@libero.it
For information or subscriptions:
e-mail: info@digitalmedworkshop.com - tel: 089 463126 - 3391542980 …
Accidentally that was very close to some project that I have in mind (using solely C# and not components). On first sight I thought that that could be very easy ... only to discover that's not.
This definition is an over simplified version of the other mentioned (only a C# is maintained that does "preparation" work and some sort of naive "topology" checks: the yellow spheres are used as visual aids to the incompatible struts/R values combos).
You can control the 3 options available from that portion:
In a nutshell ... the Exo W behaves with an odd way (at least in my opinion). In order to get the gist of the issue stick to that portion of the def and forget the rest:
This portion of the def attempts to create an usual Exo mesh using a Line list (cleaned and user controlled as regard the min length) derived from exploded mini voronoi (i.e. brep edges). OK, I can understand the red Exo since due to the nature of voronoi breps there's more than possible the presence of small "struts" that may yield non manifold topologies.
But ... the thing is that Exo W is also red in the other mode (non Voronoi) where struts are quite big and no potential "engulfed" situations may occur:
And when the 2d Gate mode is set to Envelope ... there's cases (R values) where Exo W works as expected and cases that it doesn't.
Anyway ... if anyone has any bright idea, drop a world
best, Peter
…
project below- should I be learning Grasshopper & Rhino or just Rhino first?
I'm trying to panel modules with low tolerances- I've prototyped regular shapes like geodesics and am now looking to experiment with irregular shapes with lots of different panel shapes.
I understand some things are best done through Grasshopper when using Paneling Tools- I'm trying to figure out if I can do what I want to achive with PT alone or should do it through Grasshopper (or some other route).
I’m on the MAC WIP - The module was built in Sketchup - all the components seem to be in order as blocks though am having problems running the ptpanel3dcustom command - thinking maybe a bug in the WIP or something wrong with my input or that I imported the sketchup file the wrong way. (I dropped it in the window) - If the 3D command is run it doesn’t do anything - if 2D (ptpanelgridcustom) it crashes.
The tileing pattern - the green rectangle is a refrence. each tile contains 4 blocks with 3 more nested in each.
How the module tiles.
The other thing I'm trying to do is specify that most of the lines in the panels don’t bend/curve when they are paneled (or something like Cage Edited). For my purposes the length & angles can change while the lines must remain straight.
These images show a test tile to be panneled on a ellipsoid. When the tile is mapped to the grid the lines curve, this is an extreme example but notice allot of tiles far from the hemespheres are also bent slightly.
These two questions have me stumped the most for now. What should I look into get a better handle on these problem areas? Maybe I should try recreating the work on a windows machine? or perhaps I should get started with Grasshopper?
Thanks for reading.
Lu…