CGNS Steering Committee

Telecon Minutes

1. The meeting was called to order at 11:05 AM. There were 12 attendees, listed below.
   
   
2. The minutes of the 6 January 2003 Reno meeting were reviewed and approved as posted on the web site.
   
   
3. Status of Reno action items:
   
   
   1. HDF-5: Everyone agrees it is a good idea to eventually replace ADF with HDF-5. HDF-5 has the following advantages: it has large following and support, it possesses parallel capabilities, and it has strong possibility to becoming an accepted ISO standard. The two major issues for us are backward compatibility and doing the work itself. Marc Poinot has a prototype available now (off the PyCGNS website <http://elsa.onera.fr/CGNS/releases/> ), but it needs a lot of testing and has some limitations (like missing system services such as error management). Ignoring links, Marc estimates it might take approximately 1 month to complete work on it, but he personally doesn't have the time to do it now. Bruce Wedan and Chris Rumsey agreed to take a look at the prototype as it currently stands.
   2. Part 52: Nothing done. The ISO effort currently on standby within Boeing. An evaluation of the ISO parts by the CGNS committee will also require active participation from at least one of the Boeing people who is working with the STEP documents.
   3. ADFVIEWER documentation and SourceForge: The documentation is complete and is on SourceForge, but there are currently still some wrinkles to work out with SourceForge to make it work for anonymous users. Bruce Wedan will send the documentation separately to Charlie Towne. Bruce will also give information to Chris Rumsey so he can try accessing CGNS from SourceForge. For SourceForge, copyright is not an issue - we are protected. The software continues to be under the GNU lesser public license. Once CGNS is accessible through SourceForge, the current plan is that Bruce (and perhaps one other person outside of ICEM?) will control and grant write privileges to certain people. Bruce also is developing shell scripts that run through the mid-level-library test cases.
   
   
4. ISO Status - Ray Cosner reported that there was a problem with the 2003 budget for ISO at Boeing that has resulted in the project currently being put on hold. Thus there was no progress at the last ISO meeting in early March. The budget problem should hopefully be resolved soon. There is a STEP meeting next week, and another ISO meeting in June.
   
   
5. Documentation - Charlie Towne will put in the changes (clarifications) suggested by Chris in the BC section of the SIDS, shown below. Also, Charlie says the documentation for utilities is currently buried (difficult to find / get to). He will correct this.
   
   
6. Discussion on extensions:
   
   
   1. There appears to be a need for allowing GridLocation and PointRange/PointList under UserDefinedData_t. Chris will write up a proposal for extension and have Bruce post it. There has also arisen a proposal from Florent Cayre of SNECMA in France, regarding additional specification of GridLocation for data deep under BC_t. Chris also agreed to write up this proposal and pass it on to Bruce to post.
   2. Regarding tools to check for SIDS compliance, there are now two separate tools in process of being developed. One (by Marc Poinot) is in conjunction with PyCGNS and performs all parts of a compliance check (syntactic and semantic parts). Checking a CGNS file is a compiler-like tool, and a compiler has a syntactic part that can be done using XML. The second tool (by Bruce Wedan) checks physical data, and can be used in conjunction with adfviewer.
   
   
7. Software Status: Version 2.2 is ready to come off Beta status. Bruce will remove the Beta status as soon as SourceForge is working for CGNS. In the future, CGNS will be obtainable only from SourceForge, and no longer from the ICEM website (the ICEM cite will point to SourceForge). As soon as the beta status is removed, Bruce will notify Charlie so Charlie can revise the documentation.
   
   
8. Other issues:
   
   
   1. Greg Stuckert mentioned a colleague with questions regarding CGNS's capability to handle material properties and different equations of state. Bob Bush said he believed that the SIDS currently handles these, but also recommended that the person submit a detailed question to cgnstalk, so that someone could more properly respond and point to where in the SIDS it is covered.
   2. Charlie Towne will look into capability for archiving of cgnstalk questions and responses.
   3. Marc Poinot reported on a recent meeting of the French CGNS User's group. Many large companies met. Each has its own way of using the standard. Mostly, CGNS is currently used for its intellectual content (SIDS part).
   4. The possibility of doing an AIAA paper for Reno 2004 was discussed. Marc Poinot and Chris Rumsey agreed to think about it, and perhaps submit something together if possible.
   
   
9. Next Telecon will probably be in mid-May. There will likely also be a CGNS meeting at the summer AIAA Meeting in Orlando. Craig Day is the person to contact for reserving a room, which should not conflict with the Standards committee meeting (Tom Shih).
   
   
10. Meeting was adjourned at 12:15 PM.
    
    
11. Summary of action items:
    
    
    1. Bruce Wedan and Chris Rumsey to check out Poinot's HDF-5 prototype.
    2. Bruce Wedan to send adfviewer documentation to Charlie Towne.
    3. Bruce Wedan to send SourceForge info to Chris Rumsey so Chris can try to access CGNS from it.
    4. Charlie Towne to make changes to SIDS.
    5. Charlie Towne to improve accessibility of utility documentation.
    6. Chris Rumsey to write 2 proposals for extensions: additional capability for UserDefinedData, and GridLocation deep under BC_t and have them posted.
    7. Bruce Wedan to get CGNS up and working on SourceForge - and notify Charlie Towne when it is ready so he can update the documentation (beta status will come off at the same time).
    8. Charlie Towne to look into archiving cgnstalk questions and responses.
    9. Chris Rumsey and Marc Poinot to discuss offline the possibility for a Reno 2004 CGNS paper.
    10. Chris Rumsey to arrange for CGNS meeting room in Orlando.

Attendees

Proposed changes/additions to SIDS

1. Re-wording of Sect 9.2 in SIDS after notes:
   
   OLD:
   Boundary-condition information for a single patch is contained in the BC_t structure. All boundary-condition information pertaining to a given zone is contained in the list of BC_t structure entities. If a zone contains N boundary-condition patches, then N separate instances of BC_t must be provided in the ZoneBC_t entity for the zone.
   
   NEW:
   Boundary-condition information for a single patch is contained in the BC_t structure. All boundary-condition information pertaining to a given zone is contained in the list of BC_t structure entities. If a zone contains N boundary-condition patches, then N (and only N) separate instances of BC_t must be provided in the ZoneBC_t entity for the zone. That is, each boundary-condition patch must be represented by a single BC_t entity.
   
   
2. Expansion of Sect. 9.3 (on BC_t), note 2 in SIDS:
   
   OLD:
   When GridLocation is set to Vertex, then PointList or PointRange refer to node indices, for both structured and unstructured grids. When GridLocation is set to FaceCenter ... etc...
   
   NEW:
   When GridLocation is set to Vertex, then PointList or PointRange refer to node indices, for both structured and unstructured grids. These node indices define the BC patch. In particular, it should be noted that these points can be interpreted in one of two ways: the finite-difference sense and the finite-volume sense. In the finite-difference sense, the points are defined as specific point locations at which the BC patch is enforced. In the finite-volume sense, the points define the boundary surrounding the BC patch region; thus, the indices are used to define the logical region in index-space within which the particular BC patch is defined. This latter case means that the edges of the BC patches may be multiply-defined, but the areas which are enclosed are unique. There is no mechanism currently included in this standard to differentiate between these two interpretations. Both are allowed. When GridLocation is set to FaceCenter ... etc...