CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Phoenics

unstructured mesh

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   February 10, 2005, 11:30
Default unstructured mesh
  #1
phoenics user
Guest
 
Posts: n/a
Are Phoenics ever likely to offer a unstructured mesh?
  Reply With Quote

Old   February 11, 2005, 10:45
Default Re: unstructured mesh
  #2
Mick Hughes
Guest
 
Posts: n/a
In a nutshell no. There are many disadvantages as well as some pros to the unstructured vs structured debate. (e.g. Rhie-Chow vs ataggered etc)

I believe that CHAM wish to keep all of the advantages of the structured mesh and handle the awkward shapes using the cut-cell technique.

  Reply With Quote

Old   February 13, 2005, 11:26
Default Re: unstructured mesh
  #3
phoenics ex-user
Guest
 
Posts: n/a
>In a nutshell no. There are many disadvantages as well as some pros to the unstructured vs structured debate. (e.g. Rhie-Chow vs ataggered etc)

that's probably THE major reason why most users are abandoning this sinking boat and moving to star, fluent, cfx etc...

>I believe that CHAM wish to keep all of the advantages of the structured mesh and handle the awkward shapes using the cut-cell technique.

this technique is definitely less accurate when dealing with inclined walls.

  Reply With Quote

Old   February 14, 2005, 11:17
Default Re: unstructured mesh
  #4
Another phoenics ex-user
Guest
 
Posts: n/a
I agree that the cut-cell technique is inaccurate and cannot handle complicated geometries. It also requires large number of cells to deal with relatively complicated geometries, that an unstructured solver can handle with a fraction of the cells required by the cut-cell technique. Will CHAM provide this solution?
  Reply With Quote

Old   February 17, 2005, 06:08
Default Re: unstructured mesh
  #5
Mick Hughes
Guest
 
Posts: n/a
Hi

Unstructured mesh generation can and usually does take a lot of effort, throwing a cartesian mesh on a complicated shape and using the cut cell technique in principle gets rid of this difficult meshing task. I guess its a pioneering approach that will suit many but not all.

The principle as you well know is that you import a STL cad geometry and throw some mesh at it and "hey presto". Of course CFD is never just quite as easy as that, but thats the goal.

Yes, you may have to throw a lot of mesh at some parts, but with structured meshes I personally think that you do get a lot of control over the cell distribution.

Regarding the accuracy, I'm not really qualified to say but I can invisage that the cut-cell method is very difficult to develop and I know that improvements have been made for 3.6 and as with every code I imagine will continue to be made. However collocated rhie-chow can have difficulties under certain circumstances as well. Just to be clear, the cut-cell method handles curved surfaces like BFC not by taking steps. There are also new features such as the thin plate with should improve representation of inclined plates.

Of course there is the possibility that you switch off the cut-cell and use more traditional methods such as bfc, or bfc multi-block.

But at the end of the day, you make your choice and pay your money, and for many users, (things like hvac especially), I think the prospect of eliminating the concept of complicated mesh generation is a valid aim and can open CFD up to a large market.

Yours Mick

  Reply With Quote

Old   February 17, 2005, 17:15
Default Re: unstructured mesh
  #6
Kevin McManus
Guest
 
Posts: n/a
I am a big fan of unstructured mesh techniques but most unstructured mesh CFD codes are FE not CV and can suffer conservation problems. Unstructured mesh CV codes use Rhie-Chow which is generally not so stable or accurate as the PHOENICS staggered grid approach.

If you can work with structured grids, possibly augmented with multi-block, BFC, cut cell and fine grid embedding techniques then you are fortunate. You are likely to find problem setup, configuration and solution to be faster and less painful than using unstructured meshes.

If however your problem demands an unstructured mesh then it is most likely a sensitive problem and you are in for a fun time. With luck you will have access to a code tailored to your specific application area as I know of no general purpose CFD codes with ease of use comparable to PHOENICS.

There are many excellent unstructured mesh CFD codes but few codes offer the time to solution and validity of solution as PHOENICS. I don't want unstructured features in PHOENICS, I already have unstructured mesh codes. I just want the bugs fixed so that the cut cells and embedded grids work 100%.
  Reply With Quote

Old   February 20, 2005, 14:21
Default Re: unstructured mesh
  #7
yet another phoenics ex-user
Guest
 
Posts: n/a
Kevin,

I disagree with most of your arguments, and to a lesser degree – of Mick.

>I am a big fan of unstructured mesh techniques but most unstructured mesh CFD codes are FE not CV and can suffer conservation problems.

