2020-4-28 Meeting notes

Approve 28 Jan 2020 minutes.

@Scot Breitenfeld ​

prioritization, review and attribution of JIRA bugs/issues

@Tony Garratt @David Gutzwiller ​

Updated Kanban Board for release of v4.2

4.2 Kanban Board:

https://cgnsorg.atlassian.net/secure/RapidBoard.jspa?rapidView=6&projectKey=CGNS

General Kanban Board:

https://cgnsorg.atlassian.net/secure/RapidBoard.jspa?rapidView=3&projectKey=CGNS&selectedIssue=CGNS-190

I would like to propose that each meeting we review the list of outstanding bugs and then prioritize those which are a “must-fix” for the next CGNS release.

David and Tony to review prior to the meeting and then discuss the top bugs in each meeting and then increase/downgrade priorities depending on opinions/discussions in the meeting.

From the list below, I have turned the outstanding Ansys suggestions/comments/request into bugs/enhancements. We can therefore from the next meeting onwards dispose with the comments below and only review the bug list board.

I would also like to initiate a discussion where we consider putting out a bug fix only release - i.e. no new features - bug fixes only.

Hope this makes sense to everyone.

Tony

Additionally, should we make the addition of HDF5 compression as a CPEX to be consider for a future release?

Platform proposals
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

#1 https://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 https://cgnsorg.atlassian.net/browse/CGNS-141

#3

- important to have parallel working

#4

#5

#6

​

high-level editing tools for the documentation page

@Marc Poinot @Christopher Rumsey ​

• No new discussion

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

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

• No new discussion.

• 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

Status of Future CPEX 0044

@Koen Hillewaert

• No new discussion

Status of Accepted CPEX 0045

@Koen Hillewaert

• No new discussion

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

Status of Future CPEX 0046

@Thomas Hauser ​

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

Sent out a doodle poll for the meeting.