Grid formats for 2D needed
 

I have developed a program to place structured or unstructured 2D grids about airfoils. The code, which is for sale on my web page, uses a variety of formats for input of the foil shape. I would like to know the most popular formats used by CFD codes to input externally generated grids. A sample input file would be greatly appreciated.

Re: Grid formats for 2D needed
 

You need two tables, one for the location of nodal point (vertex) and one for the connectivity ( to define the cell ). line-1: total number of points , line-2: X , Y coordinates of the first point, ...... You can also include point ID in the line-2 as : ID, X, Y. After that you need a table of connectivity. line-1: 3, 1,2,3 . ( 3-point polygon, point-1, connected to point-2, connected to point-3, connected back to point-1 ) or line-N: 4, 11,12,13,14 . ( 4-point rectangle, where 11,12,13,14 are nodal point ID's ). You can also define the total number of cells ( polygons) to be defined in the connectivity table in the first line. If you use ASCII file, then everybody can read it. this format is nearly universal. In this way, you don't have to worry about the format change of the code in the future versions.

Re: Grid formats for 2D needed
 

I would like to support John's suggestion, just a small remark. You should make sure that you generate a consistent connectivity list. For 2D case, I would suggest to write out the vertices of the 2D polygons (elements) in the counterclockwise manner. Consistent ordering (e.g. a counterclockwise order) assures that the calculation of edge normal vectors does not require any additional logic.

regards

D.M. Lipinski

Re: Grid formats for 2D needed
 

Yes, that is definitely very important. For example, do: line-1: 3, 1,2,3 . line-2: 3, 3,4,1 ... Don't do: line-1: 3, 1,2,3 . line-2: 3, 4,3,1 ... ( unless you have a special reason to do that.). Thanks!

Re: Grid formats for 2D needed
 

Thank you for the replies. For operation a CFD code, do you not also reqire a list of the cells on each side of an edge. You then loop through a list of edges to compute fluxes to be added to the cell on each side of the edge. I was hoping to get hold of existing input formats to use as de facto standards.

Re: Grid formats for 2D needed
 

In this case, I would suggest that you send e-mail to each developer of CFD codes to see whether the I/O format is available or not. Some claimed that it's included in their user's guide. Even with the format, you still need their code to check out your mesh. So, look for code which you have direct access to, then contact the developer for the I/O format.

Re: Grid formats for 2D needed
 

Donald,

there is a new effort to set up a standard for CFD related data, the CFD General Notation System (CGNS). They have a web site:

http://www.cgns.org/

Best regards,

Robert

Robert Schneiders MAGMA Giessereitechnologie GmbH D-52072 Aachen Kackertstr. 11 Germany Tel.: +49-241-88901-13 email: rjs@magmasoft.de www: http://www-users.informatik.rwth-aachen.de/~roberts/

Re: Grid formats for 2D needed
 

Do you know how this effort is related to the CFD-DTF (Data Transfer Facilities... or something like that) things pushed by CFDRC? I noticed that CFDRC also was the only CFD code vendor associated with the CGNS standard.

Standardization of CAD/CFD/PRE/POST formats is something we need badly, not only for commercial codes but also to be able to use our own solvers together with commercial pre and post processors.

Re: Grid formats for 2D needed
 

As long as the I/O format is made public, one can always read the whole or part of the file for subsequent use. With so many ways to create geometry, model , mesh, solutions and animation, the use of the standard can only delay the development of better methods. Even in the seemingly black-and-white world of CAD, the number of colors, the exact equation of curves used can easily make two CAD I/O non-compatible.

Data exchange interfaces and seamless computing
 

You might be right but a lot of companies and organizations are betting millions on that you are wrong... These new standardization initiatives in CFD are just the tip of an iceberg I think. Data-exchange interfaces and seamless computing might revolutionize high performance computing in the future. It's a subject I know very little about, but I'm starting to realise that there might be big things on the horizon here. Giants like Microsoft's COM, Javabeans and CORBA are a few of the bigger players. I found this article which discusses this from a perspective quite close to CFD: HPcc as High Performance Commodity Computing It's not that easy to read though (this world has more cryptic acronyms than CFD)

As I said I know very little about this. Anyone who knows more? How could this affect CFD codes in the future?

Re: Data exchange interfaces and seamless computing
 

If you use a new version of MS applications and send the output file to another department which is still using an older version of the same application, most likely the person who receives your file is going to have hard time to read your file. Here we are simply talking about the file I/O that is the format. The compatibility problem comes from (1). the format change, and (2). the contents change. The format change could be related to the program logic change in order to streamline the operation, and the contents change could be related to the added new features of the new version. These are necessary for the survival of the program in the market place. The computer graphics standard is one example related to the graphic library, and the CAD file standard is another one related to the geometry definition. For the efficient operation of an application program, the format of I/O and the contents of I/O are likely to change from time to time in order to satisfy the need of the users. Even UNIX is not universal not to mention the Windows-95 vs Windows-3.1 etc.. Market domination is the trend not the I/O format compatibility.

Re: Data exchange interfaces and seamless computing
 

I agree... this is the trend until recently. I'm just saying that this might change in the future. A globalised internetworked society is bound to generate open standards not governed by a single company - there is no single company controling the standards on the web. HTTP and HTML came first, after that followed java and the next wave is just starting. There is no telling where this will end, it is a snow-boll that is just beginning to pick up speed, and it might affect high-performance computing and CFD codes sooner than we expect.

Re: Data exchange interfaces and seamless computing
 

Technically, data exchange is a modest problem to solve which requires common sense and cooperation rather than innovation. STEP is a good example of a method of solving it which was conceived in the early 80s (I believe) when the failings of IGES became apparent but has only recently really got going. What has happened to it is a lesson to us all... The success of IBM and then Microsoft is built on never conforming to standards that you cannot control unless it is absolutely essential. Another example is Sun, they are doing everything imaginable to get people locked into java and leaving their roots far behind. However, to return to the point, if you want to conform to standards STEP is still probably the best place to start rather than supporting a commercial players attempt but you are going to need some stamina.