,with OpenfoamV1612+ in Windows 10 64bit.The blockmesh worked good.And the snappyhexmesh crashed in the process.My computer memory is not enough? Or some settings wrong?Could you help me solve this question?/---------------------------------------------------------------------------| ========= | || \ / F ield | OpenFOAM: The Open Source CFD Toolbox || \ / O peration | Version: v1612+ || \ / A nd | Web: www.OpenFOAM.com || \/ M anipulation | |*---------------------------------------------------------------------------*/Build : v1612+Exec : snappyHexMeshDate : Aug 27 2017Time : 09:39:54Host : "default"PID : 13443Case : /home/ofuser/workingDir/butterfly/outdoor_airflownProcs : 1sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //Create time
Create mesh for time = 0
Read mesh in = 2.14 s
Overall mesh bounding box : (-241.5472 -241.4418 0) (496.4376 536.2438 144.8633)Relative tolerance : 1e-06Absolute matching distance : 0.001081851
Reading refinement surfaces.Read refinement surfaces in = 0.01 s
Reading refinement shells.Refinement level 3 for all cells inside around_buildings_area.stlRead refinement shells in = 0 s
Setting refinement level of surface to be consistent with shells.For geometry outdoor_airflow.stl detected 0 uncached triangles out of 120Checked shell refinement in = 0 s
Reading features.Read features in = 0 s
Determining initial surface intersections
Edge intersection testing:Number of edges : 1684728Number of edges to retest : 1684728Number of intersected edges : 5583Calculated surface intersections in = 1.68 s
Initial mesh : cells:554112 faces:1684728 points:576779Cells per refinement level:0 554112
Adding patches for surface regions
Patch Type Region
outdoor_airflow:
6 wall buildings
Added patches in = 0.03 s
Edge intersection testing:Number of edges : 1684728Number of edges to retest : 0Number of intersected edges : 5583Selecting decompositionMethod none
Refinement phase
Found point (127.4452 147.401 72.43167) in cell 402042 on processor 0
Surface refinement iteration 0
Marked for refinement due to surface intersection : 8820 cells.Determined cells to refine in = 3.87 sSelected for refinement : 8820 cells (out of 554112)Edge intersection testing:Number of edges : 1883850Number of edges to retest : 250376Number of intersected edges : 21198Refined mesh in = 1.77 sAfter refinement surface refinement iteration 0 : cells:615852 faces:1883850 points:652499Cells per refinement level:0 5452921 70560
Surface refinement iteration 1
Marked for refinement due to surface intersection : 38502 cells.Determined cells to refine in = 0.04 sSelected for refinement : 40392 cells (out of 615852)Edge intersection testing:Number of edges : 2787132Number of edges to retest : 1118049Number of intersected edges : 85655Refined mesh in = 3.17 sAfter refinement surface refinement iteration 1 : cells:898596 faces:2787132 points:990317Cells per refinement level:0 5432351 486812 306680
Surface refinement iteration 2
Marked for refinement due to surface intersection : 159213 cells.Determined cells to refine in = 0.1 sSelected for refinement : 168471 cells (out of 898596)Edge intersection testing:Number of edges : 6576117Number of edges to retest : 4737635Rhino Model and GH files is in t'he zip file.Please help me solve this question!~~…
I understand.
I think honeybee and ladybug together are already a great design tool. I didn't realize the whole story with CFD and the various ways you have tried. Have a lot of respect for your project and your colleagues that are working on this, and I hope you guys get enough credit just going for it considering just how ambitious your project is. and open-source equivalence of at least 7 percent equity share too :) as in per owners. if you guys can offer 1 year cliff and 4 year vesting I will consider joining your team. just kidding what your team is doing are beyond me.
After checking simulation CFD 2015, I realized that one big advantage for LB+HB is that well, I didnt see a built in feature of taking account for direct solar gain as part of the simulation.
From the tutorials I have seen, they set the reference temperature to the exterior walls, but there is nothing solar. Here is a rather comprehensive video of how to set up for Simulation CFD . From 10:30 you can see that boundary condition for exterior walls is set with a film coefficient and Reference temperature (around 12:30). At 12:33, there is actually a parameter called radiation right below. I check the parameters for that myself and found that it includes emissivity and reference temperature but not watt hour per square meter like we have it with ladybug.
SO even for a software like simulation CFD, which already seems very sophisticated with the pay-as-you-go cloud parallel simulation option and all, I don't see that it is designed for simulating natural ventilation. Since with SIM CFD it seems that one can be precise about everything including heat plumes from artificial lights in terms of watts so I am guessing that there is a way to model in solar gain as some kind of projected geometry somehow but it is pretty clear that there is EXTRA WORK needed to factor in solar gain there.
I think it would be pretty major if there is a way to model solar radiation and CFD for interior/building envelop together because I have not seen that kind of simulation in the industry.
Thank you for the extra ref cayote and coolvent. I will make check them out along with SAM.
p.s. I reread what I wrote and just wanted clearify I sure didn't refer to any of your work with honeybee or ladybug as "artistic illustration." I meant my pretty arrows :)
…
u can still find some wonky behaviour in GH related to datatrees. My experience is that new users quite quickly get the hang of it once they learn that a tree is in fact not a tree but in the first place set of lists, where the path shows how the pieces of data used to be grouped.
Branch Count checking A component has multiple tree inputs, but has different amount of branches, each having branch count > 2. (While I understand the logic of combining multiple trees, I've not once encounted once that combining a component with e.g. an input of 2 branches and an input of 4 branches to give any kind of sensible output.
Desired behaviour: If a component has branches (each being > 2 path count), the component should throw a warning. ("Strict branches behaviour?). For example: take an offset component, with 6 branches of curves and 5 branches of offsets. It is extremely likely that this is the result of an error earlier in the definition. This works however without a problem - the last branch is repeated again, and it's later on quite hard to discover something went wrong.
Checking branch Count The most important numeric is the amount of branches, and the amount of items in the tree. It's desired that the hovers show the amount of data and the amount of branches.
Desired behaviour
Trees with paths of different rank Trees that contain {0;0} and {0} and {0;0;1} is usually a sign of trouble of not well merged trees, faulty C# components, or just nasty coding habits.
Trim as undo graft instead of flatten Having the trim in the context menu would provide an easy way to undo a graft. Right now the easiest way for many people is to flatten it, and then start all over again - while just getting rid of the last index keeps the underlying history and makes it easier to write reuseable pieces of code when you prepend datatrees to it.
Component to get branch by index, not by path Would be great. Suppose you have a grid of points, grouped by row. It would help to show: "look, this is in the first path, it's called {0;0;1}, it's got 10 points, these points are the first row".
Analogue to using list item to show what is the first point, second point, and so on.
Semantic path names (maybe far fetched) But what if we can add a short name of each method that was executed to the path list, so it can show:
{Slider 0; Series 0; Point 0}{Slider 0; Series 0; Point 1}
{Slider 0; Series 0; Point 2}
{Slider 0; Series 0; Point 3}
{Slider 0; Series 1; Point 0}
{Slider 0; Series 1; Point 1}
{Slider 0; Series 1; Point 2}
{Slider 0; Series 1; Point 3}
Make the input/data matching inside components explicit Can we make it even more obvious that a component is not a black box that's executed once, but in fact an iteration machine that tries to make sense of the inputs that's fed to this box?
Show data combination. How data input A relates to data input B and data input C, is currently very implict and is just plain hard to learn., and required the ability to be able to relate the output back to the input. If we can textually or even graphically show what data matching occured inside a component, it would greatly help the understanding (and debugging) of "what's going on here in this component"
A verbose explanation of the data matching in component A
Iteration one: - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0) - Motion: We take the data item from Branch 0, Position 0: (Vector 0,0,0)
Iteration two:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 0, Position 1: (Vector 10,0,0)
Iteration three:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 0, Position 1: (Vector 20,0,0)
etc.
A verbose explanation of the data matching in component B
Iteration one: - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0) - Motion: We take the data item from Branch 0, Position 0: (Vector 0,0,0)
..
Iteration seven:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 7, Position 0: (Vector 0,70,0)
..
Iteration 27:
- Geometry: We take the data item from Branch 0, Position 7: (Point 80,0,0)
- Motion: We take the data item from Branch 2, Position 0: (Vector 0,20,0)
…
will work slightly different from before. Sorry about breaking this, but it proved impossible to improve the selection logic with the fairly ambiguous notation that was implemented already.
Not every change is breaking though and I hope that most simple matching rules will work as before. There will be a McNeel webinar on Wednesday the 6th of November where I discuss the new selection rules (as well as path mapping syntax and relative offsets within one or more data trees). This will be a pretty hard-core webinar aimed at expert users. The event will be recorded so you can always go and watch it later. I figured I'd briefly explain the new selection rules on Ning before I release the update though.
-------------------------------------------------------------------------------
Imagine we have the following data tree, containing a bunch of textual characters:
{0;0} = [a,e,i,o,u,y] {0;1} = [ä,ë,ê,ï,î,ö,ô,õ,ü,û,ÿ,ý] {1;0} = [b,c,d,f,g,h,j,k,l,m,n,p,q,r,s,t,v,w,x,z] {1;1} = [ç,ĉ,č,ĝ,ř,š,ş,ž]
There are a total of four branches {0;0}, {0;1}, {1;0} and {1;1}. The first branch contains all the vowels that are part of the standard English alphabet. The second branch contains all non-standard vowels and branches three and four contain the standard and non-standard consonants respectively.
So what if we want to select from this tree only the standard vowels? Basically include everything in the first branch and disregard everything else. We can use the [Tree Split] component with a selection rule to achieve this:
{0;0}
This selection rule hard-codes the number zero in both tree path locations. It doesn't define an item index rule, so all items in {0;0} will be selected.
If we want all the vowels (both standard and non-standard), then we have several options:
{0;?} = select all branches that start with 0
{0;(0,1)} = select all branches that start with 0 and end in either 0 or 1
{0;(0 to 1)} = ......................................... and end in the range 0 to 1.
Conversely, selecting all standard vowels and consonants while disregarding all non-standard character can be achieved with rules as follows:
{?;0}
{(0,1);0}
{(0 to 1);0}
It is also possible to select items from each branch in addition to limiting the selection to specific branches. In this case another rule stated in square brackets needs to be appended:
{0;?}[0 to 2]
The above rule will select the first three vowels from the standard and the non-standard lists.
Basically, rules work in a very consistent way, but there are some syntax conventions you need to know. The first thing to realize is that every individual piece of data in a data-tree can be uniquely and unambiguously identified by a collection of integers. One integer describes its index within the branch and the others are used to identify the branch within the tree. As a result a rule for selection items always looks the same:
{A;B;C;...;Z}[i] where A, B, C, Z and i represent rules.
It's very similar to the Path Mapper syntax except it uses square brackets instead of parenthesis for the index (the Path Mapper will follow suit soon, but that won't be a breaking change). You always have to define the path selector rule in between curly brackets. You can supply any number of rules as long as you separate them with semi-colons.
The index rule is optional, but -when provided- it has to be encased in square brackets after the path selection rule(s).
The following rule notations are allowed:
* Any number of integers in a path
? Any single integer
6 Any specific integer
!6 Anything except a specific integer
(2,6,7) Any one of the specific integers in this group.
!(2,6,7) Anything except one of the integers in this group.
(2 to 20) Any integer in this range (including both 2 and 20).
!(2 to 20) Any integer outside this range.
(0,2,...) Any integer part of this infinite sequence. Sequences have to be at least two integers long, and every subsequent integer has to be bigger than the previous one (sorry, that may be a temporary limitation, don't know yet).
(0,2,...,48) Any integer part of this finite sequence. You can optionally provide a single sequence limit after the three dots.
!(3,5,...) Any integer not part of this infinite sequence. The sequence doesn't extend to the left, only towards the right. So this rule would select the numbers 0, 1, 2, 4, 6, 8, 10, 12 and all remaining even numbers.
!(7,10,21,...,425) Any integer not part of this finite sequence.
Furthermore, it is possible to combine two or more rules using the boolean and/or operators. If you want to select the first five items in every list of a datatree and also the items 7, 12 and 42, then the selection rule would look as follows:
{*}[(0 to 4) or (6,11,41)]
The asterisk allows you to include all branches, no matter what their paths looks like.
It is at present not possible to use the parenthesis to define rule precedence, rules are always evaluated from left to right. It is at present also not possible to use negative integers to identify items from the end of a list.
If you want to know more, join the Webinar on Wednesday!
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 8:57pm on November 3, 2013
ndrea Graziano (Co-de-iT) Arch. Salvo Pappalardo (AION architecture) Arch. Giovanni Basile (Officina Ermocrate)
[.] Descrizione:
Modulo 1 Il workshop è finalizzato a fornire ai partecipanti i fondamenti della modellazione parametrica e generativa attraverso Grasshopper, plug-in di programmazione visuale per Rhinoceros 3D (uno dei più diffusi modellatori NURBS per l‘architettura e il design). Il workshop mira a gestire e sviluppare il rapporto tra informazione e geometria lavorando sui sistemi di involucro in condizioni specifiche. La discretizzazione di superfici (pannellizazione sia Nurbs che Mesh), la modellazione delle geometrie attraverso informazioni (siano esse provenienti da dati di analisi ambientali, da mappe di colore o da database), l’estrazione e la gestione di informazioni richiedono la comprensione delle strutture dei dati al fine di definire un processo che va dalla progettazione alla costruzione. I partecipanti impareranno come costruire e sviluppare strutture di dati parametrici per informare geometrie ‘data-driven’ e come estrarre le informazioni rilevanti da tali modelli per il processo di costruzione.
Modulo 2 Il workshop, volto a promuovere le nuove tecnologie digitali di supporto alla progettazione e alla fabbricazione, fornirà ai partecipanti, utilizzando Grasshopper, gli strumenti per la preparazione dei modelli 3D di elementi modulari decorativi "bricks & tiles" in argilla la cui successiva prototipazione avverrà tramite fresatura dello stampo con pantografo CNC a 3 assi. Il workshop darà quindi ai partecipanti i fondamenti per l’utilizzo di tale strumento di fabbricazione digitale e si concluderà con la fabbricazione di un proprio modello realizzato durante il corso.
[more info]
[Press Kit]…
ight be able to provide more insight). Whenever you run a new simulation in Radiance, it is not always necessary to re-write all of the initial simulation files from scratch. These initial simulation files include both a .rad geometry file as well as a separate .pts file that contains the test point locations. If all that you are changing in a given parametric run is the locations of the test points (like your case), it is not necessary to re-write (or reinterpret) the entire .rad geometry file. My guess is that there is some type of check for this built into either code Mostapha wrote or radiance functions that Mostapha is calling. As such, it seems that the rad geometry file is not being re-written (or re-interpreted by radiance) completely when all that you change is the test points and this actually seems to be saving you an extra 10 seconds each time that you run the component without changing the materials or the building geometry. Other times (like when you plug in custom radParameters), it seems that it re-writes (or re-interprets) the .rad geometry file from scratch since this file is probably affected by customized rad parameters.
So far, if this explanation is holding, it seems like there would be no concern on your end but I also recognize that the difference between these long and short simulations is giving you radiation results that are ever so slightly different from each other (by my estimates, they differ by about 0.2%). Compared to the other types of assumptions that the radiance model is making, though, these are mere rounding errors that probably originate from the number of decimal places in the vertices of the rad geometry file. Rather than worrying about whether your simulations are giving you the right rounding errors to give you matching results, I would encourage you to instead contemplate how much your radiance results are matching reality given all of the assumptions that you are making about the climate (with the epw file for a "typical" year) and with the number of light bounces in the radiance simulation. To give you an example, I ran your model with a higher quality of simulation type (3 ambient bounces) and this gives you results that differ by 1.1% from the original simulation that you were running with only 2 ambient bounces (this is practically an order of magnitude larger than 0.2%).
To address your unease I will say that, for a long time, I also felt uneasy any time that I encountered something that seemed unpredictable in software that I was using. Once I started coding my own stuff, though, I realized quickly that unpredictable behavior is an unavoidable aspect of all software. There is always a tradeoff between accurate results and the time it takes to get them, which produces a multitude of possible ways to arrive at a solution. Add into this complex situation the fact that you might have an almost infinite number of possible inputs to a given set of code.
Because of the unpredictable multitude of cases, there is no application that is completely free from limitations and assumptions. In this light, what ends up being more important than the actual calculation method used is the social infrastructure that is in place to help understand what is being run under the hood, hence why both Radiance and Honeybee are open source and why we try to build a robust community of support through forums like this one!
-Chris…
n due at the end of march. i am hoping to see if i can do this as a sort of "HIVE MIND" experiment with one or two or more posters to the forum. i have uploaded two files to http://www.formpig.com/nine_bar-FAR and I have the following goals:
1. To "kinematically iterate" various formal building envelopes based upon a 50' x 100' lot that "conform" to the nine bar linkage geometry.
2. This lot would have "setbacks" consisting of two 5' side setbacks, a 10' rear yard setback and a 25' front yard setback. max height on the structure is 32' and the allowable overhangs into the setbacks are 2'. I would like to find a way to use the "nine bar geometry" to construct a series of iterations for "floors", "walls" and "ceilings", which would then be tied to a volumetric (cubic volume), or a total square footage (perhaps based upon two horizontal section cuts) which was based upon a given number that I will provide per local building code.
3. Laid on top of this we would also have "mcmansion ordinance" requirements based upon the pdf enclosed. i expect to have this "tent restriction" data in digital form to upload to ftp shortly.
It would be up to you individually or collectively to determine how best to position this "in the real world" based upon the lot, setbacks, zoning requirements etc. For instance, perhaps the nine bar configuration has its vertices coplanar with the 50' x 100' x 32' envelope restrictions and then the chosen volume is "trimmed' by the setback requirements. Or perhaps the nine-bar configuration is generated completely within the setbacks, or perhaps it is generated 2' outside of the setbacks so as to take advantage of the 2' overhang allowance on the setbacks, etc.
*
Given an opportunity to develop the work in a second phase we would have an opportunity to tie this into various efficiencies such as Bill of Materials (wall floor and ceiling square foot calculations), envelope to volume calculations, solar panel efficiencies (solar orientation and envelope geometry) etc, etc (love to get suggestions for this).
*
I've become /really/ convinced that this would be a /really/ interesting entry based upon my just finishing up Kas Oosterhuis' Towards a New Kind of Building: A Designer's Guide for Non-Standard Architecture". In an ideal world I was hoping that it would be possible to hash this out discussion-wise and then literally passing it around on the list after someone eventually made the first move by tossing out a rough ghx script. My expectation would be to finalize it rapidly in the next two weeks. Something of a contemporary version of a design charette.
However, I realize this may not be workable so if you have experience in this arena and particularly if you think this is a brief that is straighforward enough to be almost literally implemented in Grasshopper, please contact me for any wage and/or contract fee requirements.
I'm getting a bit of a late jump on this but my hope is that with the right participant(s) that I can thrash it together quick enough for the first round.
info@formpig.com…
ies and ideas (in this case agent-based modelling) simply because they are the new cool thing to do and, if we think carefully about how the integration of agent-based modeling will improve the accuracy and usefulness of our models, we are more likely to make lasting contributions through their integration.
For example, it seems vital to me that such agent-based models be grounded in some clear quantifiable observations of human behavior in real buildings as opposed to relying on our own coefficients to represent how valuable we think certain things are to the occupants. I will give an example of two agent-based ideas that I have had - one of which has turned out to seem much more valuable in the long-run because of it's grounding in real-world data and I plan to implement soon.
To start with the more valuable example, ever since I read this awesome book on adaptive thermal comfort (https://books.google.com/books?id=vE7FBQAAQBAJ&printsec=frontcover&dq=adaptive+thermal+comfort&hl=en&sa=X&ved=0ahUKEwjDmO6avNnJAhUD9h4KHXWVBuAQ6AEIHDAA#v=onepage&q=adaptive%20thermal%20comfort&f=false), I have had several ideas for how to integrate the findings of recent comfort surveys into our energy models. Generally, the focus of thermal comfort research seems to be shifting from theoretical human energy balance calculations to surveys of occupant behavior, giving us a lot of great data that helps incorporate these behavioral factors in our energy models. To continue one of the ideas that you mention, Theodore, here is a plot from the book that describes the window-opening behavior of occupants as the indoor temperature increases:
Currently, EnergyPlus does not easily allow you to set such a function for window-opening, as you point out but the incorporation of this behavior seems necessary to produce an accurate model of a naturally ventilated building (since opening all of the windows as soon as the indoor temperature hits 21 C is far from realistic). To get around this, I was thinking of including an option on the nat vent component that will put in a series of IF/THEN nat vent objects that approximate this smooth function through a step function:
IF 19 < indoor temperature < 20 THEN WindowOpening = 10%
IF 20 < indoor temperature < 21 THEN WindowOpening = 15%
IF 21 < indoor temperature < 22 THEN WindowOpening = 21%
IF 22 < indoor temperature < 23 THEN WindowOpening = 35%
...
I am hoping to implement this soon.
To describe the example that I have realized was not so helpful with time, when I was first drafting the idea for high-resolution comfort maps (https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A), I originally thought that I would develop computer models an animations of occupants moving around the thermally diverse space to make themselves more comfortable. Once I started to get into this, however, I realized that the social characteristics of a space usually have a much larger impact on where people place themselves than the thermal characteristics and it is not until the thermal characteristics become very uncomfortable or the presence of other people is completely removed that the thermal environment dominates the movement behavior. Thus, in order to model the occupant behavior, I would have to code in the relative importance of a large number of these social characteristics in relation to thermal comfort, which would have been a process of me simply making up coefficients to produce cool-looking but somewhat meaningless animations. It is only when my nicely-designed thermal environments were aligned with the social/programmatic characteristics of the space that I could argue that I was justifiably adding value since the thermal characteristics were not in contradiction to or being weighted against the social ones. So, in the end, realized that all I needed in order to produce a good design was to align the thermal environment with the placing of program and the agent-based modelling would not have enabled the production of a much better design. This is the reason why the human silhouettes are manually placed in the thermal animations on the youtube playlist in the above link and is the reason why I do not intend to incorporate agent-based modelling in this particular manner.
Let me know your thoughts on this as I realize I may also be looking at this from a narrow perspective that is not informed by all that agent-based modelling has to offer.
-Chris…
ntación en distintos procesos del Diseño.
Se abordaran los conceptos basicos y la metodologia para abordar problemas de diseño a traves del desarrollo de Herramientas Algorítmicas mediante un proceso de programacion visual.
Como plataforma de trabajo se utilizara Rhinoceros+Grasshopper.
Instructor:
Leonardo Nuevo Arenas
Fechas:
17 y 18 de Septiembre de 2011
Lugar:
Calzada del Federalismo Sur No. 135 Altos 3, Frente al Parque Rojo (http://bit.ly/nNOuZ5)
Cupo:
Limitado a 15 plazas
Fecha limite de pago:
Viernes 9 de Septiembre
Importante:
Los participantes deberán traer su propia Laptop con todo el software y actualizaciones (originales o versiones de demostración oficiales) previamente instaladas. (Se fijara una fecha unos días antes para revisas que todos los equipos estén en orden y listos para trabajar). Si planeas venir de fuera de la ciudad contactanos y te pondremos en contacto con otras personas que también vayan a hacerlo para en caso de desearlo puedan compartir su lugar de estancia.
Contacto:
Leo. 33 3956 9209
nuarle@msn.com
Aye. 33 1050 3482
ayeritza.fara@gmail.com…