-
Notifications
You must be signed in to change notification settings - Fork 4
Home
The examples subdirectory will contain Jupyter notebooks that demonstrate the basics of using the pytokio API to retrieve data. Because pytokio uses existing data sources, these notebooks must be run on a system that has access to the data source(s) you want. Specifically,
- NERSC's Lustre data stored in HDF5 is saved to the NERSC Global File System, so accessing it requires access to an NGF mount (e.g., from https://jupyter.nersc.gov/)
- The job accounting and diameter data relies on Slurm accounting database access via the
sacct
command. Thus, it must be run from a system that can runsacct -j 12345
and get the correct job information for job12345
.
Please don't commit directly to master. Instead, follow the protocol outlined below.
All major features should
- Have a GitHub issue opened describing the new feature
- Have a new branch named according to
yourname/githubissuenumber
; for example, a branch calledglennklockwood/issue23
will correspond to the feature described in Issue #23.
and all commits should be pushed to this branch. When the feature is complete, ensure that all unit/integration tests are passing, then create a pull request against master for that branch. A second person should review your changes and accept the merge or provide feedback on what must be changed before the branch can be merged.
Bug fixes which either
- require more than just a line or two of code changes, or
- already has a bug filed as a GitHub issue
must follow the same guidelines as the Major Features changes above. Create a new branch named yourname/githubissuenumber
, fix the bug there, and then issue a pull request to master when it is complete.
Typos, one-line bug fixes, and similarly minor features can be pushed directly to master. Please exercise good judgment when doing this; if your push to master introduces a new bug or breaks a test, you will be in trouble.