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

Agenda Notes Monday February 27th 2017 11:00 AM

Jump to bottom
Michael Duda edited this page Feb 27, 2017 · 4 revisions

MPAS-Developer Telecon:

Date: 27 February 2017
Time: 11:00 MST / 19:00 CET

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

Agenda Topics:

  1. Framework modifications:

  2. How are we to use the new "Reviewers" feature in github?

Notes:

Participants: Adrian, Dom, Matt, Mark

Github "Reviewers" feature: how do we use it?

A thread on StackOverflow suggests that Github had in mind that "Assignees" is used to assign Issues or to assign work on a PR to someone without write access to a repository, and "Reviewers" is used to require code reviews before a PR can be merged.

We'll try to use "Assignees" exclusively for requesting reviews of a PR:

  1. This avoids the need to scan through long comment sections for some PRs to look for approval from others
  2. It eliminates ambiguity in whether a comment was meant as approval for merge or something else
  3. It would allow the initiator of a PR to merge their own PR after all reviewers have "Approved" the PR

Framework Pull-Requests

  • 1255: In MPAS-Seaice about 75% of runtime was taken up by calls to MPAS_seekStream when using one year of forcing data at 6-hourly interval. Seeking reads all times every time we seek the stream, rendering seaice model unusable. The proposed changes are specific to files with more than 20 records and only when seeking an exact time; some additional code comments to explain this special case will exit the routine early or revert to the existing linear search would be good.

  • 1237: We just need "Approve" status from all designated reviewers.

  • 1246: A draft implementation is ready and tested in regular and debug mode, and tested with several cores active in ACME. We can successfully get logs for different cores written to correct files. Also includes modifications for OpenMP threading and foundations for interfacing to C code.

    • Probably open up PR to general testing and comments this week.
    • Probably need to convert everything at once to avoid having log information split between multiple files.
    • Mark: Give typical examples of usage in code comments? Right now, we can check the example calls in the test core (though these will be removed before merging the PR).
    • Adrian: Column physics package that writes its own message needs to work with this new logging module.
      • note: error files aren’t opened until the first write of an ERROR message to the logging module
    • Question: how should log files be named? Each core can choose any convention they like at the moment - there is the opportunity for each core to set filename templates.
Clone this wiki locally