Are Phoenics ever likely to offer a unstructured mesh?

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.

>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.

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?

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

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%.

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.

PHOENICS's best choose : do not develop

: fix phoenics' bug

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

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?

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.

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.

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!

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...

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.

Do these codes have the multifluid models of turbulence or the ability to co-solve flow/heat/stress-strain at the same time?

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...

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.

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?

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.

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.