I have one more question... There are those within our company who think we should switch to Fluent after years using PHOENICS. The main reason, as I see it, is mesh generation. In my consulting group we do transient, inhomogeneous BFC simulations of geophysical flows in coastal waters, lakes and rivers. We construct our BFC grids manually using digital charts (containing bottom countours) and a special ArcView program that we had made for us, combined with some Matlab routines. Our grids try to follow both the shoreline contours and the bottom topography. For large domains, this is a lot of work and I miss the possibility to increase the resolution in smaller sections of the domain (such as around a pier). In Fluent, we could apparently construct a geometry from the depth contour database (a 2D regular mesh containing the bottom depth) and the surface, and then an unstructured mesh could be automatically created to fill this volume, regulating the resolution as we desired.

Any comments? Does the unstructured mesh have any drawbacks compared to BFC? Note that because of the different horizontal and vertical scales in geophysical flows, our cells often have very large aspect ratios (horizontal length scale 10-1000 m, vertical length scale 0.1-10 m) which can cause numerical problems.

Thanks,

Olof

I have found in some CFD books that the computational time is more in unstructured grid as compared to structured grid. Perhaps you can evaluate Geogrid (structured grid) free of cost for a month. BFC grid generation is little easy in GEOGRID and can be easily imported in PHOENICS. You may visit at http://www.csi-cfd.com/ If you use, please share your experience. I have just procured it.

Vikas

GRIDGEN has the power to generate grid for both PHOENICS and FLUENT. Take a try and you'll know which one is better

Thanks for the different suggestions concerning grid generation software. However, I was more interested in the numerical pros and cons of structured vs. unstructured grids. Vikas Kumar believes there is a performance difference, with the advantage being on the side of structured meshes. Any other comments? What about numerical stability and accuracy?

Sincerely,

Olof

I would suggest that the numerical accuracy of structured grids may be higher than the unstructured grids if the finite-volume method is employed by the CFD code. One of the advantages using structured grids is that the neighbour connectivity simplifies programming and the matrix of the algebraic equation system has a regular structure, which can best be exploited in some linear equation solvers. Therefore it may have better stability in terms of numerical operation.

On the other hand, the unstructured grids have been increasingly popular because it can be generated automatically and have very good capability in handling complicated geometries. You might be aware of that it is sometimes very frustrating to create a body-fitted structured grids if a complex geometry is involved in the computing domain. One disativantage of using unstructured grids is in modelling the flows near walls because it may not be as efficient as the structured grids. It is acknowledged the structured grids have better resolutions when modelling the wall-affected flows and that is why some CFD codes still suggest users to create some structured grids near walls in addition to the unstructured grids for better representation of the flow field near walls.

Grid generation has been a vivid research area in the CFD community because the quality of grids is crucial to your CFD simulation. If you want to find out more about the role of grids in CFD, you can consult a number of textbooks suggested by this web site where you must be able to get the information you want.

C. Hu

hi, i am a fluent user for many years. i am a novice in PHOENICS. it is right that we shoul use structured grid as far as possible for , nmerical dissipation, matrix handling and so CPU cost... But when geometry aspects prevail, unstructured grids should be chosen: today the availabe CPU power can largely allow its use. in addition, the drawbacks of CPU cost and time on the final convergence is reduced in fluent by using a multigrid sover by default, what PHOENICS just proposes it as an additional option... the cPU cost is also reduced in fluent by an automatic grid adaptation, following the parameters u chose: gradient of a scalar, pressure, velocity... this considerably reduces the grid cells and concentrates them only in the regions of interest...

the best u can do, is to try FLUENT and may be have both with PHOENICS..but $$$

yann,

I have used both fluent and Phoenics and some other CFD packages as well as Finite element analysis packages that use similar logic.

In my experience using unstructured grids tends to be more CPU expensive but less time intensive to set up the grid. With structured grids they tend to take longer to set up the grids but tend to be less CPU intesive - and you have greater control on where to refine the mesh. Sometimes automatic meshing tools are not the best in this area and requires some manual editting.

Unstructured meshes suffer from the same problems as structured meshes when being streched, mainly numerical stability and bumerical accuracy. However, selecting the correct 'shapes' can allow for a larger aspect ratio on the grid.

Also, when considering the change to Fluent you should look at the iues around adding your own code. I beileve that this is one of the best features of Phoenics when compared to other CFD codes.

As others have suggested look at using a third party grid generation software and still use Phoenics maybe the best compromise.

Hope this helps

Leon

The argument of the lower efficiency of the unstructured methods is often raised, and I wish to note on this point.

There is indeed some overhead using a connectivity matrix rather than just using the neighbours in the logical (indices) space. However, to some extent it also occurs in PHOENICS, because of its segmented memory structure and the need to use the L0F, LB, L0PV, etc. functions.

Moreover, if you consider a little more complicated geometry, you will realize you actually gain efficiency with unstructured grid. As a very simple example, consider a "+" shaped domain. You can easily mesh and solve it with quads using an unstructured solver, and there would be relatively few cells in the grid if the "legs" are thin and long. Using a structured grid, you will have to block many cells to prevent flow through the "legs" boundaries. This would be quite inefficient. Another possibility is to use multi-blocked structured grid. This is a compromise, and you will have the same sort of indirect access as in the unstructured approach (maybe to a somewhat lower extent, but with less flexibility).

As for the accuracy, if we stick to the above example, you may have exactly the same solution in all the above methods if the same discretization scheme is used, regardless of the grid topology.

To sum up, in my opinion, the claim for inefficiency of the unstructured grid is only relevant in highly simplified cases. In many others, the opposite is quite probable.

Rami

It seems to me that in the vertical direction it is eminently sensible to use BFCs to represent the sloping bottom (unless you have underwater cliffs!), and I imagine that you must have developed a satisfactory procedure for setting up the vertical grid coordinates, based on given depth data.

For defining shoreline contours, it's going to be a harder task to set up the BFC grids in general. Some cases I imagine will be fairly straightforward and will give you a nice grid, others less so.

Have you thought of another idea, which nobody in this discussion seems to have considered yet? This is to use a cartesian grid in plan view, just using BFC for the depth. (This accords with the current CHAM philosophy, as implemented in VR.) What I mean here is that as far as PHOENICS is concerned the grid is BFC, but that if you looked at it in plan view it would appear Cartesian. I think this might be quite an interesting idea, the only serious drawback would be if you need some sort of boundary conditions to be implemented specifically on the shoreline. This could be done but might be a bit more difficult.

If you have any sort of CAD representation of the shoreline, you could make use of the CAD interface to VR to set up the geometry in plan view extremely easily. Remember that if you define a cartesian grid in Q1, you just need to add a BFC=T command to take the existing cartesian grid and render it BFC. You could then modify the depth coordinates to match the bottom.

You may already have thought of this idea and dismissed it - but if not, think about it! I think it could prove to be quite a slick way of setting up your geometries. Then you would retain the efficiency of the structured grid, the power of "user-programmability" in Ground, and you might be able to make use of VR's local-fine-grid facility!

Worth thinking about?

David Glynn

Flowsolve Ltd