Apparently, most present commercial CFD codes are unstructured CV (cf. FLUENT, STAR, CFX, etc.).

>Unstructured mesh CV codes use Rhie-Chow which is generally not so stable or accurate as the PHOENICS staggered grid approach.

As far as I am aware, the above codes use techniques very similar to those of PHOENICS (I think all were directly influenced by Spalding, since the main characters were his students at Imperial College). Their accuracy and stability characteristics are at least as good as those of PHOENICS.

>If you can work with structured grids, possibly augmented with multi-block, BFC, cut cell and fine grid embedding techniques then you are fortunate. You are likely to find problem setup, configuration and solution to be faster and less painful than using unstructured meshes.

For trivial geometries and flowfield, no doubt structured grid is the easiest to set up and most economical. When you need multiblocks and fine grid embedding, setting is no longer easy with PHOENICS (not to mention it is buggy). The opponents, on the other hand, supply easy-to use interfaces and meshers, and if this is not enough, there are plenty of splendid unstructured meshers out there, whose grids may be imported into the major players preprocessors. If you wish to use these independent grid gen's with structured grid, you lose a lot of their power and usually also waste a lot of cells unnecessarily. You also almost always end up with low quality grids at certain locations, usually at edges or corners (i.e., exactly where it is most important to have a good quality grid…) due to the structured grid constaint.

>If however your problem demands an unstructured mesh then it is most likely a sensitive problem and you are in for a fun time. With luck you will have access to a code tailored to your specific application area as I know of no general purpose CFD codes with ease of use comparable to PHOENICS.

Once again you are encouraged to look at the capability of all other major CFD packages. You'll find they are usually more potent and general than PHOENICS, whose main processor (Earth) advanced very little during (at least) the last decade.

>There are many excellent unstructured mesh CFD codes but few codes offer the time to solution and validity of solution as PHOENICS.

Quite the opposite.

>I don't want unstructured features in PHOENICS, I already have unstructured mesh codes. I just want the bugs fixed so that the cut cells and embedded grids work 100%.

If you are happy with PHOENICS – good for you. However there is some criticism here, touching another painful issue: PHOENICS is full of bugs, and they seem to persist there from one release to another, while new ones are added with each new release.

As to Mick's posting:

>>Unstructured mesh generation can and usually does take a lot of effort, throwing a cartesian mesh on a complicated shape and using the cut cell technique in principle gets rid of this difficult meshing task. I guess its a pioneering approach that will suit many but not all.

See my above notes on pre-processing and meshing tools available for unstructured grids.

>>The principle as you well know is that you import a STL cad geometry and throw some mesh at it and "hey presto". Of course CFD is never just quite as easy as that, but thats the goal.

>>Yes, you may have to throw a lot of mesh at some parts, but with structured meshes I personally think that you do get a lot of control over the cell distribution.

>>Regarding the accuracy, I'm not really qualified to say but I can invisage that the cut-cell method is very difficult to develop and I know that improvements have been made for 3.6 and as with every code I imagine will continue to be made. However collocated rhie-chow can have difficulties under certain circumstances as well. Just to be clear, the cut-cell method handles curved surfaces like BFC not by taking steps. There are also new features such as the thin plate with should improve representation of inclined plates.

How good would you expect a solution on such grid for, say, vortex shedding behind a sphere? Surely much worse than an adapted (and necessarily unstructured) grid, and with a huge waste of cells as a bonus.

>>Of course there is the possibility that you switch off the cut-cell and use more traditional methods such as bfc, or bfc multi-block.

Well both BFC and multiblock are steps away from the brute-force partial cells methodology and in a direction towards unstructured grid, but – alas – too small a step.

>>But at the end of the day, you make your choice and pay your money, and for many users, (things like hvac especially), I think the prospect of eliminating the concept of complicated mesh generation is a valid aim and can open CFD up to a large market.

