2020-1-28 Meeting notes

Owned by Scot Breitenfeld
Last updated: Jun 15, 2021
5 min read

Date

28 Jan 2020

 

Participants

  • @Scot Breitenfeld ​

  • @Koen Hillewaert ​

  • @Mickael PHILIT

  • @Gregory Sjaardema

  • @Thomas Hauser

  • @Vicky Moschou

  • @Tony Garratt

  • Stephen Wood (NASA) accompanies @Christopher Rumsey

  • @stephen.guzik

  • @Christopher Rumsey

  • @Marc Poinot

  • @Pierre-Jacques Legay

  • @Patrick Baker

  • @Tobias Leicht

Steering Committee Issues

@Scot Breitenfeld will follow-up with contacts at P&W about new representative for the committee, vote to drop P&W at next meeting if none found.

Discussion topics

Time (Approximate)

Item

Presenter

Notes

Time (Approximate)

Item

Presenter

Notes

1min

Approve 11 Dec 2019 minutes.

@Scot Breitenfeld ​

post last meeting’s minutes to CGNS webpage.

5min

CGNS version number specification

@Scot Breitenfeld Vangelis Skaperdas

Beta-cae will summarize the issue and the proposed solution to the version issue
@Koen Hillewaertwill send out the Beta-cae document to the entire committee for discussion, and to follow-up with a vote as to whether to increase the CGNS version to 4.0, or to continue with the 3.x series and to just provide a graceful exit fix. The issue will also be raised on CGNStalk after the committee discussion.

A poll was taken after the meeting,

A majority of the committee decided on option 2:

Due Jan 31, 2020:@Scot Breitenfeld will release a patched version, v.3.4.0-patch0, with CPEX0043 removed. Commits after CPEX0041 commit can remain if they do not depend on CPEX0041.
Due Jan 31, 2020:@Scot Breitenfeld or @Mickael PHILIT will release v4.0.0, which was essentially the 3.4.0 release.
v 4.1.0 can be released shortly thereafter with new fixes committed after the 3.4.0 release.

After discussion during the meeting, it was decided that forward compatibility will be maintained in a major release as before

@Koen Hillewaert will check whether this forward compatibility has to be described in more detail. Basically should result in graceful exit if data present in “extended” version of older datastructures

 

15min

prioritization, review and attribution of JIRA bugs/issues

@Tony Garratt @David Gutzwiller ​

 

Platform proposals
Drop SunOS, Windows 7 and 8 and AIX?

Windows is under-tested. Suggest Test C and Fortran serial and parallel on Windows 10 x64 as a bare minimum

Do we test both 32bit (legacy) and 64bit API? It's a minor point, but it would a good idea to add 32bit to at least one Linux and Windows

Bug list: https://cgnsorg.atlassian.net/browse/CGNS-176

A priority of bugs to fix in next release

#1https://cgnsorg.atlassian.net/browse/CGNS-135

​Crucial to Ansys. Although most HPC is Linux, project set-up often was done on Windows and import/export/sharing of mesh/solution done on Windows, while most runs performed on Linux clusters

#2

#3

- important to have parallel working

#4

#5

#6

​Conflicting bugs - are we supporting configure or not? Very confusing to end-users

Overall comments from Ansys

  • Configure much easier to use than cmake. Ansys would prefer we drop cmake and move back to configure - but see above - are we moving to cmake only or not??

  • Make LFS the default - 2Gb is tiny by today's standards. Introduce LFS=off or SFS option for backward compatibility

During the meeting, this was marked as having the highest priority for ansys

  • Add large file test cases >4Gb serial and parallel both platforms

  • Overall needs of Ansys - these items and bug fixes important to use, not any of the new enhancements right now.

 

Overall comments from NUMECA

I generally agree with the comments from ANSYS / Tony Garrett. I will second a few points based on NUMECA's needs:

Highest priority bugs:



This issue has highest priority for numeca. DG says the parallel interface is actually unusable and therefore disabled in numeca tools

We have disabled parallel CGNS in our release packages until CGNS 176 and CGNS 109 are fixed, it became a problem for our support engineers.

I agree with the comments on configure vs CMAKE. Our internal library maintenance system is built on configure, and it would be nice to maintain support if possible.

  • There is no current plan to drop Autotools support.

 

5min

high-level editing tools for the documentation page

@Marc Poinot @Christopher Rumsey ​

Raw html is not an ideal format to maintain documentation, the latex version seemed easier. It was mentioned to maybe go back to using latex, but the latex version is now out of date compared to the html version. Some committee members were uncertain whether the latex format was the right way to go when compared to other documentation methods (Markdown, Readthedocs, etc…). Either way, it will involve some effort to move from the html versions.

  • @Marc Poinot has prototype w/ REST (used for the readthedocs web site). It supports equations and images and should therefore be sufficient. It is implemented / available in dedicated branch (documentation_migration). Needs feedback before continueing

  • action for all: check result and the actual rest code. Main concern: simplicity of edition - to be checked by all in the source in a dedicated branch

5min

cgnstalk: maintain or to be replaced by an alternative discussion group

  • main issue is that it is a NASA tool and getting older → less flexibility

  • currently it’s main advantage is visibility / following

  • if replaced, best within the current tools (jira/confluence) for archival; probably as close as possible to bug tracking

2min

Status of Accepted CPEX 0040

 

 

5min

Status of Accepted CPEX 0041

 

 

5min

Status of Accepted CPEX 0042

 

 

5min

Status of Accepted CPEX 0043

 

 

2min

Status of Future CPEX 0044

 

 

2min

Status of Accepted CPEX 0045

@Koen Hillewaert

@Koen Hillewaert prototype implementation working and interfaced in inhouse code.

2min

Status of Future CPEX 0046

@Thomas Hauser ​

@Thomas Hauser will organise a meeting before the next committee meeting; probably even this week.

Action items from last meetings

postponed

done, but not merged yet

Decisions

New Business

 

Any new CGNS funding proposal opportunities?

may be part of a EuroHPC proposal (Joint undertaking in H2020) on soft- and middleware on exascale → currently no calls announced, one passed in january

small work package on scalability with in house code by Cenaero in PRACE 6IP code development project

all cpex except for 41 and 45 will be in patched version; CPEX0041 in first release of v4

Schedule next meeting

10:00 AM EST (US), Apr 28, 2020

Adjourn