ow the steps of the successful run when step 1.2 is bypassed (note that the and OpenFOAM session is open in the background while running the Butterfly demo file):
1. create wind tunnel, and use different parameters of (4,4) for _globalRefLevel_ as suggested by Theodoro in this post
2. run blockMesh:
3. run snappyHexMesh:
4. run checkMesh:
5. connect the case from checkMesh to simpleFOAM and run the simulation:
6. the simulation converged at 1865 iteration, but the results visualization part has some problem:
7. so I revised this part according to suggestions from Hagit:
8. and the results can be visualized for P and U values:
The GH file used for the successful run shown above is attached here.
Now, the following is the error I got when the case from the update fvScheme component is used for simpleFOAM simulation:
the warning message on the simpleFOAM component is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
The error message from the readMe! output node is attached below as a text file.
Hope you can kindly advise what the important steps or parameters I might have missed here. I assume it might be related to OpenFOAM rather than with the Butterfly workflow...
Thank you very much!
- Ji
…
ed cubics. Only geometrical information i found was on the wikipedia page above.
Grid spacing with ribs of unit length is 1+(1.5*2^0.5) = 3.12 in xyz for the cantitruncated, with alternating grid points used for the different modules (that's why i only use odd numbers of grid points in the GH definition) and a second grid shifted in the three directions with half of the grid spacing.
Second system has the same grid spacing in x and y (not alternating though) and 3 as Z spacing.
The Cartesian coordinate system for the different solids:
Cantitruncated:
http://en.wikipedia.org/wiki/Truncated_cube (±ξ, ±1, ±1), (±1, ±ξ, ±1), (±1, ±1, ±ξ) where ξ = \sqrt2 - 1
http://en.wikipedia.org/wiki/Truncated_cuboctahedron (±1, ±(1+√2), ±(1+√8))
http://en.wikipedia.org/wiki/Truncated_tetrahedron permutations of (±1,±1,±3) with an even number of minus signs
Truncated:
http://en.wikipedia.org/wiki/Cuboctahedron (±1,±1,0) (±1,0,±1) (0,±1,±1)
http://en.wikipedia.org/wiki/Truncated_octahedron All permutations of (0, ±1, ±2)
http://en.wikipedia.org/wiki/Truncated_tetrahedron see above
cheers,
pitrak…
ed to loft between in a consecutive manner ie. between the 1st and 2nd line, between the 2nd and 3rd line, between the 3rd and 4th line etc.
Thus I believe if I can manipulate the list of 10 planar curves into something that looks like the following, I could plug that list into a loft component to create 10 develop-able strips for my pipe!0 | Planar Curve1 | Planar Curve______________1 | Planar Curve2 | Planar Curve______________2 | Planar Curve3 | Planar Curve..._____________8 | Planar Curve9 | Planar CurveBelow are some screen grabs of what I've done so far, if there are better ways to go about this I'm also interested in that.
Cheers, ScottN.B. I know this script functions perfectly fine, I'd just like a script that is not as heavy and can be applied to larger, more complex geometries.
…
e actual method.
Below, I descibe how they work:
1) drag "scheduleDay" onto the canvas
2) drag some Gene Pool lists onto the canvas and connect a number slider - from 0 to 3.
3) connect the Gene Pool list to _genePool input. The component change some important features of the Gene Pool list automatically. Now you have LB_GenePool!!
4) choose the template that it's suitable for you.
5) disconnect LB_GenePool and if templates are not good, you can change them manually
6) drag "Ladybug annual schedule" onto the canvas
7) Connect LB_GenePools to inputs for the days of the week, Epw file and if you want to "_holiday" (in this way you consider holidays). Now you have your simple schedule.
8) a small workflow to visualize it into Rhino..
9) Connect "Ladybug annual schedule" to "Honeybee_Create CSV Schedule" to make your csv Schedule
You could make a schedule more complex than the one in the example above.
You can do that with _analysisPeriod input.
Bests
Antonello…
. Sometimes the result has less "Number of Parts" than what I choose because in the end result I get some of the items as an invalid mesh. For example here I wanted 10 parts but I get only 8 and the rest are invalid.
3. How can connect the results to Octopus and Colibri so it iterate automatically? I want to do optimization through ladybug tools.
Thank you,
…
onstrates the following:
1. The definition's functionality employing HumanUI for the custom user interface.
2. Color based segmentation in manual and auto modes.
3. The evaluation of the definition's ability to handle different point cloud data sets.
This definition performs color based segmentation in two modes.
A manual mode, that implements the Delta-E CIE 2000 color difference formula, for targeted feature detection. An auto mode, that employs a simple RGB Color Range algorithm for quicker preliminary results.
RGB to XYZ to CIELab conversion and Delta-E scripts were based on Colormine's project code from github. Results have been compared and verified with the results of http://colormine.org/color-converter and http://colormine.org/delta-e-calculator/Cie2000.
Each stored class is charted and can be accessed through the UI, as shown at 2:30, where Delta-E CIE 2000, in CieLab color space, output results were found to be in perceptive conformity with human eyes, far superior to the preliminary RGB implementation.
Initial definition versions could process highly subsampled clouds in acceptable timings. Further research showed that employing the multithread processing of Volvox components, bundling the Delta E formula with the RGB to CIE lab color conversion script, per color segmentation calculations for a one million points point cloud would go down from 23 (c# script component) and 8 (vb script component) seconds to approx. 1 second (volvox script cloud component), thus allowing the segmentation of less subsampled point clouds.
I would like to thank Heumann A. and Zwierzycki M. who provided direct support with HumanUI and Volvox. Also Grasshopper3d forum users Maher S. and Segeren P., who contributed with Rhino viewport manipulation scripts.
More on Volvox:
http://papers.cumincad.org/cgi-bin/works/Show?_id=ecaade2016_171&sort=DEFAULT&search=ecaade%20volvox&hits=2629
http://www.food4rhino.com/app/volvox
http://duraark.eu/
HumanUI:
http://www.food4rhino.com/app/human-ui?page=1&ufh=&etx=
ColorMine:
https://github.com/THEjoezack/ColorMine…
onent are experiential or location specific. For example: humidex has been derived and widely used in Canada.Also both humidex and discomfort index should be used in in-shade conditions.For universal applications and locations, you should concentrate on either PET or UTCI (this is what "Outdoor Comfort Calculator" component is based on).
I have found out, that for instance - OutdoorComfortCalculator - which considers temperatures of 9-26 and other factors, gives the % of comfortable time outdoor for instance in Kenya in Africa (high temperatures and humidity) 55%, whereas within the same .epw data and some additional factors added to the Thermal Indices component, the "humidex" or "Discomfort index" give a result drastically lower, I think it was even 1-5% comfortable.How is that?
Yes, this is one of the issues that I have with UTCI index: the authors wanted to make it as an index applicable in any type of climate. To create the UTCI comfort categories a number of data has been collected from different locations (for hot humid climate, it was the data from Madagascar. I may be wrong on this). This resulted in universal comfortable range of 9 to 26 C which you mentioned. How would the people in Madagascar perceive the feel like temperature of 9 degrees as comfortable is beyond my understanding.Thermophysiology of a human in Madagascar, and in Poland is the same. However their acclimatization is quite different, which raises the issue with the upper universal comfortable range. In general people who live in hotter climates have a bit higher tolerance to high temperature than those living in continental climates. And vice-versa: their tolerance to lower temperatures is lower than the tolerance of the people from the continental climates. Here is a comparison of the UTCI - PET stress categories:
UTCI
all climates stress category
above +46 extreme heat stress+38 to +46 very strong heat stress+32 to +38 strong heat stress+26 to +32 moderate heat stress+9 to +26 no thermal stress+9 to 0 slight cold stress0 to -13 moderate cold stress-13 to -27 strong cold stress-27 to -40 very strong cold stressbelow -40 extreme cold stress
PET
(sub)tropical humid climate temperate climate stress categoryabove +42 above +41 extreme heat stress+38 to +42 +35 to +41 strong heat stress+34 to +38 +29 to +35 moderate heat stress+30 to +34 +23 to +29 slight heat stress+26 to +30 +18 to +23 no thermal stress+22 to +26 +13 to +18 slight cold stress+18 to +22 +8 to +13 moderate cold stress+14 to +18 +4 to +8 strong cold stressbelow +14 below +4 extreme cold stress
I attached below an example of PET humid climate comparison with UTCI, for in-shade and out-shade conditions.As it can be seen UTCI shows the percent of time comfortable: two times higher than PET.
Thank you Pin, for the useful comment, on usage of "Analysis period" component.…
na cubierta o una estructura sigue en pie; presentar el router cnc en el evento depende del ejercicio práctico, para mayores informes no duden en escribir a luzyextura@gmail.com o a las oficinas de Bishon en Querétaro
_______________________________________________________
Workshop de arquitectura paramétrica mediante procesos digitales.
El temario incluye aspectos básicos y medios del modelado en Rhino, tanto de dibujo como de objetos en 3D, y las funciones de Grasshopper como una herramienta para el diseño paramétrico.
Al finalizar el curso, los asistentes serán capaces de manejar Rhinoceros y Grasshopper en un nivel medio, también comprenderán todas las herramientas básicas y el estilo de trabajo.
Además del contenido teórico se incluye un ejercicio práctico, que consiste en la producción de un modelo 3D, abarcando desde las ideas generadoras, el diseño, dibujo de piezas para su fabricación y construcción final.
El workshop tiene dos semanas de duración, con un horario de 8 am a 3 pm, el costo para estudiantes es de $4590, para la comunidad en general $4900. 35% descuento antes del 22 de julio
Informes bishion@mail.com, luzytextura@gmail.com.
Teléfono en Querétaro 4422 75 2863
Teléfono en la Ciudad de México 04455 4381 3302…
rawing speed here depends mainly on the speed of a single processor. Get a faster processor, increase the redraw speed.
2) Geometry operations. Such as Piping, Lofting, Curve CP etc. These are all performed by the Rhino core so there's little to be done here. We're continuously working on speeding things up, but they're already pretty fast (considering the complexity of the tasks). Rhino 5 has got a few bits and pieces of multi-threaded code and once we're convinced they're working well we'll probably apply those newly won skills to other parts of the core. These operations are also dependent mainly on processor speed.
3) Autosave operations. Since these involve writing data to the disk, it's very hard to predict whether or not it will be a fast or slow operation.
4) Viewport previews. This code is actually pretty horrible, it could be much faster than it currently is. However, a good Graphics card will make a lot of difference both now and in the future.
The ideal spec for Grasshopper is the same as it is for Rhino:
A) Get a good graphics card. We no longer shun ATI since their latest cards are actually pretty good, so either get a high-end NVidia or ATI card. Good gaming cards are not necessarily good CAD cards. Gaming cards are optimized for triangles and sprites, they don't do particularly well with curves.
B) Memory is dirt cheap, get as much as you can. 4GB being the absolute minimum. But, be sure to get fast-access memory, makes a lot of difference.
C) Get a fast processor. Since neither Rhino nor Grasshopper very much use multi-threading it is important that every single core is fast. I.e., don't get fooled by vendors who add the core speeds together and present that as the processor speed. One core running at 4 GHz is better than 8 cores running at a combined 16GHz.
As for OS, I'd recommend XP Pro or Windows 7. Stay away from Vista if you can. Also, almost all the software and hardware problems I come across at workshops are happening on MacOS machines running some flavour of Windows. Be it parallels, Bootcamp or VMWare.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 11:33am on December 15, 2009
something (C# or components) that does a planer periodic nurbs - any shape imaginable in fact (shown a humble "figure of 8").
2. Imagine a capability (C# only: sorry) to create a "guide" (indicative/intermediate) surface. Basically: patch the nurbs from step 1 against a variety of user controlled curves/points/cats/dogs/you name it.
3. Imagine doing this U/v quad mesh thingy (we can fill the "gaps" [C# only: sorry] with the base boundary easily - especially when triangulating the mesh - but better work as shown):
4. Imagine calling the cavalry (Kangaroo) and instructing to do ... things on that "normalized" mesh.
5. What things? Well ... like equalize edges, "inflate", planarize the quads (extra WOW stuff that one), pull it against the "guide" surface [from step 2] or some other weird ideas of mine.
this is what V2 does (WIP).
more soon
…