he "return" is comment out as shown below?
After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:
Then the blockMesh component gives the following error: seems I have to manually start OF first..
so, as the error message suggested, I open OF by Start_OF.bat:
Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:
... and the blockMesh finished successfully:
... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:
... up to the simpleFoam component, I got the error again:
The warning message 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"
... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.
So, my questions are:
1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
2. what might be the cause of the unsuccessful run of simpleFoam in the end?
Hope you can kindly advise! Thank you!
- Ji
…
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
…
t. So here we go!
1. Honeybee is brown and not yellow [stupid!]...
As you probably remember Honeybee logo was initially yellow because of my ignorance about Honeybees. With the help of our Honeybee expert, Michalina, now the color is corrected. I promised her to update everyone about this. Below are photos of her working on the honeybee logo and the results of her study.
If you think I'm exaggerating by calling her a honeybee expert you better watch this video:
Thank you Michalina for the great work! :). I corrected the colors. No yellow anymore. The only yellow arrows represent sun rays and not the honeybee!
2. Yellow or brown, W[here]TH Honeybee is?
I know. It has been a long time after I posted the initial video and it is not fun at all to wait for a long time. Here is the good news. If you are following the Facebook page you probably now that the Daylighting components are almost ready.
Couple of friends from Grasshopper community and RADIANCE community has been helping me with testing/debugging the components. I still think/hope to release the daylighting components at some point in January before Ladybug gets one year old.
There have been multiple changes. I finally feel that the current version of Honeybee is simple enough for non-expert users to start running initial studies and flexible enough for advanced users to run advanced studies. I will post a video soon and walk you through different components.
I think I still need more time to modify the energy simulation components so they are not going to be part of the next release. Unfortunately, there are so many ways to set up and run a wrong energy simulation and I really don’t want to add one new GIGO app to the world of simulation. We already have enough of that. Moreover I’m still not quite happy with the workflow. Please bear with me for few more months and then we can all celebrate!
I recently tested the idea of connecting Grasshopper to OpenStudio by using OpenStudio API successfully. If nothing else, I really want to release the EnergyPlus components so I can concentrate on Grasshopper > OpenStudio development which I personally think is the best approach.
3. What about wind analysis?
I have been asked multiple times that if Ladybug will have a component for wind study. The short answer is YES! I have been working with EFRI-PULSE project during the last year to develop a free and open source web-based CFD simulation platform for outdoor analysis.
We had a very good progress so far and our rockstar Stefan recently presented the results of the work at the American Physical Society’s 66th annual DFD meeting and the results looks pretty convincing in comparison to measured data. Here is an image from the presentation. All the credits go to Stefan Gracik and EFRI-PULSE project.
The project will go live at some point next year and after that I will release the Butterfly which will let you prepare the model for the CFD simulation and send it to EFRI-PULSE project. I haven’t tried to run the simulations locally yet but I’m considering that as a further development. Here is how the component and the logo looks like right now.
4. Teaching resources
It has been almost 11 months from the first public release of Ladybug. I know that I didn't do a good job in providing enough tutorials/teaching materials and I know that I won’t be able to put something comprehensive together soon.
Fortunately, ladybug has been flying in multiple schools during the last year. Several design, engineering and consultant firms are using it and it has been thought in several workshops. As I checked with multiple of you, almost everyone told me that they will be happy to share their teaching materials; hence I started the teaching resources page. Please share your materials on the page. They can be in any format and any language. Thanks in advance!
I hope you enjoyed/are enjoying/will enjoy the longest night of the year. Happy Yalda!
Cheers,
-Mostapha
…
currently within a fake euphoria framework - blame China/UAE) and a potential decision about doing/developing this or doing that … well …anyway … read and enjoy.
AEC matters: The good, the bad and the ugly.
The bad news: Rhino is NOT suitable for the job (although some use it … but only in the sense that people use Modo for the so called “hard modeling”). By job I mean things up to shop drawing level + specs + you and me (we call it Final level) – nothing to do with sketches and outlines of some abstract “schematic” topology.
The ugly news: The so called Design-Construct approach gains exponentially momentum especially in countries the likes of China/UAE/BRICS (95% of the whole AEC activity worldwide happens there). DeCo means: AEC engineers deliver some kind of study in a preliminary level and the main contractor splits (outsourcers) the job and assigns the study completion AND the construction to various sup-constructors. That thing appeared first – in a large scale - in Dubai 15 years ago. This means that the era of Sergio Pininfarina is over and out: welcome anonymous Toyota designer. In plain English: days of construction corporations fast replacing practices. Dead men walking.
The good news: All AEC related apps (Revit, AECOsim, Allplan and the likes) are in a lethargic state as regards the brave new world (based on the archaic level driven organization schemas etc etc). Of course they all claim the exact opposite and point that support BIM (nobody mention PLM) better than the other guy. But the 21st century – helped by 2 forthcoming unavoidable crisis (a) about shortage of water (b) about transition from carbon to hydrogen economy – isn’t about bureaucracy: think cost/resources optimization and “fitness” rather than China/UAE type of liquid trend. Days of euphoria fast approaching the Wall.
Top to bottom and visa versa.
Old days Titans (Oscar, Mies, Walter, Pierre Luigi, Frank, Eero, blah blah) outlined things (mostly using crayons) and the rest were struggling to translate these in reality in an one way vector like process : Top to bottom that is. These days the inverse gains momentum : when in the whole consider the part … validate … redo … validate … redo. This means bottom to top geared with top-to-bottom. In plain English : child imposes rules to parent and parent imposes rules to child. This means classic MCAD feature/history modeling (CATIA/NX/MS). This is something that Rhino can’t do (not to mention that Rhino is a surface modeler – a rather critical fact).
The parts that are bigger than the whole.
Go there ( http://www.behance.net/gallery/2885057/a-myriad-of-cables) are inspect the whole thing: it’s a parametric nightmare made with the other guy (Generative Components – slower than a Skoda + bugs + why bother?). But the whole (masts and membranes and the likes) means nothing here: focus to the details that are critical for connecting this with that. Complex feature driven solids that are made with internal (on a per se basis) parameters (like fillets required for casting or radius for cable anchoring) whilst they comply with external rules/parameters (cable angles, topology clash issues etc etc). So the whole outlines possibilities … and the part either can follow…or the part must change…or the whole must change. Can you do that with GH/Rhino? And if not what’s missing? (lot’s of things to be honest).
Some other "similar" things:
The narrow picture.
I agree with what others already said and with pretty much all Ola’s points – especially the visual drag-and-drop path mapper (i.e. a visual data manipulator so to speak) and the enable/disable components in groups capability.
Some other suggestions:
A multi canvas capability. As things are right now…it’s like working in Rhino in one view (rather unsuitable I guess). In fact …since overlapping views they don’t work in Rhino…well…you know, he he.
A working auto profile arrangement capability (non twisted Loft/Sweep and the likes). Worth 1Bn dollars that one.
Ability to locate components that caused this or that in the Rhino view: meaning a 2 way communication approach : GH makes things happen in Rhino and things can indicate their cause in the GH canvas.
A robust collection of components that bake stuff in nested blocks (emulating some primitive assembly/component way of thinking). Why may you ask? Well … the whole objective is to talk to CATIA (via STEP) don’t you agree? CATIA makes things happen in real-life not Rhino.
A robust collection of components that can create real-life parametric tensile membrane solutions (get some inspiration from FormFinder: useless because it’s academic but good to point the way). Membranes (and geodesics) are the future.
I could continue at infinitum but IMHO the big picture is worth 12345,67 “focused” GH improvements.
May the Force (the dark option) be with us all.
…
This blog post is a rough approximation of the lecture I gave at the AAG10 conference in Vienna on September 21st 2010. Naturally it will be quite a different experience as the medium is quite…
Added by David Rutten at 3:27pm on September 24, 2010
is set up to manipulate strings into an STL file that is quite different from how Grasshopper defines meshes, in that an STL seems to define each face by XYZ points, Grasshopper wants a single list of all vertex points and then has an allied lists of topological connectivity according to vertex number, so for now I just hacked it to spit out points minus so many duplicates it generates for STL:
Right now it has an internal 3D trigonometric function I added input sliders to control, that creates surfaces that look a lot like molecular orbitals.
So how do I make a mesh? I failed to make a single mesh face from each STL face since AddMesh seems to want a list, so I tried making a single list and matching it with a simple ((1,2,3),(4,5,6),(7,8,9)...) array of connectivity but it hasn't worked yet since the STL list of vertices has duplicates that won't work for Grasshopper and removing the duplicates scrambles the connectivity relation.
After some work on this and seeing the output, I figure I could just randomly populate the mathematical function with points instead, unless it really gives a better mesh result than other routines. I'm not sure what to do with it yet, even if I get the mesh figured out.
import rhinoscriptsyntaximport RhinoPOINTS_CONTAINER =[]POINTS = []class Vector: # struct XYZ def __init__(self,x,y,z): self.x=x self.y=y self.z=z def __str__(self): return str(self.x)+" "+str(self.y)+" "+str(self.z) class Gridcell: # struct GRIDCELL def __init__(self,p,n,val): self.p = p # p=[8] self.n = n # n=[8] self.val = val # val=[8] class Triangle: # struct TRIANGLE def __init__(self,p1,p2,p3): self.p = [p1, p2, p3] # vertices # HACK TO GRAB VERTICES FOR PYTHON OUTPUT POINTS_CONTAINER.append( (p1.x,p1.y,p1.z) ) POINTS_CONTAINER.append( (p2.x,p2.y,p2.z) ) POINTS_CONTAINER.append( (p3.x,p3.y,p3.z) )# return a 3d list of values def readdata(f=lambda x,y,z:x*x+y*y+z*z,size=5.0,steps=11): m=int(steps/2) ki = [] for i in range(steps): kj = [] for j in range(steps): kd=[] for k in range(steps): kd.append(f(size*(i-m)/m,size*(j-m)/m,size*(k-m)/m)) kj.append(kd) ki.append(kj) return ki from math import sin,cos,exp,atan2 def lobes(x,y,z): try: theta = atan2(x,y) # sin t = o except: theta = 0 try: phi = atan2(z,y) except: phi = 0 r = x*x+y*y+z*z ct=cos(PARAMETER_A * theta) cp=cos(PARAMETER_B * phi) return ct*ct*cp*cp*exp(-r/10) def main(): data = readdata(lobes,10,40) isolevel = 0.1 #print(data) triangles=[] for i in range(len(data)-1): for j in range(len(data[i])-1): for k in range(len(data[i][j])-1): p=[None]*8 val=[None]*8 #print(i,j,k) p[0]=Vector(i,j,k) val[0] = data[i][j][k] p[1]=Vector(i+1,j,k) val[1] = data[i+1][j][k] p[2]=Vector(i+1,j+1,k) val[2] = data[i+1][j+1][k] p[3]=Vector(i,j+1,k) val[3] = data[i][j+1][k] p[4]=Vector(i,j,k+1) val[4] = data[i][j][k+1] p[5]=Vector(i+1,j,k+1) val[5] = data[i+1][j][k+1] p[6]=Vector(i+1,j+1,k+1) val[6] = data[i+1][j+1][k+1] p[7]=Vector(i,j+1,k+1) val[7] = data[i][j+1][k+1] grid=Gridcell(p,[],val) triangles.extend(PolygoniseTri(grid,isolevel,0,2,3,7)) triangles.extend(PolygoniseTri(grid,isolevel,0,2,6,7)) triangles.extend(PolygoniseTri(grid,isolevel,0,4,6,7)) triangles.extend(PolygoniseTri(grid,isolevel,0,6,1,2)) triangles.extend(PolygoniseTri(grid,isolevel,0,6,1,4)) triangles.extend(PolygoniseTri(grid,isolevel,5,6,1,4)) def t000F(g, iso, v0, v1, v2, v3): return [] def t0E01(g, iso, v0, v1, v2, v3): return [Triangle( VertexInterp(iso,g.p[v0],g.p[v1],g.val[v0],g.val[v1]), VertexInterp(iso,g.p[v0],g.p[v2],g.val[v0],g.val[v2]), VertexInterp(iso,g.p[v0],g.p[v3],g.val[v0],g.val[v3])) ] def t0D02(g, iso, v0, v1, v2, v3): return [Triangle( VertexInterp(iso,g.p[v1],g.p[v0],g.val[v1],g.val[v0]), VertexInterp(iso,g.p[v1],g.p[v3],g.val[v1],g.val[v3]), VertexInterp(iso,g.p[v1],g.p[v2],g.val[v1],g.val[v2])) ] def t0C03(g, iso, v0, v1, v2, v3): tri=Triangle( VertexInterp(iso,g.p[v0],g.p[v3],g.val[v0],g.val[v3]), VertexInterp(iso,g.p[v0],g.p[v2],g.val[v0],g.val[v2]), VertexInterp(iso,g.p[v1],g.p[v3],g.val[v1],g.val[v3])) return [tri,Triangle( tri.p[2], VertexInterp(iso,g.p[v1],g.p[v2],g.val[v1],g.val[v2]), tri.p[1]) ] def t0B04(g, iso, v0, v1, v2, v3): return [Triangle( VertexInterp(iso,g.p[v2],g.p[v0],g.val[v2],g.val[v0]), VertexInterp(iso,g.p[v2],g.p[v1],g.val[v2],g.val[v1]), VertexInterp(iso,g.p[v2],g.p[v3],g.val[v2],g.val[v3])) ] def t0A05(g, iso, v0, v1, v2, v3): tri = Triangle( VertexInterp(iso,g.p[v0],g.p[v1],g.val[v0],g.val[v1]), VertexInterp(iso,g.p[v2],g.p[v3],g.val[v2],g.val[v3]), VertexInterp(iso,g.p[v0],g.p[v3],g.val[v0],g.val[v3])) return [tri,Triangle( tri.p[0], VertexInterp(iso,g.p[v1],g.p[v2],g.val[v1],g.val[v2]), tri.p[1]) ] def t0906(g, iso, v0, v1, v2, v3): tri=Triangle( VertexInterp(iso,g.p[v0],g.p[v1],g.val[v0],g.val[v1]), VertexInterp(iso,g.p[v1],g.p[v3],g.val[v1],g.val[v3]), VertexInterp(iso,g.p[v2],g.p[v3],g.val[v2],g.val[v3])) return [tri, Triangle( tri.p[0], VertexInterp(iso,g.p[v0],g.p[v2],g.val[v0],g.val[v2]), tri.p[2]) ] def t0708(g, iso, v0, v1, v2, v3): return [Triangle( VertexInterp(iso,g.p[v3],g.p[v0],g.val[v3],g.val[v0]), VertexInterp(iso,g.p[v3],g.p[v2],g.val[v3],g.val[v2]), VertexInterp(iso,g.p[v3],g.p[v1],g.val[v3],g.val[v1])) ] trianglefs = {7:t0708,8:t0708,9:t0906,6:t0906,10:t0A05,5:t0A05,11:t0B04,4:t0B04,12:t0C03,3:t0C03,13:t0D02,2:t0D02,14:t0E01,1:t0E01,0:t000F,15:t000F} def PolygoniseTri(g, iso, v0, v1, v2, v3): triangles = [] # Determine which of the 16 cases we have given which vertices # are above or below the isosurface triindex = 0; if g.val[v0] < iso: triindex |= 1 if g.val[v1] < iso: triindex |= 2 if g.val[v2] < iso: triindex |= 4 if g.val[v3] < iso: triindex |= 8 return trianglefs[triindex](g, iso, v0, v1, v2, v3) def VertexInterp(isolevel,p1,p2,valp1,valp2): if abs(isolevel-valp1) < 0.00001 : return(p1); if abs(isolevel-valp2) < 0.00001 : return(p2); if abs(valp1-valp2) < 0.00001 : return(p1); mu = (isolevel - valp1) / (valp2 - valp1) return Vector(p1.x + mu * (p2.x - p1.x), p1.y + mu * (p2.y - p1.y), p1.z + mu * (p2.z - p1.z)) if __name__ == "__main__": main() # GRASSHOPPER PYTHON OUTPUTPOINTS = rhinoscriptsyntax.AddPoints(POINTS_CONTAINER)POINTS = rhinoscriptsyntax.CullDuplicatePoints(POINTS)…