Skip to content
This repository has been archived by the owner on Oct 23, 2020. It is now read-only.

Agenda Notes Monday February 5th 2018 11:00 AM

Jump to bottom
Michael Duda edited this page Feb 6, 2018 · 10 revisions

MPAS-Developer Telecon:

Date: February 5, 2018
Time: 11:00 MDT / 19:00 CET

Call-in number: 1-866-740-1260
Access Code: 4978161

Agenda Topics:

  1. Framework modifications:
  2. Follow up on E3SM/MPAS repo set-up. Notes at: https://docs.google.com/document/d/1MGYIydK9ufuqfUySkbxcusPSPL9eGUphbot9-GP8DjE/edit?usp=sharing
    • If MPAS repository is made public, how will we handle the wiki pages (meeting notes, call-in number, etc.)?
    • How are owners of a fork of a private repository that was made public notified? How are they asked to begin paying for their private fork or to switch to a public repository?
  3. Fortran/C interoperablity-- does this work and is it already being used? The context is coupling of C/C++ based land model to MPAS-O.
    • The Fortran 2003 ISO_C_BINDING module is used in the MPAS framework
  4. Probable MPAS v5.3 release in the next couple of weeks
    • Address a moisture initialization problem in MPAS-Atmosphere
    • Maybe also include changes to the way that sub-grid-scale orography statistics are computed in the init_atmosphere core
    • Fix incorrect units for some Registry.xml tendency fields in MPAS-Atmosphere
    • Address Issue #1415 and #1493 ?
  5. Is anyone successfully running on Cori? What module environment and PIO library have been used with success?

Notes from the previous meeting:

Monday, 29 January 2018 @ 11:00 MDT

Notes:

  • MPAS / MPAS framework C/Fortran connections are very limited right now, but it isn't clear that MPAS can be easily called as a component of a C-based system under its current implementation. On C/C++ side, only Fortran code can interact with the Fortran data types, so this does not readily appear to work. Some substantial work may be needed here. @mgduda to provide some code samples to indicate accepted ways that C/Fortran interoperability may work. Fortran data structures are not directly usable by C without some type of interoperable data type and data manipulation. Limitation is ISO_C_BINDING fundamentally, which probably will require some data munging to ensure cross-compatability of C/Fortran datatypes. Custom interchange datatype for data assimilation project (OOPS) may provide a partial path forward and @mgduda can provide some code examples / connections to the OOPS project. @matthewhoffman calls C/C++ from Fortran (Fortran derived types can't be passed across and forms the bottleneck). Design and implementation of interfaces is key and probably require a customized solution. Custom code and fair amount of effort is likely required, this is non-trivial.

Participants: Mark, Todd, Xylar, Bill, Michael, Matt, Adrian

E3SM repository

  1. There is a need for some collaborators to work on private repos.
  2. If MPAS-Dev/MPAS is changed to be public, forks remain private but users with private forks get charged. Such a change would require communication with all developers with private forks, which is a downside.
  3. We can rename github repos. See https://help.github.com/articles/renaming-a-repository. If we renamed MPAS-Release (for example), we would need to inform users that they must change local repos that point to the new name.
  4. One option is to leave MPAS-Dev/MPAS as private, and then migrate needed branches to a new public repo (or renamed MPAS-Dev/MPAS-Release). Pro: users can continue private development on MPAS-Dev/MPAS with no notification. Con: All history of issues and pull requests will restart. Con: worse yet, a new repo would restart our numbering history for issues and PRs, so all old references to PRs and issues would no longer link, even though all those numbers are in the git log. Con: (really bad) there would be two of every issue/PR number, i.e. a #319 on both old and new repos, with no way to know which it is other than the date. There could be some hacky ways to transfer all issues between repos, see https://github.com/holman/ama/issues/413.
  5. The name of our working repo is important and should be considered carefully. For example, MPAS-Release implies that it is for releases only. MPAS-Public makes people wonder if there is a private one they can’t see.
  6. One option for a public/private split is to have framework be public and be a submodule in the core branches. Michael said he would prefer to look at other options to avoid the difficulty of submodules, and making sure each core is in sync with a framework on another branch.

Next Telecon

Monday 12 February 2018 @ 11:00 MDT

Clone this wiki locally