|
[Sponsors] |
June 8, 2005, 10:08 |
Boundary conditions problem
|
#1 |
Guest
Posts: n/a
|
i have a cube with a non solid interior, but the faces of the cube are all solid.I start out with a .dat array of a cube and i convert it to stl, which leaves it as a meshed face. Problem is, gambit sees the cube as just one face and I can't set the boundry conditions. is there a way to split up the faces is gambit , tgrid or fluent, or is there a way to set the boundary conditions in any of these programs with the whole cube being just one face? i just need a velocity inlet and a pressure outlet
|
|
June 8, 2005, 16:27 |
Re: Boundary conditions problem
|
#2 |
Guest
Posts: n/a
|
Some possibilities...
(1) Can the cube be rebuilt in GAMBIT, rather than importing the .stl file? Then remesh the new cube? (2) There are settings (I forgot exactly where) during the import of .stl files to check 2D or 3D. Has the appropriate box been checked? (3) Can the .dat be converted to an .xyz file? Then brought into GAMBIT and meshed with face information maintained? (4) How about breaking the cube into virtual faces and then redefining them as real faces? or simply reassembling them into a final virtual volume? |
|
June 8, 2005, 16:50 |
Re: Boundary conditions problem
|
#3 |
Guest
Posts: n/a
|
1) no the cube cannot be rebuilt in gambit, the inside is complicated as it comes froms experimental scanning 2) importing the stl files, the selection for 2D/3D is grayed out so i don't think it matters. 3) I am using IDL to read the dat file into a cubic matrix, which is then convered to vertices and polygons using poly_shade, then used to write the stl file. (after first converting the polygons to triangles) I could theoretically write the file in any format, in ascii, given that i know the format it needs to be written in.(i'm not familiar with .xyz) 4) when it is imported into gambit, It only gives me surfaces. like say i imported a sphere from an stl file, gambit would give me a face that is the complete outside surface of the sphere, but no edges or vertices. i then can stitch the faces and mesh the newly created virtual volume. If there is a way to break down this face into component faces, vertices or edges, i would like to know whow to do it. It seems difficult to do much of anything with the virtual geometry in gambit.
So if you can give me any ideas, i'd appreciate it. thanks so much |
|
June 9, 2005, 10:10 |
Re: Boundary conditions problem
|
#4 |
Guest
Posts: n/a
|
This is a tough problem. I can relate to some of the frustrations you must be going through.
A couple of years ago, we made 3D scans of human mannequins and used a software called Paraform to take the scanned data and convert it to a volume . This was a very laborious process with many crashes and failed conversions. Eventually it became a process of assembling groups of virtual edges into real edges, then assembling them into real and virtual faces, then into virtual volumes, and finally applying a new mesh to the end product. Converting from virtual to real can be done but it is difficult, frustrating, and time consuming. It took a month of 10-hour days to do this and in the end the product was reasonably acceptable. However, it did work and we were able to simulate flow around a human body. We published the results in a conference proceeding manuscript: Li, Jun; Celik, Ismail; Yavuz, Ibrahim; Guffey, Steven E.; Bird, Aaron J. (2003) "The Effect of Turbulence and Scalar Transport Models on Prediction of Worker Exposure to Aerosols." Proceedings of FEDSM'03 4th ASME-JSME Joint Fluids Engineering Conference, Honolulu, Hawaii, USA, July 6-11, 2003. Since then we have had more success using CySlice to get the scans convertable to GAMBIT. Are you using CySlice? or have access to it? One thing we noticed was that the number of "holes" in the geometry that was brought into GAMBIT was related to the resolution at which we scanned. GAMBIT can fix those holes, but I found that this is a process that must be watched carefully or some holes will be left that mess up the connections between edges and faces. Maybe this is something you have already seen. In many cases, zooming into the absolute resolution of GAMBIT was necessary to find edges and faces that were connected... separated by only a small distance (10^-6 is max resolution of GAMBIT, I think). If two edges were near to one another in this way, they could be connected, but if there were more than two, often the *wrong* two would be connected, leaving the third unconnected, but which was connected to other nearby faces/volumes. So when the geometry was meshed, it was not continuous and sometimes this wasn't discovered until attempting to solve the domain. To get around this just took time and patience. Other than the above, I'm afraid there is really nothing more that I can think of. Aaron |
|
June 9, 2005, 10:50 |
Re: Boundary conditions problem
|
#5 |
Guest
Posts: n/a
|
I'm not sure if this helps, but I thought it would throw it out there.
It sounds a lot like some issues a friend of mine was having with CMM data from an aircraft installation. He turned to Rhino 3D (www.rhino3d.com) to get around the problem. I've never used it myself, but I heard it's got some very easy interfaces for cleaning up real-world geometry, and since it's a nurbs modeling tool, if there seems to be a couple data points that are out-of-whack, you can smooth them out. Hope this helps, and good luck, Jason |
|
June 9, 2005, 12:02 |
Re: Boundary conditions problem
|
#6 |
Guest
Posts: n/a
|
Thnaks both of you for your help. I am going to have to look into cyslice and rhino 3d, but I don't think my university has any licences for those. I tried googling that conference precedding manuscript, but i couldn't find it, any chance you could email it to me? I really appreciate it.
Anyone else have any possible solutions to the problem? Thanks |
|
June 10, 2005, 14:00 |
Re: Boundary conditions problem
|
#7 |
Guest
Posts: n/a
|
Would it be possible to use a UDF to set the boundary conditions for this case? if so, any references on how to make udfs?
|
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
mass flow in is not equal to mass flow out | saii | CFX | 12 | March 19, 2018 06:21 |
CG, BICGSTAB(2) : problem with matrix operation and boundary conditions | moomba | Main CFD Forum | 2 | February 17, 2010 04:37 |
Fluent accuracy and boundary conditions | Paolo Lampitella | FLUENT | 0 | June 12, 2008 07:25 |
Problem with Boundary conditions | Mahiboobswamulu | Main CFD Forum | 10 | August 26, 2003 14:24 |
boundary conditions problem | reinaldo kuhn | Phoenics | 1 | March 27, 2003 12:46 |