|
[Sponsors] |
December 20, 2000, 15:17 |
Gambit problems
|
#1 |
Guest
Posts: n/a
|
Pretty soon I will give up completely on Gambit. I have spent the last three weeks struggling with: geometry which passes all the checks, looks OK, sometimes even meshes, but is apparently corrupt, trying to use commands which are not greyed out but then getting the message "this function is not implemented yet", deleting .lok files and restarting Gambit because it has given me a fatal exception error (I am used to this but when it happens more than 10 times in any one day it gets a bit wearing), starting again, from the beginning, because a file which I have been working on for two weeks has suddenly developed a problem and can no longer be read by anyone but me (that had the helpdesk foxed for a while), writing out pages of face and edge numbers and not using groups because perfectly good geometry is reported as corrupt when grouped (it was all fine beforehand), limiting my use of rendering because it causes fatal exception errors, limiting my use of copy and translate because it also causes fatal exception errors, pestering my collegues to reproduce their CAD models time and time again because the logical way of producing 360 degree revolutions is unacceptable for imported geometry in Gambit, etc., etc..
Maybe someone out there has some words of hope or comfort for me. Is there light at the end of a tunnel, and is it daylight or just a train coming in the other direction. Maybe there is some other software which can accept Catia geometry, modify it, make additons to it and then generate a suitable mesh for CFD without so much pain. I have been known as an eternal optimist and through thick and thin I have maintained that attitude. But Gambit and this high profile project deadline between them are starting to impinge on that attitude. Best wishes to all in this season of high stress, Althea |
|
December 20, 2000, 23:42 |
Re: Gambit problems
|
#2 |
Guest
Posts: n/a
|
(1). I used to write my own solver, the mesh generation code, and the graphic processor. So, it takes a superman to know all aspects of the CFD phases. (2). Among the most difficult part is the geometry and mesh generation, because 3-D geometry is hard to generate, and a good 3-D mesh is not a trivial task. I have learned this many many years ago. (3). And even if you can generate a good mesh, it still up to the solver to decide whether the mesh is acceptable or not, whether it is consistent with the solution or not. A good looking mesh does not always generate good solutions, because there are other factors such as the physical properties, models, and boundary conditions which can affect the final result. (4). But, I am very glad to hear your message, because you are telling the truth. (5). So, the better way to do thing right is to use " only fundamental tools necessary". A few years back, when my colleague was using codes such as PATRAN, Geomesh, I told myself that, preBFC is good enough for me. It does not have editing tools, but it can create geometry and mesh from bottom up. (5). So, at one time, I was creating a geometry model using some 500 surface patches. Each point, curve, and surface was created individually and has its own name. It also required a pre-planning about how to create the geometry and the subsequent mesh long before I even started typing in the coordinates of a point. For un-structured mesh, I also had used the tgrid for 3-D grid generation in addition to the preBFC. (6). You can say that it is time consuming, but it is simple and it can give you the geometry and the mesh you are looking for. (7). I had used the GAMBIT a couple of times, but then I was doing something else and had to use other CFD codes and other mesh generation software. So, it is not possible for me to answer your technical questions related to GAMBIT. (8). I became interested in 3-D gemetry modeling back in early 80'. It was not just for the CFD, but also for the game model rendering. It helped me a lot in dealing with very complex 3-D model. (9). So, my suggestion is: (a). look from the solver's side first, and determine the mesh requirements related to the type of mesh and the nature of the physical solution. In this way, you have a rough idea about the flow field and the topology of the mesh, (b). Then, look at the mesh generation to determine what topology and blocking will give you the desired mesh. If the code can generate only un-structured mesh, then it is no good for the required structured mesh demanded by the solver. And even if, the solver can accept the unstructured mesh, you still need to plan ahead of the time in terms of the mesh size distribution. Sometimes, you will have to divide the mesh into more blocks to control the mesh density, even with the un-structured mesh program. (c). After you have the correct idea to generate the desirable mesh with a specific code (or module), you then figure out how to generate the geometry consistent with the mesh. (10). This is the only correct sequence to generate the geometry. If you are taking the other approach, from existing geometry to an available mesh generation code, then to the solver, you will always run into troubles somewhere along the line. This is because, the solution, the solver, the formulation, the mesh generation, and the geometry all have to be consistent with one another, in physics and topology. (11). For the mesh generation part, what you need to do is to identify the essential tools required to generate the basic mesh, which is consistent with the existing geometry or the geometry to be created or re-modelled. (12). So, a lot of thinking is required, if one is really interested in getting a good mesh and a good solution. Editing tools in geometry and mesh generation codes are just something which can save time, once you know how to generate a good mesh. What I am saying is: all you need to have is the capability to create points, curves, and surfaces, nodal distribution on curves, surface mesh and the volume mesh. The extra tools are something you really don't need, but will save you time only after you know how to create a consistent mesh for your solution. (13). In other words, GAMBIT is an over-kill program, for under-educated users. For professional users, they need only very few basic tools and options. (14). The CAD requirement is different. They don't worry about the topology of each patches of the model. Only the final model counts. This is very different from the mesh requirement for the solver. (15). I hope that you can see the point. The math can only handle very simple things, thus it is up to the human to work out the details. (16). It is sometimes much easier for me to draw a 2-D mesh on paper than to generate it using a computer code. And in 2-D, if you know where to place the nodal point, you can type the (x,y) coordinates into the program. Even a complex solver can accept point (x,y,z) as input from a file or keyboard.
|
|
December 21, 2000, 03:39 |
Re: Gambit problems
|
#3 |
Guest
Posts: n/a
|
Hy Althea,
I think the most important point is: never use virtual or facetted geometry in the construction-process !!!!!!!!!!!!! I do everything only with real geometry, only at the very end I use virtual geometry to connect edged or faces that did not connect real, I build the last (virtual) volumes that could not be built real. But before that, save your real part. I do not even set a point if I have virtual geometry, I only mesh ! |
|
December 21, 2000, 05:52 |
Re: Gambit problems
|
#4 |
Guest
Posts: n/a
|
Thanks for your comments Frank,
However it is not easy to avoid the use of virtual or facetted geometry when you are working with complex geometry which is built up from five separate translated and imported Catia files which arrive in virtual or facetted form. I would like to be able to exclusively use real goemetry. I would alos like our design engineers to design everything with straight edges. It would be lousy for the flow but geometry import and creation would be a lot easier. It's not going to happen though, so I will have to carry on the difficult way. Regards Althea |
|
December 21, 2000, 06:02 |
Re: Gambit problems
|
#5 |
Guest
Posts: n/a
|
Thanks John for your wise (and as usual many) words.
You are completely right. I should and do try to always keep the flow in mind when I am generating a mesh. I think part of the problem is I get impatient to get it finished and distracted by the number of complex CAD tools which should be helping me. Then I start to loose sight of what I am trying to do. A nights sleep (I'm in the UK) has done the problem the world of good. I have come back to it today and am dividing it up into smaller and more rational (flow wise) regions. A lot of the problems have now gone. Those that haven't I am more philisophical about. I have also had some encouraging feedback from my Fluent support engineer which has given me the hope I need to persist. Maybe Christmas wont be that bad afterall Best wishes Althea |
|
December 21, 2000, 15:31 |
Re: Gambit problems
|
#6 |
Guest
Posts: n/a
|
(1). I can only say that based on my experience the geometry model for CFD is completely different from that derived from CAD, even though the overall geometry for both models are the same. (certain areas must be modified for CFD applications) (2). It is a complex issue, and I don't want to discuss it here, because it is going to have great impact on the CFD applications. (3). In other words, the geometry model developed must be consistent with the CFD design and analysis (which include the geometry variation, and the input condition variation). (in a way similar to the parametric CAD design, for example) (4). To achieve this goal, one must develop a system to create the geometry for CFD analysis and design. (this geometry model is definitely not the CAD geometry model.)
|
|
December 22, 2000, 16:28 |
Re: Gambit problems
|
#7 |
Guest
Posts: n/a
|
Althea,
Sorry to hear about your difficulties and frustrations with Gambit. I suspect you had to work with corrupt models leading to unexpected behavior and numerous crashes. Unfortunately, inter operability of cad models between different systems has some fundamental limitations.Some of the main issues that affect data exchange between two system includes: - Difference in the tolerance (accuracy) used in the two system. This often creates gaps and overlaps in the geometry. - Translation quality : Data exchange via a neutral format (IGES, STEP) involves two-step process. Two fundamental aspects are how well the data is translated to a new format, and how well the data is interpreted when brought into another system. Most often, the entity types supported by a cad system do not match exactly with that of the other system or the neutral standards. This leads to approximation at each step. - Quality of the original model. We have seen much better results from CATIA using STEP format. The main advantage with STEP is that it is a better standard (driven by ISO) and natively supports solid models. This will give you real geometry in Gambit, where you can use healing to further improve its accuracy. We are also improving geometry/topology checks in Gambit to make it more comprehensive. This would help in early detection of corrupt data. Some of the specific problems mentioned by you has already been fixed and would be available in next release. Please let your support engineer know of any remaining issues, and we will try to fix them as soon as we can. Regards, Shyam |
|
December 25, 2000, 18:59 |
Re: Gambit problems
|
#8 |
Guest
Posts: n/a
|
Hi,
- visit a Gambit Course - export the Model in steps in AICES and reimport it in a new Gambit sessions - call your support engineer - You MUST understand the logic of Gambit (Course!) - I have very complex Models which i could mesh with Gambit without problems - Mesh generations take about 80% of project time Regards, Girgis. |
|
December 27, 2000, 03:46 |
Re: Gambit problems
|
#9 |
Guest
Posts: n/a
|
O the perils of using 3rd party software. It's a shame that Fluent do not just admit that they are at the mercy of Spatial's (notorious) 'quality' releases. Interoperability is a good scapegoat but not the real cause of so many people's pain. John C's point is correct, Gambit has the perception of being a good tool for under-educated users but more importantly is a good revenue streamer for Fluent.
Sexy software sells, but not for long. J. |
|
January 2, 2001, 06:37 |
Re: Gambit problems
|
#10 |
Guest
Posts: n/a
|
I had similar problems as those you described. However, we managed to improve the robustness of Gambit by upgrading the OpenGL drivers.
/Sonny |
|
January 2, 2001, 19:40 |
Re: Gambit problems
|
#11 |
Guest
Posts: n/a
|
You are not the only one who is suffering from GAMBIT problem... Actually, even a geometry built from scratch using GAMBIT also cause a lot of fatal errors... I got an experience where I created a complex 3D geometry and the time that I start uniting and subtracting parts I ended up several fatal errors...
I become worst once I import some geometry from other CAD software... I really do suggest to build your work in part and save them separately to easily identify the gambit problem... Actually it is very difficult to pinpoint problem once you did work it out in stages... |
|
January 3, 2001, 06:09 |
Re: Gambit problems
|
#12 |
Guest
Posts: n/a
|
Thanks Girgis,
I have attended the Gambit training course and also some advanced Gambit training as well. I do call my Fluent support engineer (frequently) and I agree about the very significant amount of project time taken up with meshing. However, I have not tried exporting and reimporting the model out of and back into Gambit. I will bear it in mind. Thanks, Althea |
|
January 3, 2001, 06:22 |
Re: Gambit problems
|
#13 |
Guest
Posts: n/a
|
Thanks for your comments Shyam,
We have pretty much completely given up on IGES, and STEP (so far) has not solved all the problems with importing. Currently we are trying importing our models into IDEAS (which we use for FEA and which has tolerances more similar to Gambit than Catia), sorting out any problems that arise there and then generating a mesh which closely represents the underlying geometry and importing that into Gambit. It's rather long winded but is an improvement over using a general standard (IGES or STEP). I agree that the quality of the original model is often a problem and we are spending a lot of effort in trying to educate our design engineers to produce better quality models when they require CFD analysis. It is an uphill struggle though, since the quality of models they are producing have always been good enough for all the other purposes. I am overjoyed (well nearly) to hear about the improvements to the geometry / topology checking and hope you've also got rid of some of those teaser buttons which are not greyed out but when pressed give the message "this functionality is not implemented yet". I am looking forward to the next release. Regards Althea |
|
January 3, 2001, 06:24 |
Re: Gambit problems
|
#14 |
Guest
Posts: n/a
|
Tried that (and upgrading the mainetnance release of the operating system) but thanks for the suggestion anyway.
|
|
January 9, 2001, 12:30 |
Re: Gambit problems
|
#15 |
Guest
Posts: n/a
|
Corrupt geometry? Fatal errors? Gambit acting in funny ways? That never happens in Gambit! No, that happens all the time.
I've been using Gambit since version 1.0, and these are my suggestions: - stick with real geometry as much as possible. - copy and heal are two functions that help alot to fix faces and volumes that give you trouble. (although, heal sometimes changes geometry more than you'd like.) - having the geometry simplified upfront in the CAD stage helps alot. - become familiar with creating your own geometry (sweep edges, sweep faces, unite, subtract, create face from wireframe, etc.) sometimes, I delete geometry except the vertices and re-create it (edges, faces, volumes) - if you're using all tets (no hex), I find Tgrid to be particularly useful in manipulating individual nodes. - using Groups in Gambit are useful to keep track of several faces, and to assign boundary conditions using groups. - Gambit has a hard time handling curved geometry, so keep that to a minimum. And that's my two cents, -Ushio |
|
January 11, 2001, 00:15 |
Re: Gambit problems
|
#16 |
Guest
Posts: n/a
|
Althea,
If a largely tetrahedral mesh is an option, I would suggest that you take a look at a software called ANSA. It is being extensively used in automotive industry (in which I work), and so far I have not heard a negative thing about it. I have been using it for about 7 months now, and have had no crashes. So far I have no complaints. ANSA can import IGES models. It also has a translator that takes CATIA surfaces and then writes out a file int its own format, which you can read in and clean up (that's what we do). Clean up is simple and easy, and is very logical to understand. It is very easy to learn. It then gives you a very nice quality triangulation (in TGrid terminology I control the surface mesh skewness to less than 0.6 for all cells, and a large majority being close to 0). It then writes out this mesh in fluent's .msh format that TGrid can read in. If you need more information, I'd be happy to provide you that. |
|
January 11, 2001, 00:20 |
Re: Gambit problems
|
#17 |
Guest
Posts: n/a
|
Ushio,
Your name sounds very familiar. Just out of personal curiosity, were you Professor Bogard's student at the University of Texas? |
|
January 11, 2001, 15:32 |
Re: Gambit problems
|
#18 |
Guest
Posts: n/a
|
Dear Althea, I suggest you try all the suggestion above first. If finally you still can not solve the problem the last way is to reinstall your gambit. I have some funny problem also and noboday knows the reseason. so finaly I reinstall the software, then the prolem dispear.
|
|
January 12, 2001, 05:32 |
Re: Gambit problems
|
#19 |
Guest
Posts: n/a
|
Dear Althea,
I really can understand your suffering. I felt the same feelings and suffered the saim pain during some grid generation processes. Especially with version 1.0 I once tried to generate a grid from an imported CAD-Geometry (I-DAES). That time for imported geometry exclusively virtual geometry was supported. It was awfully. Every day afternoon I was desperated. But after one night, as you, having had a good sleep without the GAMBIT nightmare, let me start again with new courage. Now we have 1.3 and a lot of things changed a became much better. For me the best now is that even with imported geometry (IGES, or Parasolid which I can use due to IDEAS-Unigraphics interface) I can keep real. As long as this is possible most things work fine. I must admit that sometimes it wastes a lot of time to keep everything real. And then I always wish that there would be a way to be independent from geometry like it was with geomesh before. Therefore I agree with John C.Chien (contribution from the 21.12.2000) where he stated that one must develop a system to create the geometry for CFD analysis AND design. (this geometry model is definitely not the CAD geometry model.) ... with emphasis on the AND. I also think that strict dependence on geometry is not aim-leading all the time. There should be "grid based" features possible too like adding nodes, extruding grid facets in order to generate volumes lets say to fill gaps a.s.o. without wasting time in repairing or creating missing or corrupted geometry. (see also the discussion initiated by Jurek "let's talk about GAMBIT fromm 16.Nov.2000, which unfortunately did not have as much resonance as it should have had) |
|
January 31, 2001, 10:15 |
Re: Gambit problems
|
#20 |
Guest
Posts: n/a
|
Hello Raza,
I have not had as much success searching for ANSA on the internet as I would have hoped. Have you got an internet address or other contact to get me started please. Thanks Althea |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Gambit 2.3.16, Xming or Exceed...HELP! | bambam3417 | FLUENT | 10 | May 7, 2010 13:39 |
Problems with gambit mesh | lions85 | FLUENT | 2 | August 28, 2009 20:05 |
installing gambit problems | aidank | ANSYS Meshing & Geometry | 1 | July 6, 2009 02:06 |
Facing Few Problems in Fluent and Gambit | Ravi Duggirala | FLUENT | 5 | March 11, 2006 04:13 |
Problems importing written gambit .neu mesh file | jemteo | FLUENT | 3 | February 20, 2006 02:42 |