Even wrt cost, the other codes are quite close to PHOENICS. And if you do not wish to solve only square rooms and the like (isn't CFD also about solving flows around cars, airplanes etc?) and you wish to have higher order solver, better response of support and less bugs – PHOENICS is definitely not the one.
  Reply With Quote

Old   March 1, 2005, 08:38
Default Re: unstructured mesh
  #8
abc
Guest
 
Posts: n/a
PHOENICS's best choose : do not develop

: fix phoenics' bug

I worked hard several month . At last found phoenics' code is wrong .
  Reply With Quote

Old   March 10, 2005, 20:43
Default Re: unstructured mesh
  #9
Kevin McManus
Guest
 
Posts: n/a
Hi yet another phoenics ex-user

Yes there are now many unstructured mesh CFD codes that, as you point out, are largely based on the work of Spalding and Patankar. As far as I am aware the codes that you mention employ (variations on) Rhie-Chow interpolation which is good but not without problems. http://www.cfd-online.com/Forum/main.cgi?read=35407

While it is generally not a good idea to generalise

When faced with highly complex geometries or extreme aspect ratios unstructured meshes certainly have advantages. I prefer to work with unstructured meshes mainly because they are amenable to adaptive meshing and dynamic load balancing although I frequently find mesh quality to be a problem.

Structured meshes are generally easier to generate, more rapid to iterate, offer faster convergence, greater stability and amenable to implemention of multigrid accelleraton.

I guess that we can at least agree that the biggest problem with PHOENICS is the bug density. It is tragic how this mature and innovative code, a benchmark in CFD, has become hamstrung through its numerous bugs. CFD is a difficult game, how is an inexperienced user expected to differentiate between their mistakes and failings in the code?
  Reply With Quote

Old   March 11, 2005, 18:10
Default Re: unstructured mesh
  #10
yet another phoenics ex-user
Guest
 
Posts: n/a
Kevin,

to start with, if your geometry is trivial and lends itself to structured grid, then you are right. many problems, however, are not such, e.g., even very simple and common geometries such as a triangular domain or a wing profile you wish to solve by a c-grid are definitely almost impossible with phoenics. not to mention real-life domains. have a look in the other major cfd vendors' sites to appreciate what is already done, and is far beyond phoenics capabilities.

using multigrid is possible for unstructured grid (e.g. AMG), and is routinely used in fluent.

generation of a grid is difficult only for really complex geometries, and good, mature meshing tools are available for a long time already.

having experience with star and fluent, believe me you usually get reliable solutions with much less effort than with phoenics, so their schemes must be better than those of phoenics, and certainly with much less bugs. many users escaped phoenics due to these reasons. should cham wake up about a decade ago, start to work hard on a new unstructured code instead of patching their old code over and over again - maybe they could be still in the game. at present, their battle is lost. add to this the slowest user support ever seen - and you even have an extra good reason to chnage horses.
  Reply With Quote

Old   March 17, 2005, 03:08
Default Re: unstructured mesh
  #11
Fluent user
Guest
 
Posts: n/a
Yet another ex user

>>to start with, if your geometry is trivial and lends itself to structured grid.............and is far beyond phoenics capabilities.<<

This is rather a sweeping statement! and misleading. Following the dialog of this tread, I find myself agreeing with some of your points, but I think you are a bit naive.

I do not think you fully appreciate the benefits of structured cartesian meshes and what can be achieved on them.

I do not believe that a cut cell method should be less accurate then an unstructured solver. At least if its implemented properly

It made me laugh that you should presume so much about any codes capabilities, there is a phoenics journal full of papers + input files that contradicts you.

I also do not see the point in phoenics developing an unstructured solver, whats the point in competing with fluent.

Additionally the price comparison between the codes is not as you imply.

>>generation of a grid is difficult only for really complex geometries, and good, mature meshing tools are available for a long time already<<

It certainly can be difficult, which is one reason why I am so interested in widening our arsenal and having our team develop cut-cell method.

>>having experience with star and fluent, believe ..... slowest user support ever seen - and you even have an extra good reason to chnage horses.<<

Yes, but why not tell CHAM directly why you stopped using instead of namelessly slanging them off here.
  Reply With Quote

Old   March 19, 2005, 18:29
Default Re: unstructured mesh
  #12
another fluent user
Guest
 
Posts: n/a
I agree with most of opinions on generation of unstructured and structured meshes. They are both precious! So the best choice is to handle with both of them. About Cham now, we have to admit that numerous changes have been to the better way. But i do not think that intends to develop an unstructured solver!Spalding wouldn't allow it!I know that it sounds against the spirit of the modern cfd codes, but staggering the grid is the best choice for Cham. About Fluent there is no reason comparing the two codes, we all know what offers each of them.Combine both of them is the best choice!
  Reply With Quote

Old   April 3, 2005, 14:36
Default Re: unstructured mesh
  #13
PattiMichelle
Guest
 
Posts: n/a
I've noticed some problems with the Fine Grid Embedding in PHOENICS - it tends to generate stability problems. It *appears* that the increased relaxation necessary for fine grids is cast over the *whole* domain but a single fine grid volume. The AutoConvergence control sometimes can handle this. Also, I've noted what appears to be reflection of transients (in unsteady probelms) from the boundaries of FineGrid volumes. There doesn't seem to be any comments on these two effects in the PHOENICS (3.6) docs or else I've missed it...
  Reply With Quote

Old   April 3, 2005, 14:38
Default Re: unstructured mesh
  #14
PattiMichelle
Guest
 
Posts: n/a
Well, I'm mainly using the CHEMKIN-II code which is part of PHOENICS. There is a LOT to be said for pre-validated chemical kinetic codes.
  Reply With Quote

Old   April 3, 2005, 14:41
Default Re: unstructured mesh
  #15
PattiMichelle
Guest
 
Posts: n/a
Do these codes have the multifluid models of turbulence or the ability to co-solve flow/heat/stress-strain at the same time?
  Reply With Quote

Old   July 15, 2005, 04:36
Default Re: unstructured mesh
  #16
Pedro Costa
Guest
 
Posts: n/a
I am confused and would apreciate if someone could clarify an issue i am having. I am a Fluent and going-to-be a CFX user, both unstructured solvers. But I am generating all my meshes in ICEM CFD, and hence, I have to do some thinking about the blocking stucture, etc. prior to mesh generation (hex meshes). If I export my multi-block stuctured mesh into Fluent/CFX, do these codes covert my structured mesh into an unstructured mesh before computation, since they are unstructured solvers? If so, the initial theoretical advantages of using structured multi-block mesh are lost or not? I am pretty sure I am confusing something here...
  Reply With Quote

Old   July 19, 2005, 13:27
Default Re: unstructured mesh
  #17
Pedro Costa
Guest
 
Posts: n/a
Here is a nicely put explanation to my question, that I got recently. A structured solver is a one that assumes that the neighbors of cell i,j are i+-1, j+-1. It can only handle structured blocks of cells. An unstructured solver does not know in advance its neighbors. Cell 2005 might be adjacent to cell 1,10003 and 65 and the unstructured solver needs to keep track of this information. However, the unstructured solver has no problem at all dealing with a structured grid as long as the information needed is provided, i.e. the unstructured code is more general than the structured code is.
  Reply With Quote

Old   August 3, 2005, 06:54
Default Re: unstructured mesh
  #18
Jelle
Guest
 
Posts: n/a
Phoenics does offer a body fitted coordinate option for the grid, but it only works for cube-shaped objects, so I wonder what the use of it is?
  Reply With Quote

Old   August 21, 2005, 04:51
Default Re: unstructured mesh
  #19
mick
Guest
 
Posts: n/a
Rectanguloid control-vol cells are very good for solving CFD.

The BFC grid system was devised as a means to model more complicated gemetries with structured grids. I suppose that is largely has been surpassed by unstructured methods and cut-cell techniques, however it still is very useful for certain geometries. It generally works well provided the cells are not skewed too much.

If I were a self employed consultant I would be using both types of code, however if the model could be simulated using a structured staggered grid, I think I would generally use this as a first choice because the pressure gradient acts at the correct place. So for models with say strong coriolis type forces etc the staggered system is proven to work well.
  Reply With Quote

Old   August 21, 2005, 05:09
Default Re: unstructured mesh
  #20
mick
Guest
 
Posts: n/a
Thats true, the unstructured solver has an adjaceny matrix which keeps track of what cells are next to each other. Also that an unstructured solver will not have any problem in solving on a structured grid. In fact I would imagine that most of the problems that are input into unstructered codes do ,(or could), infact have used a structured grid arrangement.

I would say that an important difference is that the unstructured codes have all variables stored at the cell center, whereas the structured codes use a staggered grid arrangement. The unstructured codes therefore use a technique (Rhie-chow) to get mass flux through the cell faces, whereas the staggered grid do not since the driving force for the flow, dP, is naturally at the cell face.

I would also say that depending on what you are doing one type of code will be better then the other. There are some problems that just lean themselves towards unstructured grids and hence unstructured methods. On the other hand the converse is also true.

  Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unstructured hex mesh lr103476 OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 12 November 24, 2006 05:56
Structurted mesh and unstructured mesh Wiroon Main CFD Forum 4 July 1, 2005 04:41
Structurted mesh and unstructured mesh Wiroon FLUENT 2 June 28, 2005 09:40
unstructured mesh mehd icho Main CFD Forum 0 February 27, 2003 07:44
Unstructured mesh Mir CD-adapco 2 May 15, 2002 15:44


All times are GMT -4. The time now is 15:13.