|
problem when converting mesh (made by ICEM) using fluentMeshToFoam
1 Attachment(s)
Hello all,
I tried to use ICEM to create a hex mesh, and saved it as .msh file, tried to convert the mesh. It was ok when the mesh doesn’t have internal surfaces/walls. When the mesh does include internal surfaces/walls, the conversion doesn’t seem to be working. I had a quick look of the OpenFoam user guide, under section: fluentMeshToFoam, one point made there is: “Fluent allows the user to define a patch which is internal to the mesh, i.e. consists of the faces with cells on both sides. Such patches are not allowed in OpenFoam and the converter will attempt to filter them out” Does this mean the type of the mesh I made is not convertible to OpenFoam? I attached the ICEM files for the test case I made (the .uns file is not included, you can click 'pre-mesh' to see the surface mesh), my application is more complicated than this due to the awkward geometry setup (I am new to OpenFoam, it could be difficult for me to manage the mesh using the OpenFoam provided facility, such as snappyHexMesh). This is just to test the principles. What I did here was to save the mesh to .msh format, and then try to convert it, it failed. Is there any other ways to convert this kind of mesh to the form OpenFoam can use? Thank you for your help Regards Forrest |
1 Attachment(s)
Tried to attached an image of the surface mesh, which may be helpful for your to diagnose without using ICEM to open the attachement from the first post. The mesh will run through the small box in the middle, and its surfaces are internal walls and small openings. Thank you
Forrest |
Hello,
I never tried 3D meshes but I imported 2D-Icem-Meshes without problems take care your msh-file is not binary. Maybe you should try a very simple case first. And use fluent3DMeshToFoam for 3D meshes. Regards, Markus. |
Markus,
Thank you for your inputs here. 3D case is ok, i tried and it was successful, for example, just mesh the middle box without its external domain (ref the image), i was able to convert. I need the external domain to define my case, which is why the surfaces of the small box become internal surfaces. I tried to load this mesh in a commercial solver, it looks fine, the internal surfaces are interpreted with cells on both sides, and these surfaces are available to set boundary conditions. It seems the converting facility 'fluentToFoam' does not allows the internal surfaces like this. But how should I get around this problem? Tried fluent3DMeshToFoam, it doesn't work. Regards Forrest Quote:
|
Below is the error messages, may be helpful when diagnose (it seems reading the pre-defined surfaces ok, but somehow can't find match for first face ,,,, :confused:): Thank you for your help
Forrest // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Dimension of grid: 3 Number of points: 40656 Reading points Number of cells: 37152 Other readCellGroupData: 15 1 9120 1 4 Reading uniform cells number of faces: 116999 Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Reading uniform faces Read zone1:21 name:INTBODY patchTypeID:fluid Reading zone data Read zone1:22 name:int_INTBODY patchTypeID:interior Reading zone data Read zone1:23 name:INTSIDE_4 patchTypeID:wall Reading zone data Read zone1:24 name:INTSIDE_2 patchTypeID:wall Reading zone data Read zone1:25 name:INTSIDE_3 patchTypeID:wall Reading zone data Read zone1:26 name:INTSIDE_1 patchTypeID:wall Reading zone data Read zone1:27 name:INTOPENING1 patchTypeID:wall Reading zone data Read zone1:28 name:INTOPENING2 patchTypeID:wall Reading zone data Read zone1:29 name:INTTOP patchTypeID:wall Reading zone data Read zone1:30 name:INTBOT patchTypeID:wall Reading zone data Read zone1:31 name:EXTTOP patchTypeID:wall Reading zone data Read zone1:32 name:EXTBOT patchTypeID:wall Reading zone data Read zone1:33 name:EXTFRONT patchTypeID:wall Reading zone data Read zone1:34 name:EXTBACK patchTypeID:wall Reading zone data Read zone1:35 name:EXTSIDE1 patchTypeID:wall Reading zone data Read zone1:36 name:EXTSIDE2 patchTypeID:wall Reading zone data FINISHED LEXING dimension of grid: 3 Creating shapes for 3-D cells Cannot find match for first face. cell model: hex first model face: 4(0 4 7 3) Mesh faces: 6 ( 0() 0() 0() 0() 0() 0() ) #0 Foam::error::printStack(Foam::Ostream&) in "/data1/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libOpenFOAM.so" #1 Foam::error::abort() in "/data1/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libOpenFOAM.so" #2 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in "/data1/OpenFOAM/OpenFOAM-1.5/applications/bin/linux64GccDPOpt/fluentMeshToFoam" #3 Foam::create3DCellShape(int, Foam::List<int> const&, Foam::List<Foam::face> const&, Foam::List<int> const&, Foam::List<int> const&, int) in "/data1/OpenFOAM/OpenFOAM-1.5/applications/bin/linux64GccDPOpt/fluentMeshToFoam" #4 main in "/data1/OpenFOAM/OpenFOAM-1.5/applications/bin/linux64GccDPOpt/fluentMeshToFoam" #5 __libc_start_main in "/lib64/libc.so.6" #6 __gxx_personality_v0 in "/data1/OpenFOAM/OpenFOAM-1.5/applications/bin/linux64GccDPOpt/fluentMeshToFoam" From function create3DCellShape(const label cellIndex, const labelList& faceLabels, const labelListList& faces, const labelList& owner, const labelList& neighbour, const label fluentCellModelID) in file create3DCellShape.C at line 186. FOAM aborting Aborted |
Hello,
if you are just going to simulate the flow around the cube there is no need to mesh the inside of the cube. Remove the corresponding block in your ICEM blocking and project the faces onto the cube's surface. Then, you got a surface mesh at the boundaries of your domain (i.e. bottom, sides and cube) and a volume mesh within your domain, but no internal walls. I've created meshes like this (2D and 3D) in ICEM and frequently import them using the fluent3DMeshToFoam without any trouble. It works definitely. Good luck. Jean-Peer. |
Dear Jean-Peer,
Thank you for your reply. Indeed, if there is no mesh inside the small box, the conversion works fine. The problem is, the small box needs to have a mesh, so the fluid can flow into the small box from its small opening there and flow out from the other side. Reading through the user guide, as I mentioned earlier, it says: "Fluent allows the user to define a patch which is internal to the mesh, i.e. consists of the faces with cells on both sides. Such patches are not allowed in OpenFoam and the converter will attempt to filter them out", I am not sure if this is saying that I am not able to convert using this facility, still need to clarify :confused:. Thanks, Forrest Quote:
|
I think the way to get rid of this, regardless of which solver supports what kind of "internal surfaces", "thin walls", "baffle walls"... is to model it as an unambigously valid 3D-fluid domain, which means having a finite thickness of the solid walls of the cube.
If I understand it right, you want to model something like the flow through a cube shaped wreck of a submarine having two bull-eyes open ? So give the submarine hull a finite thickness (as it has) and you are topologically fine. Depending on your skills in ICEM, this is pretty easy (at least with the box), and you might get rid of numerical problems with a thin wall in crossflow. Having the two 90° corners is more physical IMHO. Cheers Olivier |
Hi Olivier,
Thank you for your input. The case I am trying to do is nothing like submarine actually (the principle may well be similar i guess), it will a ventilation problem, a simple shape building geometry in a wind tunnel. The air flows over the building also flows through the building by the designated openings (the actual building model is bit more complicated than the cube). In the past, I was using commercial solvers, was able to set up the walls without a finite thickness. I thought I should be able to do this in OpenFOAM as well, which was why I tried to convert the mesh this way. I could actually add a finite thickness using ICEM without much trouble, but the thickness will be small compared with the overall computational domain, and will the large aspect ratio pose any trouble with the mesh or not I am not quite sure. Thanks Yingchun Quote:
|
The small scale details in large scale domain dilemma :confused: For sure, refining the mesh to the wall thickness causes restrictions on numerics, you have to guarantee smooth cell volume (or edge length) transitions + the courant number limitation.
But following my intuition, such a refinement is to some point necessary to get some physical results for the flow around the doors of the building. Local refinement or unstructured meshes are the most viable solutions to resolve such details well. Pure structured hex forces you to extend the refinements through the domains, except when finding a smart way to use o-grids. Well if you could live with the thin wall assumption from a modeling stand point, you have in fact to struggle with the export-import issues... I just remember all this was quite a pain in the beginning of CFX-5. I suppose they have solved that in the ICEM to CFX work flow meanwhile. Anyway, thin walls always remain a little bit ambiguous in pre-processing. Two ways to go around using finite wall thickness and not to impose thin cells: - Use a larger wall thickness than real so your cells are not too small, I think this is not introducing more modelling errors than the zero thickness assumption. - Make the door cutout sharp while maintaining a wall thickness on the surfaces: Introduce a layer of blocks for the wall, and collapse the correposnding fluid block that is filling the door. The single edge you get, you can project it on the outer or inner door frame edge or create a door-frame midline for this. Do you get what I mean ? We could move to the ICEM Forum with that too :D. |
1 Attachment(s)
Olivier, I did think about this, leaving a finite thickness with walls may be ok, of course, need fiddling around with how thick it should be. The problem is, if I am using the hex meshing in ICEM, I found it was very difficult to ‘pick up’ the unwanted blocks inside the domain. When you try to select, all the blocks show up, selecting a particular block within so many blocks is quite difficult for me and I haven’t found a way to get away with this kind of tedious selection process (Olivier, you might be able to help I guess). Also, the real opening is a circle, and the air inside the cube flows out through the cylinder duct on the top. I used the O-grid to mesh it, attached is just an illustration. Never tried, but if I do give the cylinder a finite thickness, how do I ‘delete’ that ‘block’ within the annular aperture? With finite thickness for the walls, the blocking procedure will be bit more complicated I guess. I didn’t quite follow your second solution, the way you described about how to make the geometry, sounds like it should be easily done by workbench (Design Modeller). We probably shouldn’t open a discussion here, otherwise we may be told ‘ICEM forum is next door’, I loved that part when I read this thread :D : http://www.cfd-online.com/Forums/openfoam-solving/63588-heat-flux-ansys-cfx.html. You gave me a sense of feeling that if I am doing the way I wanted initially, I may end up struggling around here, en…, I thought there should be a standard/straightforward way for doing this… Regards Forrest |
Hi all,
Just to close this thread by saying many thanks to those who applied, and particularly to Olivier, who has been helping me fiddling around with ICEM last few days, learnt quite a lot :) ! The conversion problem was not actually due to the mesh generated by ICEM, it was due to the OF version I was using (1.5). After configured v1.6, use the ‘fluent3DMeshToFoam’, the mesh can be converted properly. ;) Thanks to all and have a good weekend Forrest |
| All times are GMT -4. The time now is 15:12. |