## This project is a 16 colors fork of [pywal](https://github.com/dylanaraps/pywal)

Generate and change color-schemes on the fly.

Pywal is a tool that generates a color palette from the dominant colors in an image. It then applies the colors system-wide and on-the-fly in all of your favourite programs.

There are currently 5 supported color generation backends, each providing a different palette of colors from each image. You're bound to find an appealing color-scheme.

Pywal also supports predefined themes and has over 250 themes built-in. You can also create your own theme files to share with others.

The goal of Pywal was to be as out of the way as possible. It doesn't modify any of your existing configuration files. Instead it works around them and provides tools to integrate your system as you see fit.

Terminal emulators and TTYs have their color-schemes updated in real-time with no delay. With minimal configuration this functionality can be extended to almost anything running on your system.

### More: \[[Installation](https://github.com/eylles/pywal16/wiki/Installation)] \[[Getting Started](https://github.com/eylles/pywal16/wiki/Getting-Started)] \[[Customization](https://github.com/eylles/pywal16/wiki/Customization)] \[[Wiki](https://github.com/eylles/pywal16/wiki)] \[[Screenshots](https://www.reddit.com/r/unixporn/search?q=wal&restrict_sr=on&sort=relevance&t=all)]

[![Packaging status](https://repology.org/badge/vertical-allrepos/pywal16.svg)](https://repology.org/project/pywal16/versions)


# xia2

![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)
[![Language grade: Python](https://img.shields.io/lgtm/grade/python/g/xia2/xia2.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/xia2/xia2/context:python)
[![Total alerts](https://img.shields.io/lgtm/alerts/g/xia2/xia2.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/xia2/xia2/alerts/)
[![Coverage](https://codecov.io/gh/xia2/xia2/branch/master/graph/badge.svg)](https://codecov.io/gh/xia2/xia2)

xia2 is an expert system to perform X-ray diffraction data processing
on your behalf, using your software with little or no input from you.
It will correctly handle multi-pass, multi-wavelength data sets as described
later but it is not a data processing package. Specifically, if you
use xia2 in published work please include the references for the programs
it has used, which are printed at the end of the output.
The system was initially written to support remote access to synchrotron
facilities, however it may prove useful to anyone using MX, for example:

* assisting new or novice users,
* giving a second opinion to experts,
* assisting busy users to allow them to focus on problem cases, or
* providing reproducible processing.

The last of these may be most useful for users in a pharmaceutical setting,
or people wishing to test or benchmark equipment, for example beamline
scientists. In all cases however the usage of the program is the same.

Website: https://xia2.github.io
Source code: https://github.com/xia2/xia2
Support: xia2.support@gmail.com


This is the repository for the Open Tree of Life reference taxonomy
(OTT), which is only one part of the Open Tree of Life project.

For general Open Tree of Life project documentation see
[the germinator repository's wiki](https://github.com/OpenTreeOfLife/germinator/wiki).

This repository contains the following:

1. `Smasher`, a taxonomy manipulation tool
    * Java package `taxa`, general classes for taxa and taxonomies
    * Java package `smasher`, for combining taxonomies
    * Java package `conflict`, for conflict analysis
    * a variety of python utilities
1. Scripts for creating the Open Tree reference taxonomy (OTT)
    * python and shell scripts for creating OTT
    * taxonomic source information, such as the separation taxonomy, Hibbett 2007, and Schaferhoff 2012
    * scripts for making the master OTT id list

## How to use 'smasher'

See file [doc/scripting.md](doc/scripting.md)
for documentation on using the scripting features of smasher for
building, subsetting, querying, and other operations on taxonomies.

Taxonomies are represented as directories, see
[here](https://github.com/OpenTreeOfLife/reference-taxonomy/wiki/Interim-taxonomy-file-format).

To test to see whether you can run Smasher successfully, do 'make test'.

If you're puzzled by some decision the algorithm has made, it can be
helpful to look at output files log.tsv, choices.tsv, and conflicts.tsv.

## How to create a new version of OTT

See the [maintenance manual](doc/maintenance/new-release.md)


mpmath
======

|pypi version| |Build status| |Code coverage status| |Zenodo Badge|

.. |pypi version| image:: https://img.shields.io/pypi/v/mpmath.svg
   :target: https://pypi.python.org/pypi/mpmath
.. |Build status| image:: https://github.com/mpmath/mpmath/workflows/test/badge.svg
   :target: https://github.com/mpmath/mpmath/actions?workflow=test
.. |Code coverage status| image:: https://codecov.io/gh/mpmath/mpmath/branch/master/graph/badge.svg
   :target: https://codecov.io/gh/mpmath/mpmath
.. |Zenodo Badge| image:: https://zenodo.org/badge/2934512.svg
   :target: https://zenodo.org/badge/latestdoi/2934512

A Python library for arbitrary-precision floating-point arithmetic.

Website: https://mpmath.org/
Main author: Fredrik Johansson <fredrik.johansson@gmail.com>

Mpmath is free software released under the New BSD License (see the
LICENSE file for details).

0. History and credits
----------------------

The following people (among others) have contributed major patches
or new features to mpmath:

* Pearu Peterson <pearu.peterson@gmail.com>
* Mario Pernici <mario.pernici@mi.infn.it>
* Ondrej Certik <ondrej@certik.cz>
* Vinzent Steinberg <vinzent.steinberg@gmail.com>
* Nimish Telang <ntelang@gmail.com>
* Mike Taschuk <mtaschuk@ece.ualberta.ca>
* Case Van Horsen <casevh@gmail.com>
* Jorn Baayen <jorn.baayen@gmail.com>
* Chris Smith <smichr@gmail.com>
* Juan Arias de Reyna <arias@us.es>
* Ioannis Tziakos <itziakos@gmail.com>
* Aaron Meurer <asmeurer@gmail.com>
* Stefan Krastanov <krastanov.stefan@gmail.com>
* Ken Allen <ken.allen@sbcglobal.net>
* Timo Hartmann <thartmann15@gmail.com>
* Sergey B Kirpichev <skirpichev@gmail.com>
* Kris Kuhlman <kristopher.kuhlman@gmail.com>
* Paul Masson <paulmasson@analyticphysics.com>
* Michael Kagalenko <michael.kagalenko@gmail.com>
* Jonathan Warner <warnerjon12@gmail.com>
* Max Gaukler <max.gaukler@fau.de>
* Guillermo Navas-Palencia <g.navas.palencia@gmail.com>
* Nike Dattani <nike@hpqc.org>

Numerous other people have contributed by reporting bugs,
requesting new features, or suggesting improvements to the
documentation.

For a detailed changelog, including individual contributions,
see the CHANGES file.

Fredrik's work on mpmath during summer 2008 was sponsored by Google
as part of the Google Summer of Code program.

Fredrik's work on mpmath during summer 2009 was sponsored by the
American Institute of Mathematics under the support of the National Science
Foundation Grant No. 0757627 (FRG: L-functions and Modular Forms).

Any opinions, findings, and conclusions or recommendations expressed in this
material are those of the author(s) and do not necessarily reflect the
views of the sponsors.

Credit also goes to:

* The authors of the GMP library and the Python wrapper
  gmpy, enabling mpmath to become much faster at
  high precision
* The authors of MPFR, pari/gp, MPFUN, and other arbitrary-
  precision libraries, whose documentation has been helpful
  for implementing many of the algorithms in mpmath
* Wikipedia contributors; Abramowitz & Stegun; Gradshteyn & Ryzhik;
  Wolfram Research for MathWorld and the Wolfram Functions site.
  These are the main references used for special functions
  implementations.
* George Brandl for developing the Sphinx documentation tool
  used to build mpmath's documentation

Release history:

* Version 1.3.0 released on March 7, 2023
* Version 1.2.1 released on February 9, 2021
* Version 1.2.0 released on February 1, 2021
* Version 1.1.0 released on December 11, 2018
* Version 1.0.0 released on September 27, 2017
* Version 0.19 released on June 10, 2014
* Version 0.18 released on December 31, 2013
* Version 0.17 released on February 1, 2011
* Version 0.16 released on September 24, 2010
* Version 0.15 released on June 6, 2010
* Version 0.14 released on February 5, 2010
* Version 0.13 released on August 13, 2009
* Version 0.12 released on June 9, 2009
* Version 0.11 released on January 26, 2009
* Version 0.10 released on October 15, 2008
* Version 0.9 released on August 23, 2008
* Version 0.8 released on April 20, 2008
* Version 0.7 released on March 12, 2008
* Version 0.6 released on January 13, 2008
* Version 0.5 released on November 24, 2007
* Version 0.4 released on November 3, 2007
* Version 0.3 released on October 5, 2007
* Version 0.2 released on October 2, 2007
* Version 0.1 released on September 27, 2007

1. Download & installation
--------------------------

Mpmath requires Python 3.8 or later versions.  It has been tested with CPython
3.8 through 3.13 and for PyPy 3.9 through 3.10.

The latest release of mpmath can be downloaded from the mpmath
website and from https://github.com/mpmath/mpmath/releases

It should also be available in the Python Package Index at
https://pypi.python.org/pypi/mpmath

To install latest release of Mpmath with pip, simply run

``pip install mpmath``

or from the source tree

``pip install .``

The latest development code is available from
https://github.com/mpmath/mpmath

See the main documentation for more detailed instructions.

2. Documentation
----------------

Documentation in reStructuredText format is available in the
docs directory included with the source package. These files
are human-readable, but can be compiled to prettier HTML using
`Sphinx <https://www.sphinx-doc.org/>`_.

The most recent documentation is also available in HTML format:

https://mpmath.org/doc/current/

3. Running tests
----------------

The unit tests in mpmath/tests/ can be run with `pytest
<https://pytest.org/>`_, see the main documentation.

You may also want to check out the demo scripts in the demo
directory.

The master branch is automatically tested on the Github Actions.

4. Known problems
-----------------

Mpmath is a work in progress. Major issues include:

* Some functions may return incorrect values when given extremely
  large arguments or arguments very close to singularities.

* Directed rounding works for arithmetic operations. It is implemented
  heuristically for other operations, and their results may be off by one
  or two units in the last place (even if otherwise accurate).

* Some IEEE 754 features are not available. Inifinities and NaN are
  partially supported; denormal rounding is currently not available
  at all.

* The interface for switching precision and rounding is not finalized.
  The current method is not threadsafe.

5. Help and bug reports
-----------------------

General questions and comments can be `sent <mailto:mpmath@googlegroups.com>`_
to the `mpmath mailinglist <https://groups.google.com/g/mpmath>`_.

You can also report bugs and send patches to the mpmath issue tracker,
https://github.com/mpmath/mpmath/issues


.. highlight: sh

Open edX Webhooks Handlers (and Other JIRA/GitHub Utilities)
============================================================

Webhooks for `Open edX`_ integrating JIRA and GitHub. Designed to
be deployed at `Heroku`_.

`Access the app`_ at https://openedx-webhooks.herokuapp.com.

|Build Status| |Coverage Status| |Documentation badge|

Set Up Development Environment
------------------------------

Prerequisites
~~~~~~~~~~~~~

Make sure you've installed:

-  Python 3.10.x development environment
   (virtualenv strongly recommended)
-  `Heroku Command Line`_

   All ``heroku`` commands can be performed through the Heroku web-based
   dashboard as well, if you don't want to use the CLI.

Set up
~~~~~~

Log in using the email address and password you used when creating
your Heroku account::

    make deploy-configure

Authenticating is required to allow both the ``heroku`` and ``git``
commands to operate.

Alternatively, to authenticate with SSH keys::

    make deploy-configure DEPLOY_USE_SSH=true

You should see output similar to::

    heroku  https://git.heroku.com/openedx-webhooks-staging.git (push)
    heroku  https://git.heroku.com/openedx-webhooks-staging.git (fetch)
    origin  git@github.com:edx/openedx-webhooks.git (fetch)
    origin  git@github.com:edx/openedx-webhooks.git (push)

Develop
-------

This app relies on the following addons from Heroku:

-  Redis
-  Papertrail
-  Scheduler

While it's possible to replicate the entire stack locally, it'll be
difficult to ensure consistent experience for each developer. Instead,
we utilize the `pipeline`_ facility offered by Heroku to handle our
development needs.

The general development cycle is:

Code → Deploy branch to staging → Test → Iterate

To deploy your current working branch to staging::

    make deploy-stage-branch

To deploy an arbitrary branch::

    make deploy-stage-branch DEPLOY_STAGING_BRANCH=feat/my-branch

Once you're satisfied with your changes, go ahead and open a pull
request per normal development procedures.

Smoke test the deployment.

If the application isn't running, visit the `openedx-webhooks-staging
Resources`_ page to make sure there are dynos running.

.. _openedx-webhooks-staging Resources: https://dashboard.heroku.com/apps/openedx-webhooks-staging/resources

Run Tests
---------

::

    make install-dev-requirements test

If you are testing a change to `repo-tools-data-schema`_, you need to coordinate
changes in both repos:

- Name your branch here the same as your branch in repo-tools-data-schema.

- Be sure your changes in repo-tools-data-schema are pushed to your branch on
  GitHub.

- Run ``make testschema`` to install your branch of repo-tools-data-schema in
  this virtualenv.

- Run tests here as usual.

.. _repo-tools-data-schema: https://github.com/openedx/repo-tools-data-schema

Deploy
------

In most cases, you'll want to deploy by promoting from staging to
production. The general workflow is:

Merge to ``master`` → Deploy ``master`` to staging → Test → Promote to
production

**Prior to the promotion**, make sure all the changes have been merged
to ``master``, and you've deployed the ``master`` branch successfully to
staging::

    make deploy-stage

When you're ready to promote from staging to production::

    make deploy-prod

Make sure the same git commit is deployed to both environments.

Make sure the abbreviated git SHAs match.

Smoke test the deployment.

Other things to know
--------------------

**This should no longer be an issue as of July 9th, 2018.**

If you re-process pull requests, an unfortunate thing can happen: it will find
stale pull requests that were written by edX employees who have now left.  The
bot will see that the author has no contributor agreement, and will make a new
JIRA issue for the pull request.  This is needless noise.

The bot looks for comments it wrote that have a JIRA issue id in them.  You can
leave the bot comment on the stale pull request so that at least it won't happen
again in the future.

Configuring a webhook
---------------------

On GitHub, visit the repo webhooks
(``https://github.com/<ORG>/<REPO>/settings/hooks``) or organization webhooks
(``https://github.com/organizations/<ORG>/settings/hooks``) page.

Create or edit a webhook.

- Payload URL: https://openedx-webhooks.herokuapp.com/github/hook-receiver
- Content type: application/json
- Secret: same as setting GITHUB_WEBHOOK_SECRET in Heroku
- Events:
    - Issue comments
    - Pull requests
    - Pull request reviews
    - Pull request review comments

Changelog
---------

Unreleased
~~~~~~~~~~

See the fragment files (if any) in the changelog.d directory.

.. scriv-insert-here

2023-12-07
~~~~~~~~~~

- When a pull request is closed, if it doesn't have a
  "open-source-contribution" label on it, it is considered an internal pull
  request.  We assume that it was processed when it was opened, and since it
  didn't get the label then, the author must have been internal at the time.

2023-11-27
~~~~~~~~~~

- Now issues created in Jira will have a label of "from-GitHub" on them. Closes
  `issue 279`_.

- Two possible errors with "jira:foo" labels now create bot comments so people
  understand why there's no Jira issue. Closes `issue 280`_.

- Fix: we no longer comment twice on a pull request closed with a comment.
  Closes `issue 277`_.

.. _issue 277: https://github.com/openedx/openedx-webhooks/issues/277
.. _issue 279: https://github.com/openedx/openedx-webhooks/issues/279
.. _issue 280: https://github.com/openedx/openedx-webhooks/issues/280

2023-11-03
~~~~~~~~~~

- Don't add a "no contributions accepted" comment if the pull request is being
  closed. It's needlessly discouraging. Fixed #273.

2023-10-31
~~~~~~~~~~

- Adding a label like ``jira:xyz`` to a pull request will look in a private
  registry of Jira servers for one nicknamed ``xyz``, and then create a Jira
  issue there to correspond to the pull request.

2023-09-13
~~~~~~~~~~

- The CLA check used to fail if a pull request had more than 100 commits.  Now
  the head sha is retrieved directly without listing all commits, so the number
  is irrelevant.

2023-08-30
~~~~~~~~~~

- Adding a comment to pull request now re-runs the checks and updates the state
  of the pull request.  Previously, we'd edit the title of the PR to trigger
  updates.

2023-08-11
~~~~~~~~~~

- Removed: the bot no longer understands the past state of users.  This data
  hasn't been maintained for the last few years.  There's no point relying on
  stale data, so the capability is removed.

- Removed: any understanding of who is a core contributor.  The bot no longer
  makes comments or labels particular to core contributors. `Issue 227`_.

.. _issue 227: https://github.com/openedx/openedx-webhooks/issues/227

- Removed: we no longer read people.yaml.

- Removed: we no longer add "jenkins ok to test" to start testing, since that
  comment was only read by Jenkins, which we no longer use.

2023-08-03
~~~~~~~~~~

- Jira authentication now uses the JIRA_USER_EMAIL and JIRA_USER_TOKEN
  environment variables.  OAuth authentication is removed. These settings are
  now obsolete and can be deleted:

  - DATABASE_URL
  - GITHUB_OAUTH_CLIENT_ID
  - GITHUB_OAUTH_CLIENT_SECRET
  - JIRA_OAUTH_CONSUMER_KEY
  - JIRA_OAUTH_RSA_KEY
  - SQLALCHEMY_DATABASE_URI

- Stopped the bot from updating a repository's labels based on ``labels.yaml``, as this is now handled by the `repo_checks <https://github.com/openedx/repo-tools/tree/master/edx_repo_tools/repo_checks>`_ tool. The ``labels.yaml`` file is now unused and can be safely deleted from any openedx-webhooks data repositories.

- Stopped the bot from adding the ``core committer`` GitHub label to pull requests to repos on which the bot believes the author to have write access. The bot's data source for repository access, ``people.yaml``, is outdated, we do not yet have a strategy for keeping it updated. Until further notice, coding Core Contributors are asked to add the ``core contributor`` label to their pull requests manually.

2023-03-03
~~~~~~~~~~

- Removed the code that used the now-obsolete ``internal`` setting in
  orgs.yaml.

- Tweaked the CLA messages.

2023-03-02
~~~~~~~~~~

- The "internal" setting is being replaced by an "internal-ghorgs" list on an
  institution.  A pull request is now internal if the author's associated
  institution (in orgs.yaml) has the org the PR is being made to as an
  internal-ghorgs org.  The old "internal" setting is still used, but we'll be
  deleting it once the new code is in place.

2023-01-30
~~~~~~~~~~

- Added: contribution pull requests will be added to GitHub projects if the
  base repo says to by adding an "openedx.org/add-to-projects" annotation in
  its catalog-info.yaml file.

2022-07-21
~~~~~~~~~~

- Adding a pull request to a project could fail if the two are in different
  GitHub orgs (like edx and openedx).  This failure used to stop the bot from
  making further changes, but now we log the exception and continue.

2022-06-13
~~~~~~~~~~

- Removing the JIRA_SERVER setting will disable Jira access for the bot. No Jira
  issues will be created or updated.

2022-06-03
~~~~~~~~~~

- Blended pull requests now go into a separate project, specified with
  the GITHUB_BLENDED_PROJECT setting.

2022-06-01
~~~~~~~~~~

- The JIRA server is now configurable with the JIRA_SERVER environment
  variable.

- New external pull requests will be added to a GitHub project.  The project is
  configurable with the GITHUB_OSPR_PROJECT environment variable.

- Removed mention of unused JIRA credentials JIRA_ACCESS_TOKEN and
  JIRA_ACCESS_TOKEN_SECRET.

2022-04-06
~~~~~~~~~~

- Repos with more than 30 labels might not have properly labelled pull requests
  that transitioned into late-alphabet statuses (like Open edX Community
  Review).  This is now fixed.

2022-04-05
~~~~~~~~~~

- Load yaml and csv data files from the `openedx/openedx-webhooks-data` repo.

2022-03-25
~~~~~~~~~~

- Pull requests can now be closed and re-opened.  When the pull request is
  re-opened, the survey comment that was added on closing is deleted.  The Jira
  ticket is returned to the state it was in before the pull request was closed.

2022-01-27
~~~~~~~~~~

- Removed the code that handled "contractor" pull requests, where the bot
  couldn't know if an OSPR ticket was needed or not.

- The CLA check is now applied to all pull requests, even edX internal ones.

2021-12-20
~~~~~~~~~~

- The bot now ignores any private repo in the edx organization.

2021-12-17
~~~~~~~~~~

- We no longer use OAuth authentication for GitHub.  All access is with a
  personal access token.

- The bot now depends on a csv generated by Salesforce to inform which users
  have signed the Contributor License Agreement (CLA)

- After processing a pull request, the GitHub rate limit is checked and logged:
    Rate limit: 5000, used 29, remaining 4971. Reset is at 2021-12-16 23:26:48

- The "needs CLA" message now includes the possibility that you've signed
  before and need to re-sign.

2021-09-29
~~~~~~~~~~

- Removed the NEED-CLA label. We have a check now, which is better.

2021-09-14
~~~~~~~~~~

- Due to an internal refactoring, now rescanning pull requests will add the
  end-of-pull-request survey comment if needed.

- Four Jira fields are no longer updated:
    'Github PR Last Updated At'
    'Github PR Last Updated By'
    'Github Latest Action'
    'Github Latest Action by edX'

2021-09-13
~~~~~~~~~~

- A GitHub check indicates whether the author has a contributor agreement or
  not.

2021-09-02
~~~~~~~~~~

- Fix an assertion error that could happen if a pull request had no body
  (description).  The assertion was:

      File "/app/openedx_webhooks/tasks/jira_work.py", line 117, in update_jira_issue
        assert fields

- Change error handling so that more actions can complete even if one fails.

2021-08-30
~~~~~~~~~~

- Removed one setting: JIRA_OAUTH_PRIVATE_KEY, which was just JIRA_OAUTH_RSA_KEY base64 encoded.

2021-08-18
~~~~~~~~~~

- fix: all UI pages are now protected with basic auth.

2021-02-25
~~~~~~~~~~

- Update the CLA link to go to https://openedx.org/cla, which currently
  redirects to our new Docusign form.  If we have to change the form in the
  future, we can change the redirect on openedx.org.

2021-01-22
~~~~~~~~~~

- When considering a pull request, we won't update the Jira extra fields if
  none of our desired fields are different.  We used to update a Jira issue if
  (for example) it had platform map info, but we didn't want to add platform
  map info.

2021-01-21
~~~~~~~~~~

- More control over rescanning:

  - You can provide an earliest and latest date to consider.  Only pull
    requests created within that window will be rescanned.

    Rescanning never considers pull requests created before 2018.  This is a
    quick fix to deal with contractor comments.

    Because we don't track when companies started and stopped being
    contractors, we can't decide now if a pull request should have had a
    contractor comment when it was created.

    The latest contractor comment on one of our pull requests was in December
    2017.  So don't consider pull requests that old.  Later we can implement a
    better solution if we need to rescan those old pull requests.

  - Rescanning now has a dry-run mode which records what would have been done,
    but takes no action.

- Before-clauses in people.yaml are now handled differently.  Previously, only
  one before clause was found, the earliest one that applied to the date we're
  interested in.  Now, all before clauses that apply (with dates after the date
  we are interested in) are layered together starting with now and working
  back in time to build a dict of data.

- Updates to Jira tickets will try not to notify users unless the title or body
  (summary or description) change.  This requires that the bot Jira user be an
  administrator of the projects it is updating.

2021-01-08
~~~~~~~~~~

- Rescanning changes:

  - Now you have the option to include closed pull requests.

  - Pull requests are fetched in full to ensure all the needed fields will be
    available.

2020-11-24
~~~~~~~~~~

- The bot used to create a Jira issue to replace an issue that had been
  deleted.  This interfered with rescanning, so the bot no longer does this.
  If a Jira issue mentioned in the bot comment has been deleted, it will not be
  recreated.

2020-10-29
~~~~~~~~~~

- The number of lines added and deleted by a pull request are recorded in
  custom Jira fields.

2020-10-15
~~~~~~~~~~

- Core Committer pull requests now start with a Jira status of "Waiting on
  Author" rather than "Open edX Community Review".

2020-09-23
~~~~~~~~~~

- Draft pull requests start with a status of "Waiting on Author".  Once the
  pull request is no longer a draft, the status is set to the initial status it
  would have originally had.

2020-08-08
~~~~~~~~~~

- BUG: if the PR description was edited, the Jira issue status would be
  incorrectly reset to its initial value [OPENEDX-424].  This is now fixed.

2020-08-07
~~~~~~~~~~

- When a core committer merges a pull request, the bot will add a comment
  pinging the committer's edX champions to let them know the merge has
  happened.

- BUG: previously the bot could clobber ad-hoc labels on Jira issues when it
  set its own labels.  This is now fixed.  The bot will preserve any labels it
  didn't make.

- Removed the code that managed webhooks in repos.

- Refactored some code that handles pull requests being closed, so now it
  operates on any change to the pull request.  The behavior should be the same,
  except now if a pull request is closed or merged after the Jira issue has
  been manually deleted, the bot will create a new issue so that it can mark it
  Rejected or Merged.

2020-07-24
~~~~~~~~~~

- BUG: previously, the bot might change GitHub labels and incorrectly drop
  ad-hoc labels that people had put on the pull request.  This is now fixed.

2020-07-23
~~~~~~~~~~

- GitHub very occasionally sends us a pull request event, but then serves us a
  404 error when we ask it about the pull request.  Now the bot will retry GET
  requests that return 404, to give GitHub a chance to get its act together.

- BUG: when a pull request was edited, the associated Jira issue would be reset
  to its initial status.  This is now fixed: the Jira status is unchanged.

2020-07-21
~~~~~~~~~~

- Previously, if an OSPR issue had been manually moved to BLENDED, and then the
  title of the pull request amended to have "[BD-xx]", the bot would try and
  fail to delete the moved issue.  Now it understands the move, and doesn't
  try to delete the original issue.  It also updates the issue with Blended
  information.

2020-07-20
~~~~~~~~~~

- Changes to the title or description of a pull request are copied over to the
  associated Jira issue to keep them in sync.

- If a change to a pull request requires a different Jira issue, the old issue
  is deleted, and a new one made.  For example, if a blended pull request
  doesn't have "[BD-xx]" in the title, an OSPR issue gets made initially.
  Now when the developer updates the title, the OSPR issue is deleted, and a
  new BLENDED issue is created for it.

2020-07-14
~~~~~~~~~~

- The "expires_on" key in people.yaml is officially obsolete, and no longer
  interpreted.

- Some incorrect CLA logic was fixed. An entry in people.yaml with no
  "expires_on" key would be considered to have a signed CLA, even if the
  agreement was "none".

2020-07-02
~~~~~~~~~~

- If an opened pull request has a CLA, then the bot will comment "jenkins ok to
  test" on it to get the tests started automatically.

2020-07-01
~~~~~~~~~~

- Blended workflow: if "[BD-XX]" is found in the title of an opened pull
  request, then the Jira ticket will be in the BLENDED project, with links to
  the correct epic, etc.

2020-06-25
~~~~~~~~~~

- Core committer logic has to be particular to specific repos, it's not a
  blanket right.  Now "committer" isn't a simple boolean, it's an object with
  subkeys: "repos" is a list of repos the user can commit to, and "orgs" is a
  list of GitHub organizations the user can commit to (any repo).

2020-06-24
~~~~~~~~~~

- Slight change to people.yaml schema: "internal:true" is used to indicate edX
  people (or Arbisoft).  The "committer:true" flag indicates core committers.

- Core committer pull request handling: a different welcome message is used,
  OSPR issues are started in the "Open edX Community Review" status, and "core
  committer" GitHub and Jira labels are applied.

2020-06-19
~~~~~~~~~~

- We used to have two GitHub webhooks.  They have been combined.  Only
  /github/hook-receiver is needed now.  The obsolete /github/pr endpoint still
  exists just to log unneeded webhook action so we can fix the GitHub
  configuration.

2020-06-15
~~~~~~~~~~

- Labels in GitHub repos are synchronized from repo-tools-data/labels.yaml
  before any labels are adjusted in the repo.

- Data read from repo-tools-data (people.yaml, label.yaml) is only cached for
  15 minutes. It used to be until the bot was restarted.

2020-06-08
~~~~~~~~~~

- Pull requests that need a CLA signed now create Jira tickets in the
  "Community Manager Review" status.

TODO
----

-  Describe the different processes that are run on Heroku
-  Describe how to access logs
-  Make sure ``docs/`` is up to date

.. _Open edX: http://openedx.org
.. _Heroku: http://heroku.com
.. _Access the app: https://openedx-webhooks.herokuapp.com
.. _Heroku Command Line: https://devcenter.heroku.com/articles/heroku-command-line
.. _pipeline: https://devcenter.heroku.com/articles/pipelines

.. |build-status| image:: https://github.com/openedx/openedx-webhooks/workflows/Python%20CI/badge.svg?branch=master
   :target: https://github.com/openedx/openedx-webhooks/actions?query=workflow%3A%22Python+CI%22
.. |Coverage Status| image:: http://codecov.io/github/edx/openedx-webhooks/coverage.svg?branch=master
   :target: http://codecov.io/github/edx/openedx-webhooks?branch=master
.. |Documentation badge| image:: https://readthedocs.org/projects/openedx-webhooks/badge/?version=latest
   :target: http://openedx-webhooks.readthedocs.org/en/latest/


# 1 / 🚀 = reciprocalspaceship
![Build](https://github.com/rs-station/reciprocalspaceship/workflows/Build/badge.svg)
[![Documentation](https://github.com/rs-station/reciprocalspaceship/workflows/Documentation/badge.svg)](https://rs-station.github.io/reciprocalspaceship)
[![PyPI](https://img.shields.io/pypi/v/reciprocalspaceship?color=blue)](https://pypi.org/project/reciprocalspaceship/)
[![Anaconda-Server Badge](https://anaconda.org/conda-forge/reciprocalspaceship/badges/version.svg)](https://anaconda.org/conda-forge/reciprocalspaceship)
[![codecov](https://codecov.io/gh/rs-station/reciprocalspaceship/branch/main/graph/badge.svg)](https://codecov.io/gh/rs-station/reciprocalspaceship)
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://github.com/rs-station/reciprocalspaceship/blob/main/LICENSE)
[![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/rs-station/reciprocalspaceship/main?filepath=docs%2Fexamples)
[![DOI](https://img.shields.io/badge/DOI-10.1107%2FS160057672100755X-blue)](https://doi.org/10.1107/S160057672100755X)

Tools for exploring reciprocal space.

`reciprocalspaceship` provides a `pandas`-style interface for
analyzing and manipulating reflection data from crystallography
experiments. Using this library, it is possible to interactively
work with crystallographic data in Python, enabling easy
integration with modern scientific computing libraries. `reciprocalspaceship`
is intended to support the rapid prototyping of new crystallographic methods and
custom analyses while maintaining clear and performant code.

Features of this library include:

- Crystallographically-aware `pandas` objects, datatypes, and syntax that are familiar to Python users.
- Convenient integration with [GEMMI](https://gemmi.readthedocs.io/en/latest/) to provide built-in methods and
  support for developing functions that use space groups, unit cell parameters, and crystallographic
  symmetry operations.
- Support for reading and writing MTZ reflection files.

## Installation

The fastest way to install `reciprocalspaceship` is using `pip`:

```
pip install reciprocalspaceship
```

or using `conda`:

```
conda install -c conda-forge reciprocalspaceship
```

For more installation information, see our [installation guide](https://rs-station.github.io/reciprocalspaceship/userguide/installation.html).

## Quickstart

To get started with `reciprocalspaceship`, see our [quickstart guide](https://rs-station.github.io/reciprocalspaceship/examples/quickstart.html).

## Documentation

For more details on the use of `reciprocalspaceship`, check out our [documentation](https://rs-station.github.io/reciprocalspaceship).

## Reference

Our paper describing the library was published in the Journal of Applied Crystallography: [link to paper](https://doi.org/10.1107/S160057672100755X).
Please cite this publication for any work that makes use of this library.

We also have a pre-print describing the library on [bioRxiv](https://www.biorxiv.org/content/10.1101/2021.02.03.429617v1).


# Infrastructure as code

Treating Haiku's infrastructure as cattle instead of kittens since 2017.

## Directories

  * docs - Full documentation on Haiku's infrastructure
  * containers - Manifests to build and deploy containers
  * deployments - Kubernetes manifests for Haiku infrastructure
  * playground - Things that we're experimenting with. Not used in production.

# Architecture

![Architecture](docs/architecture.png)

# Quickstart

These are the path of least resistance for new admins to do "things"

| :boom: DANGER                                                        |
|:---------------------------------------------------------------------|
|*Never* run ```kubectl delete``` on persistent volume claims you need! Running ```kubectl delete``` / ```kubectl delete -f ``` on things describing volume claims will result in Kubernetes dropping (deleting) persistant volumes. (AKA massive + rapid data loss)|

Running through the [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) class is recommended!

## Pre-requirements

* Install kubectl
* Export the Kubernetes configuration from Digital Ocean, import locally
  * If this is your first kubernetes cluster, just put it at ```~/.kube/config```

## Quick Commands

> aka, i'm a sysadmin and a dog in a lab-coat

### Check your configured cluster

*List the known Kubernetes Clusters (contexts) of my client:*
```
kubectl config get-contexts
```

*Change the Kubernetes Cluster my local client focuses on:*
```
kubectl config use-context (NAME)
```

### List Deployments

> Deployments are "how many desired sets of pods" within the cluster.

```
kubectl get deployments
```

### Scaling Deployments

If you want something to "stop running for a while", this is the easiest
and safest way.  NEVER run ```kubectl delete``` if you don't know what
you're doing.

```
kubectl scale --replicas=0 deployments/(NAME)
```

### List Pods

> Pods are one or more tightly related containers running in Kubernetes
> Deleting a Pod will result in the related deployment recreating it.

### Entering a container

aka, equavient to ```docker exec -it (NAME) /bin/bash -l...```

If the pod has one container:

```
kubectl exec -it pod/(NAME) -- /bin/bash -l
```

If the pod has multiple containers:

```
kubectl exec -it pod/(NAME) -c containername -- /bin/bash -l
```

### Examining Stuff

```
kubectl describe pod/(NAME)
kubectl describe deployment/(NAME)
```

## Initial Installation

* Deploy ingress controller via instructions in deployments/ingress-controller/traefik
* Deploy manifests in deployments for various services
* Scale each deployment to 0 replicas
  * ```kubectl scale --replicas=0 deployments/(BLAH)```
* Populate persistent volumes for each application
  * see tools/migration_tools for some scripts to do this en-masse via rsync
* Once ready for switchover, adjust DNS to new load balancer
* Scale up applications
* ```kubectl scale --replicas=1 deployments/(BLAH)```

## Rolling Restarts

*To perform a rolling restart of each deployment replica:*
```
kubectl rollout restart deployment/(NAME)
```

### Example

> -n kube-system is the namespace. We run Traefik in a seperate namespace since it's important.

*Rolling restart of Traefik:*
```
kubectl -n kube-system rollout restart daemonset/traefik-ingress-controller
```

## Rolling Upgrade

Here we upgrade a container image from the command line.  You can also update the matching yml document
and run ```kubectl apply -f (thing).yml```

### Example

> -n kube-system is the namespace. We run Traefik in a seperate namespace since it's important.

*Rolling upgrade of Traefik:*
```
kubectl -n kube-system set image daemonset/traefik-ingress-controller traefik-ingress-lb=docker.io/traefik:v2.6
```

## Accessing Services / Pods

You can port-forward / tunnel from various points within the Kubernetes cluster to your local desktop. This is really
useful for troubleshooting or understanding issues better.

*Listen on localhost port 8888, to port 9999 within the pod*
```
kubectl port-forward pod/(NAME) 8888:9999
```

*Listen on localhost port 8080, to named port web of the service*
```
kubectl port-forward service/(NAME) 8080:web
```

Pressing ctl+c will terminate the port-forwarding proxy

## Importing data

*Restoring volume / database backups:*
**See deployments/other/restore*.yml**

*Manual database import:*
```cat coolstuff.sql | kubectl exec -i deployment/postgres -- psql -U postgres```

## Forcing CronJobs

We leverage multiple jobs to perform various automatic activities within kubernetes. Some example
jobs include postgresql backups to s3, persistent volume backups to s3, and syncing various git
repositories.

Once and a while, you may want to force these jobs to run before performing maintenance, or for
testing purposes.

* pgbackup - PostgreSQL backup jobs
* pvbackup - Persistent volume backup jobs

> There are several example restore jobs in deployments/other.  These can be manually edited
> and applied to restore data.  It's highly recommended to review these CAREFULLY before use
> as a mistake could result in unattended data loss.
>
> These restore jobs should be used on empty databases / persistent volumes only!

1. Listing CronJobs
    ```
    $ kubectl get cronjobs
    NAME                        SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    discourse-pgbackup          0 0 * * 1,4   False     0        2d14h           6d13h
    discourse-pvbackup          0 3 * * 3     False     0        11h             6d17h
    gerrit-github-sync          0 * * * *     False     0        38m             13d
    gerrit-pvbackup             0 1 * * 1,4   False     0        2d13h           8d
    haikudepotserver-pgbackup   0 0 * * 1,4   False     0        2d14h           3d21h
    .
    ```
2. Forcing a CronJob to run
    This is a great thing to do before any maintenance :-)
    ```
    $ kubectl create job --from=cronjob/discourse-pgbackup discourse-pgbackup-manual-220316
    ```
3. Monitoring manual CronJob
    ```
    $ kubectl get jobs
    NAME                                 COMPLETIONS   DURATION   AGE
    discourse-pgbackup-manual-220316     1/1           1m         1m

    $ kubectl logs jobs/discourse-pgbackup-manual-220316
    Backup discourse...
    Backup complete!
    Encryption complete!
    Added `s3remote` successfully.
    `/tmp/discourse_2022-03-14.sql.xz.gpg` -> `s3remote/haiku-backups/pg-discourse/discourse_2022-03-14.sql.xz.gpg`
    Total: 0 B, Transferred: 136.45 MiB, Speed: 77.32 MiB/s
    Snapshot of discourse completed successfully! (haiku-backups/pg-discourse/discourse_2022-03-14.sql.xz.gpg)
    ```

# Secrets

For obvious reasons, :key: secrets are omitted from this repository.


scqubits: superconducting qubits in Python
===========================================

[![Anaconda-Server Badge](https://anaconda.org/conda-forge/scqubits/badges/downloads.svg)](https://anaconda.org/conda-forge/scqubits)
[![CodeFactor](https://www.codefactor.io/repository/github/scqubits/scqubits/badge)](https://www.codefactor.io/repository/github/scqubits/scqubits)
[![codecov](https://codecov.io/gh/scqubits/scqubits/branch/master/graph/badge.svg?token=PUBXSHF6HU)](https://codecov.io/gh/scqubits/scqubits)

[J. Koch](https://github.com/jkochNU), [P. Groszkowski](https://github.com/petergthatsme)

> **Join the scqubits mailing list!** Receive information about new releases
> and opportunities to contribute
> to new developments.
> |[SIGN UP](https://sites.northwestern.edu/koch/scqubits-news-sign-up/)|
> |---------------------------------------------------------------------|

scqubits is an open-source Python library for simulating superconducting qubits. It is meant to give the user
a convenient way to obtain energy spectra of common superconducting qubits, plot energy levels as a function of
external parameters, calculate matrix elements etc. The library further provides an interface to QuTiP, making it
easy to work with composite Hilbert spaces consisting of coupled superconducting qubits and harmonic modes.
Internally, numerics within scqubits is carried out with the help of Numpy and Scipy; plotting capabilities rely on
Matplotlib.

If scqubits is helpful to you in your research, please support its continued
development and maintenance. Use of scqubits in research publications is
appropriately acknowledged by citing:

    Peter Groszkowski and Jens Koch,

    *scqubits:  a Python package for superconducting qubits*,

    Quantum 5, 583 (2021).

    https://quantum-journal.org/papers/q-2021-11-17-583/

    Sai Pavan Chitta, Tianpu Zhao, Ziwen Huang, Ian Mondragon-Shem, and Jens Koch,

    *Computer-aided quantization and numerical analysis of superconducting circuits*,

    New J. Phys. 24 103020 (2022).

    https://iopscience.iop.org/article/10.1088/1367-2630/ac94f2

Download and Installation
-------------------------

For Python 3.7 - 3.12: installation via conda is supported.
```
conda install -c conda-forge scqubits
```

Alternatively, scqubits can be installed via pip (although it should be noted that installing via pip under a conda environment is strongly discouraged, and is not guaranteed to work - see conda documentation).
```
pip install scqubits
```

Documentation
-------------

The documentation for scqubits is available at: https://scqubits.readthedocs.io

Related Packages
----------------

There are two related packages on github:

documentation source code: https://github.com/scqubits/scqubits-doc
example notebooks: https://github.com/scqubits/scqubits-examples

Contribute
----------

You are welcome to contribute to scqubits development by forking this repository and sending pull requests,
or filing bug reports at the
[issues page](https://github.com/scqubits/scqubits/issues).

All contributions are acknowledged in the
[contributors](https://scqubits.readthedocs.io/en/latest/contributors.html)
section in the documentation.

All contributions are expected to be consistent with [PEP 8 -- Style Guide for Python Code](https://www.python.org/dev/peps/pep-0008/).

License
-------
[![license](https://img.shields.io/badge/license-New%20BSD-blue.svg)](http://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_.28.22Revised_BSD_License.22.2C_.22New_BSD_License.22.2C_or_.22Modified_BSD_License.22.29)

You are free to use this software, with or without modification, provided that the conditions listed in the LICENSE file are satisfied.


Bit-Bots Vision
===============

[![CodeFactor](https://www.codefactor.io/repository/github/bit-bots/bitbots_vision/badge)](https://www.codefactor.io/repository/github/bit-bots/bitbots_vision)

[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE)

This is the vision ROS package of the Hamburg Bit-Bots.

The vision is able to detect balls, lines, the field itself, the field boundary, goal posts, teammates, enemies and other obstacles.

For further information and getting started, see the documentation of this package at our website: [docs.bit-bots.de](https://docs.bit-bots.de/package/bitbots_vision/latest/index.html)

An earlier version of this pipeline is presented in our paper [An Open Source Vision Pipeline Approach for RoboCup Humanoid Soccer](https://robocup.informatik.uni-hamburg.de/wp-content/uploads/2019/06/vision_paper.pdf).
When you use this pipeline or parts of it, please cite it.
```
@inproceedings{vision2019,
author={Fiedler, Niklas and Brandt, Hendrik and Gutsche, Jan and Vahl, Florian and Hagge, Jonas and Bestmann, Marc},
year={2019},
title={An Open Source Vision Pipeline Approach for RoboCup Humanoid Soccer},
booktitle={RoboCup 2019: Robot World Cup XXIII},
note = {Accepted},
organization={Springer}
}
```


![CI](https://github.com/threeML/threeML/workflows/CI/badge.svg?branch=master&event=push)
[![Conda Build and Publish](https://github.com/threeML/threeML/actions/workflows/conda_build.yml/badge.svg)](https://github.com/threeML/threeML/actions/workflows/conda_build.yml)
![Test Against XSPEC](https://github.com/threeML/threeML/workflows/Test%20Against%20XSPEC/badge.svg)
[![codecov](https://codecov.io/gh/threeML/threeML/branch/master/graph/badge.svg)](https://codecov.io/gh/threeML/threeML)
[![Documentation Status](https://readthedocs.org/projects/threeml/badge/?version=latest)](http://threeml.readthedocs.io/en/latest/?badge=latest)
[![License](https://img.shields.io/badge/License-BSD%203--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)
[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.5646954.svg)](https://doi.org/10.5281/zenodo.5646954)

![GitHub pull requests](https://img.shields.io/github/issues-pr/threeML/threeML)
![GitHub issues](https://img.shields.io/github/issues/threeML/threeML)

## PyPi

[![PyPI version fury.io](https://badge.fury.io/py/threeML.svg)](https://pypi.python.org/pypi/threeML/)
![PyPI - Downloads](https://img.shields.io/pypi/dw/threeml)
![PyPI - Python Version](https://img.shields.io/pypi/pyversions/threeml)
[![Install using pip](https://github.com/threeML/threeML/actions/workflows/pip_install.yml/badge.svg)](https://github.com/threeML/threeML/actions/workflows/pip_install.yml)
## Conda

![Conda](https://img.shields.io/conda/pn/threeml/threeml)
![Conda](https://img.shields.io/conda/dn/threeml/threeml)

 The Multi-Mission Maximum Likelihood framework (3ML)

A framework for multi-wavelength/multi-messenger analysis for astronomy/astrophysics.

Astrophysical sources are observed by different instruments at different
wavelengths with an unprecedented quality. Putting all these data together to
form a coherent view, however, is a very difficult task. Indeed, each instrument
and data type has its own ad-hoc software and handling procedure, which present
steep learning curves and do not talk to each other.

The Multi-Mission Maximum Likelihood framework (3ML) provides a common
high-level interface and model definition, which allows for an easy, coherent
and intuitive modeling of sources using all the available data, no matter their
origin. At the same time, thanks to its architecture based on plug-ins, 3ML uses
under the hood the official software of each instrument, the only one certified
and maintained by the collaboration which built the instrument itself. This
guarantees that 3ML is always using the best possible methodology to deal with
the data of each instrument.

Though **Maximum Likelihood** is in the name for historical reasons, 3ML is an
interface to several **Bayesian** inference algorithms such as MCMC and nested
sampling as well as likelihood optimization algorithms. Each approach to
analysis can be seamlessly switched between allowing users to try different
approaches quickly and without having to rewrite their model or data interfaces.

Like your [XPSEC](https://heasarc.gsfc.nasa.gov/xanadu/xspec/) models? You can
use them in 3ML as well as our growing selection of 1-,2- and 3-D models from
our fast and customizable modeling language
[astromodels](http://astromodels.readthedocs.org/en/latest/).

## Installation

Installing with pip or conda is easy. However, you want to include models from
[XSPEC](https://heasarc.gsfc.nasa.gov/xanadu/xspec/manual/Models.html), the
process can get tougher and we recommend the more detailed instructions:

```bash
pip install astromodels threeml
```

```bash
conda  install astromodels threeml -c threeml conda-forge
```
Please refer to the [Installation instructions](https://threeml.readthedocs.io/en/stable/notebooks/installation.html) for more details and trouble-shooting.

## Press
* [Software in development at Stanford advances the modeling of astronomical observations](https://news.stanford.edu/2017/12/07/software-advances-modeling-astronomical-observations/)

## Who is using 3ML?
Here is a highlight list of teams and their publications using 3ML.

* [Fermi-LAT](https://fermi.gsfc.nasa.gov) and [Fermi-GBM](https://grb.mpe.mpg.de)
  * [GeV–TeV Counterparts of SS 433/W50 from Fermi-LAT and HAWC Observations](https://iopscience.iop.org/article/10.3847/2041-8213/ab62b8)
  * [The Bright and the Slow](https://iopscience.iop.org/article/10.3847/1538-4357/aad6ea)
* [HAWC](https://www.hawc-observatory.org)
  * [Extended gamma-ray sources around pulsars constrain the origin of the positron flux at Earth](https://science.sciencemag.org/content/358/6365/911)
  * [Evidence of 200 TeV photons from HAWC J1825-134](https://arxiv.org/abs/2012.15275)
* [POLAR](https://www.astro.unige.ch/polar-2/?fbclid=IwAR0IxMxHtiXZyqc0A_kT1xKe9ASAk_VmfJpCEBr0HOhDG5eOHY7AE5TWHv8)
  * [The POLAR gamma-ray burst polarization catalog](https://ui.adsabs.harvard.edu/link_gateway/2020A&A...644A.124K/doi:10.1051/0004-6361/202037915)

A full list of publications using 3ML is [here](https://ui.adsabs.harvard.edu/abs/2015arXiv150708343V/citations).

## Citing
If you find this package useful in you analysis, or the code in your own custom data tools, please cite:

[Vianello et al. (2015)](https://arxiv.org/abs/1507.08343)

### Acknowledgements
3ML makes use of the Spanish Virtual Observatory's Filter Profile service (http://svo2.cab.inta-csic.es/svo/theory/fps3/index.php?mode=browse&gname=NIRT).

If you use these profiles in your research, please consider citing them by using the following suggested sentence in your paper:

"This research has made use of the SVO Filter Profile Service (http://svo2.cab.inta-csic.es/theory/fps/) supported from the Spanish MINECO through grant AyA2014-55216"

and citing the following publications:

The SVO Filter Profile Service. Rodrigo, C., Solano, E., Bayo, A. http://ivoa.net/documents/Notes/SVOFPS/index.html
The Filter Profile Service Access Protocol. Rodrigo, C., Solano, E. http://ivoa.net/documents/Notes/SVOFPSDAL/index.html

 ThreeML is supported by National Science Foundation (NSF)


PyMoDAQ
#######

.. image:: https://img.shields.io/pypi/v/pymodaq.svg
   :target: https://pypi.org/project/pymodaq/
   :alt: Latest Version

.. image:: https://readthedocs.org/projects/pymodaq/badge/?version=latest
   :target: https://pymodaq.readthedocs.io/en/stable/?badge=latest
   :alt: Documentation Status

.. image:: https://codecov.io/gh/PyMoDAQ/PyMoDAQ/branch/pymodaq-dev/graph/badge.svg?token=IQNJRCQDM2
    :target: https://codecov.io/gh/PyMoDAQ/PyMoDAQ

====== ========== ======= ======
Python Qt Backend OS      Passed
====== ========== ======= ======
3.8    Qt5        Linux   |38Qt5|
3.9    Qt5        Linux   |39Qt5|
3.10   Qt5        Linux   |310Qt5|
3.11   Qt5        Linux   |311Qt5|
3.8    Qt5        Windows |38Qt5win|
3.8    PySide2    Linux   |38pyside|
3.9    Qt6        Linux   |39Qt6|
====== ========== ======= ======

.. |38Qt5| image:: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp38pyqt5.yml/badge.svg?branch=pymodaq-dev
    :target: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp38pyqt5.yml

.. |39Qt5| image:: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp39pyqt5.yml/badge.svg?branch=pymodaq-dev
    :target: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp39pyqt5.yml

.. |310Qt5| image:: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp310pyqt5.yml/badge.svg?branch=pymodaq-dev
    :target: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp310pyqt5.yml

.. |311Qt5| image:: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp311pyqt5.yml/badge.svg?branch=pymodaq-dev
    :target: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp311pyqt5.yml

.. |38Qt5win| image:: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp38pyqt5_win.yml/badge.svg?branch=pymodaq-dev
    :target: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp38pyqt5_win.yml

.. |38pyside| image:: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp38pyside2.yml/badge.svg?branch=pymodaq-dev
    :target: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp38pyside2.yml

.. |39Qt6| image:: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp39pyqt6.yml/badge.svg?branch=pymodaq-dev
    :target: https://github.com/PyMoDAQ/PyMoDAQ/actions/workflows/Testp39pyqt6.yml

.. figure:: http://pymodaq.cnrs.fr/en/latest/_static/splash.png
   :alt: shortcut

PyMoDAQ, Modular Data Acquisition with Python, is a set of **python** modules used to interface any kind of experiments.
It simplifies the interaction with detector and actuator hardware to go straight to the data acquisition of interest.

It has two purposes:

* First, to provide a complete interface to perform automated measurements or logging data without having to write a user/interface for each
  new experiment, this is under the *Dashboard_module* environment and its extensions.
* Second, to provide various tools (modules) to easily build *custom apps*

It is organised a shown below:

.. figure:: http://pymodaq.cnrs.fr/en/latest/_images/pymodaq_diagram.png
   :alt: overview

   PyMoDAQ's Dashboard and its extensions: DAQ_Scan for automated acquisitions, DAQ_Logger for data logging and many other.

The main component is the **Dashboard** : This is a graphical component that will initialize actuators and detectors given
the need of your particular experiment. You configure the dashboard using an interface for quick launch of various
configurations (numbers and types of control modules).

The detectors and the actuators are represented and manipulated using two control modules:

* **DAQ_Move_module** : used to control/drive an actuator (stand alone and/or automated).
  Any number of these modules can be instantiated in the Dashboard
* **DAQ_Viewer_module** : used to control/drive a detector (stand alone and/or automated).

Any number of these modules can be instantiated in the Dashboard.

The Dashboard allows you to start dedicated extensions that will make use of the control modules:

* **DAQ_Logger_module** : This module lets you log data from one or many detectors defined in the dashboard. You can log data
  in a binary hierarchical hdf5 file or towards a sql database
* **DAQ_Scan_module** : This module lets you configure automated data acquisition from one or many detectors defined
  in the dashboard as a function or one or more actuators defined also in the dashboard.

and many others to simplify any application development.

Published under the MIT FREE SOFTWARE LICENSE

GitHub repo: https://github.com/PyMoDAQ

Documentation: http://pymodaq.cnrs.fr/


# grib2io

[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

[![Python 3.8](https://img.shields.io/badge/python-3.8-blue.svg)](https://www.python.org/downloads/release/python-380/)
[![Python 3.9](https://img.shields.io/badge/python-3.9-blue.svg)](https://www.python.org/downloads/release/python-390/)
[![Python 3.10](https://img.shields.io/badge/python-3.10-blue.svg)](https://www.python.org/downloads/release/python-3100/)
[![Python 3.11](https://img.shields.io/badge/python-3.11-blue.svg)](https://www.python.org/downloads/release/python-3110/)
[![Python 3.11](https://img.shields.io/badge/python-3.12-blue.svg)](https://www.python.org/downloads/release/python-3120/)

![Build Linux](https://github.com/NOAA-MDL/grib2io/actions/workflows/build_linux.yml/badge.svg)
![Build macOS](https://github.com/NOAA-MDL/grib2io/actions/workflows/build_macos.yml/badge.svg)

![PyPI](https://img.shields.io/pypi/v/grib2io?label=pypi%20package)
![PyPI - Downloads](https://img.shields.io/pypi/dm/grib2io)

[![Anaconda-Server Badge](https://anaconda.org/conda-forge/grib2io/badges/version.svg)](https://anaconda.org/conda-forge/grib2io)
[![Anaconda-Server Badge](https://anaconda.org/conda-forge/grib2io/badges/platforms.svg)](https://anaconda.org/conda-forge/grib2io)
[![Anaconda-Server Badge](https://anaconda.org/conda-forge/grib2io/badges/downloads.svg)](https://anaconda.org/conda-forge/grib2io)

[![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/NOAA-MDL/grib2io/HEAD)

## Introduction

grib2io provides a Python interface to the [NCEP GRIB2 C library](https://github.com/NOAA-EMC/NCEPLIBS-g2c) for reading and writing GRIB2 files.  The World Meteorological Organization ([WMO](https://www.wmo.int)) **GRI**dded **B**inary, Edition **2** ([GRIB2](https://www.wmo.int/pages/prog/www/WMOCodes/Guides/GRIB/GRIB2_062006.pdf)) is a table-driven, binary data format designed for transmitting large volumes of gridded meteorological and atmospheric data.

grib2io is the successor to [ncepgrib2](https://github.com/jswhit/ncepgrib2) which **_was_** a module within [pygrib](https://github.com/jswhit/pygrib).  As of pygrib v2.1, development of ncepgrib2 was dropped in favor of continued development of the pygrib module which provides an interface to the ECMWF [ecCodes](https://github.com/ecmwf/eccodes) library.  grib2io aims to provide a fast, efficient, and easy-to-use interface to the NCEP g2c library.  One way to accomplish this is to leverage the [NCEP GRIB2 Tables](https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/) which are included in grib2io.  With these [tables](./grib2io/tables) included and functions interact with them, grib2io provides a translation of GRIB2's integer coded metadata to human-readable language.

## Documentation
* [API documentation](https://noaa-mdl.github.io/grib2io/grib2io.html)
* [User Guide Jupyter Notebook](https://github.com/NOAA-MDL/grib2io/blob/master/grib2io-v2-demo.ipynb)

## Required Software
* [Python](https://python.org) 3.8+
* [NCEPLIBS-g2c](https://github.com/NOAA-EMC/NCEPLIBS-g2c) 1.7.0+
* setuptools 34.0+
* NumPy 1.22+
* pyproj 1.9.6+
* C compiler: GNU, Intel, and Apple Clang have been tested.

## Optional Software
* [grib2io-interp](https://github.com/NOAA-MDL/grib2io-interp) 1.0.0+ - Provides ability to perform spatial interpolation via the [NCEPLIBS-ip](https://github.com/NOAA-EMC/NCEPLIBS-ip)

## Required External Libraries

### NCEPLIBS-g2c
The [NCEPLIBS-g2c](https://github.com/NOAA-EMC/NCEPLIBS-g2c) library is required for grib2io.  You will have to build and install this yourself, but this is not difficult.  For macOS users, NCEPLIBS-g2c can be installed via [this Homebrew Tap](https://github.com/eengl/homebrew-nceplibs).  If you use the Anaconda ecosystem, then you can install via `conda install -c conda-forge nceplibs-g2c`.

## Install

Once again, this assumes that NCEPLIBS-g2c has been installed.  If NCEPLIBS-g2c has been installed into a "common" installation path, then it will be found, otherwise define environment variable `G2C_DIR` with the installation path.

* From [PyPI](https://pypi.python.org/pypi/grib2io) via pip:

```
pip install grib2io
```
* From [conda-forge](https://anaconda.org/conda-forge/grib2io) via conda:

```
conda install -c conda-forge grib2io
```

* From source:
```shell
pip install .
```

> [!NOTE]
> ### Building with static libraries
> The default behavior for building grib2io is to build against shared-object libraries.  However, in production environments, it is beneficial to build against static library files.  grib2io (v2.2.0+) allows for this type of build configuration.  To build against static library files, set the environment variable, `USE_STATIC_LIBS="True"` before your build/install command.  For example,
>
>```shell
>export USE_STATIC_LIBS="True"
>pip install .
>```

## Development

The intention of grib2io is to become the offical Python interface for the NCEP g2c library.  Therefore, the development evolution of grib2io will mainly focus on how best to serve that purpose and its primary users -- mainly meteorologists, physical scientists, and software developers supporting the missions within NOAA's National Weather Service (NWS) and National Centers for Environmental Prediction (NCEP), and other NOAA organizations.

## Disclaimer

This repository is a scientific product and is not official communication of the National Oceanic and Atmospheric Administration, or the United States Department of Commerce. All NOAA GitHub project code is provided on an 'as is' basis and the user assumes responsibility for its use. Any claims against the Department of Commerce or Department of Commerce bureaus stemming from the use of this GitHub project will be governed by all applicable Federal law. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply their endorsement, recommendation or favoring by the Department of Commerce. The Department of Commerce seal and logo, or the seal and logo of a DOC bureau, shall not be used in any manner to imply endorsement of any commercial product or activity by DOC or the United States Government.


CharmHelpers |badge|
--------------------

.. |badge| image:: https://github.com/juju/charm-helpers/actions/workflows/build.yml/badge.svg?branch=master
    :target: https://github.com/juju/charm-helpers/actions/workflows/build.yml

Overview
========

CharmHelpers provides an opinionated set of tools for building Juju charms.

The full documentation is available online at: https://charm-helpers.readthedocs.io/

Common Usage Examples
=====================

* interaction with charm-specific Juju unit agents via hook tools;
* processing of events and execution of decorated functions based on event names;
* handling of persistent storage between independent charm invocations;
* rendering of configuration file templates;
* modification of system configuration files;
* installation of packages;
* retrieval of machine-specific details;
* implementation of application-specific code reused in similar charms.

Why Python?
===========

* Python is an extremely popular, easy to learn, and powerful language which is also common in automation tools;
* An interpreted language helps with charm portability across different CPU architectures;
* Doesn't require debugging symbols (just use pdb in-place);
* An author or a user is able to make debugging changes without recompiling a charm.

Dev/Test
========

See the HACKING.md file for information about testing and development.

License
=======

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.


# SIMPLE

The vision of the SIMPLE project is to create a *collaborative* database of low-mass stars, brown dwarfs, and directly
imaged exoplanets: a simple archive of complex objects. The tables and fields currently included in the
database are described in the [Documentation](documentation/README.md)
and currently include names, coordinates, photometry and reference and data provenance information and is visualized
in the [schema](#simple-database-schema) below.
The archive includes kinematics, spectra, modeled and retrieved parameters.

There are several different methods to interact with the database, including:
- Python
- a website and API at https://simple-bd-archive.org/
- database browsers such as [DB Browser for SQLite](https://sqlitebrowser.org/)

To report missing data, data bugs or make feature requests, please use the [SIMPLE-db issue tracker](https://github.com/SIMPLE-AstroDB/SIMPLE-db/issues).

For day-to-day discussions, please join us in the #simple-db-dev channel in the [Astropy Slack workspace](https://astropy.slack.com/).
If you are not already in the Astropy Slack, [request an account](http://joinslack.astropy.org/).

To see more details about how this project got started and our initial discussions, check out the [archived running notes in the Wiki](https://github.com/SIMPLE-AstroDB/SIMPLE-db/wiki/Original-Notes).

## Getting Started

If you'd like to set up your own copy of the SIMPLE database, here's what we recommend:

1. Clone or download a copy of this repo locally onto your computer.

2. Set up an environment for the Python code and install dependencies.
We recommend using a conda environment to handle python dependencies. The following commands will use that file to create and activate an
   environment called `simple-db`. Run these commands at the terminal command prompt
    ```bash
    conda  create -n "simple-db" python=3.10
    conda activate simple-db
    pip install -r requirements.txt
    ```

3. In Python, connect a database file `SIMPLE.sqlite` as a Database object called `db` and recreate the database using the JSON files in the `data/` directory. Run these commands from within Python.
   ```python
   from astrodb_utils import load_astrodb
   from simple.schema import *
   from simple.schema import REFERENCE_TABLES

   db = load_astrodb("SIMPLE.sqlite", recreatedb=True,  reference_tables=REFERENCE_TABLES)
    ```

    This step generates a "SIMPLE.sqlite" file which can be opened, explored, and modified using a variety of tools.

4. Use `astrodbkit2` to [explore](https://astrodbkit2.readthedocs.io/en/latest/#exploring-the-schema), [query](https://astrodbkit2.readthedocs.io/en/latest/#querying-the-database), and/or [modify](https://astrodbkit2.readthedocs.io/en/latest/#modifying-data) the database.
For example:
    - Find all objects in the database with "0141" in the name
        ```python
        db.search_object('0141', fmt='astropy')
        ```

    - See all the data in the database for 2MASS J01415823-4633574

        ```python
        db.inventory('2MASS J01415823-4633574', pretty_print=True)
        ```

5. The database can also be modified using helper scripts found in [`simple/utils`](simple/utils) and in the [`astrodb_utils`](https://github.com/astrodbtoolkit/astrodb_utils) package. Previously used scripts to modify and/or update the database are stored in the [`scripts/`](scripts) directory and can be used for inspiration.

## Contributor Instructions
If you've made changes to the SIMPLE Archive that you would like to contribute to the public version, here's how to make a contribution.

1. If you've made changes to the database contents, write out the new/modified JSON files:
    ```python
    db.save_database(directory="data/")
    ```

2. (Optional, but highly recommended) Run and modify tests as necessary
    ```bash
    pytest
    ```

3. Open a pull request with the modified JSON files and optionally, your ingest script.

## SIMPLE Database Schema

The schema for the SIMPLE database is described
in the [Documentation](documentation) and can be found in [`simple/schema.py`](simple/schema.py).

A graphical representation of the SIMPLE schema:
<img src="https://github.com/SIMPLE-AstroDB/SIMPLE-db/blob/main/documentation/figures/schema2023.png?raw=true" width=75%>


# Kelvin

Kelvin - The Ultimate Code Examinator

```
kelvin
├── api
├── evaluator (pipeline for evaluating, linting submits)
│   ├── images (docker images for custom pipeline actions)
│   └── pipelines.py (integrated pipeline actions - Docker evaluation, ...)
├── kelvin (base configuration of the application)
├── survey (module for easy surveys defined in yaml)
└── web (web interface for the kelvin)
```

## Getting started

### Using docker

```shell-session
$ cp .env.example .env
$ docker-compose up
$ docker-compose exec web ./manage.py migrate
$ docker-compose exec web ./manage.py createsuperuser
$ ./evaluator/images/build.py  # Rerun if pipeline images change
$ ./sync_from_prod.sh  # Optional, you can populate the db yourself
```


---
[![Build Status](https://github.com/KernelTuner/kernel_tuner/actions/workflows/test-python-package.yml/badge.svg)](https://github.com/KernelTuner/kernel_tuner/actions/workflows/test-python-package.yml)
[![CodeCov Badge](https://codecov.io/gh/KernelTuner/kernel_tuner/branch/master/graph/badge.svg)](https://codecov.io/gh/KernelTuner/kernel_tuner)
[![PyPi Badge](https://img.shields.io/pypi/v/kernel_tuner.svg?colorB=blue)](https://pypi.python.org/pypi/kernel_tuner/)
[![Zenodo Badge](https://zenodo.org/badge/54894320.svg)](https://zenodo.org/badge/latestdoi/54894320)
[![SonarCloud Badge](https://sonarcloud.io/api/project_badges/measure?project=KernelTuner_kernel_tuner&metric=alert_status)](https://sonarcloud.io/dashboard?id=KernelTuner_kernel_tuner)
[![OpenSSF Badge](https://bestpractices.coreinfrastructure.org/projects/6573/badge)](https://bestpractices.coreinfrastructure.org/projects/6573)
[![FairSoftware Badge](https://img.shields.io/badge/fair--software.eu-%E2%97%8F%20%20%E2%97%8F%20%20%E2%97%8F%20%20%E2%97%8F%20%20%E2%97%8F-green)](https://fair-software.eu)
---

Create optimized GPU applications in any mainstream GPU
programming language (CUDA, HIP, OpenCL, OpenACC).

What Kernel Tuner does:

- Works as an external tool to benchmark and optimize GPU kernels in isolation
- Can be used directly on existing kernel code without extensive changes
- Can be used with applications in any host programming language
- Blazing fast search space construction
- More than 20 [optimization algorithms](https://kerneltuner.github.io/kernel_tuner/stable/optimization.html) to speedup tuning
- Energy measurements and optimizations [(power capping, clock frequency tuning)](https://arxiv.org/abs/2211.07260)
- ... and much more! For example, [caching](https://kerneltuner.github.io/kernel_tuner/stable/cache_files.html), [output verification](https://kerneltuner.github.io/kernel_tuner/stable/correctness.html), [tuning host and device code](https://kerneltuner.github.io/kernel_tuner/stable/hostcode.html), [user defined metrics](https://kerneltuner.github.io/kernel_tuner/stable/metrics.html), see [the full documentation](https://kerneltuner.github.io/kernel_tuner/stable/index.html).

## Installation

- First, make sure you have your [CUDA](https://kerneltuner.github.io/kernel_tuner/stable/install.html#cuda-and-pycuda), [OpenCL](https://kerneltuner.github.io/kernel_tuner/stable/install.html#opencl-and-pyopencl), or [HIP](https://kerneltuner.github.io/kernel_tuner/stable/install.html#hip-and-pyhipl) compiler installed
- Then type: `pip install kernel_tuner[cuda]`, `pip install kernel_tuner[opencl]`, or `pip install kernel_tuner[hip]`
- or why not all of them: `pip install kernel_tuner[cuda,opencl,hip]`

More information on installation, also for other languages, in the [installation guide](http://kerneltuner.github.io/kernel_tuner/stable/install.html).

## Example

```python
import numpy as np
from kernel_tuner import tune_kernel

kernel_string = """
__global__ void vector_add(float *c, float *a, float *b, int n) {
    int i = blockIdx.x * block_size_x + threadIdx.x;
    if (i<n) {
        c[i] = a[i] + b[i];
    }
}
"""

n = np.int32(10000000)

a = np.random.randn(n).astype(np.float32)
b = np.random.randn(n).astype(np.float32)
c = np.zeros_like(a)

args = [c, a, b, n]

tune_params = {"block_size_x": [32, 64, 128, 256, 512]}

tune_kernel("vector_add", kernel_string, n, args, tune_params)
```

More [examples here](https://kerneltuner.github.io/kernel_tuner/stable/examples.html).

## Resources

- [Full documentation](https://kerneltuner.github.io/kernel_tuner/stable/)
- Guides:
  - [Getting Started](https://kerneltuner.github.io/kernel_tuner/stable/quickstart.html)
  - [Convolution](https://kerneltuner.github.io/kernel_tuner/stable/convolution.html)
  - [Diffusion](https://kerneltuner.github.io/kernel_tuner/stable/diffusion.html)
  - [Matrix Multiplication](https://kerneltuner.github.io/kernel_tuner/stable/matrix_multiplication.html)
- Features & Use cases:
  - [Full list of examples](https://kerneltuner.github.io/kernel_tuner/stable/examples.html)
  - [Output verification](https://kerneltuner.github.io/kernel_tuner/stable/correctness.html)
  - [Test GPU code from Python](https://github.com/KernelTuner/kernel_tuner/blob/master/examples/cuda/test_vector_add.py)
  - [Tune code in both host and device code](https://kerneltuner.github.io/kernel_tuner/stable/hostcode.html)
  - [Optimization algorithms](https://kerneltuner.github.io/kernel_tuner/stable/optimization.html)
  - [Mixed-precision & Accuracy tuning](https://github.com/KernelTuner/kernel_tuner/blob/master/examples/cuda/accuracy.py)
  - [Custom metrics & tuning objectives](https://kerneltuner.github.io/kernel_tuner/stable/metrics.html)
- **Kernel Tuner Tutorial** slides [[PDF]](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/slides/2022_SURF/SURF22-Kernel-Tuner-Tutorial.pdf), hands-on:
  - Vector add example [[.ipynb](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/hands-on/cuda/00_Kernel_Tuner_Introduction.ipynb)] [![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/KernelTuner/kernel_tuner_tutorial/blob/master/hands-on/cuda/00_Kernel_Tuner_Introduction.ipynb)
  - Tuning thread block dimensions [[.ipynb](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/hands-on/cuda/01_Kernel_Tuner_Getting_Started.ipynb)] [![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/KernelTuner/kernel_tuner_tutorial/blob/master/hands-on/cuda/01_Kernel_Tuner_Getting_Started.ipynb)
  - Search space restrictions & output verification [[.ipynb](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/hands-on/cuda/02_Kernel_Tuner_Intermediate.ipynb)] [![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/KernelTuner/kernel_tuner_tutorial/blob/master/hands-on/cuda/02_Kernel_Tuner_Intermediate.ipynb)
  - Visualization & search space optimization [[.ipynb](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/hands-on/cuda/03_Kernel_Tuner_Advanced.ipynb)] [![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/KernelTuner/kernel_tuner_tutorial/blob/master/hands-on/cuda/03_Kernel_Tuner_Advanced.ipynb)
- **Energy Efficient GPU Computing** tutorial slides [[PDF]](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/slides/2023_Supercomputing/SC23.pdf), hands-on:
  - Kernel Tuner for GPU energy measurements [[.ipynb](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/energy/00_Kernel_Tuner_Introduction.ipynb)] [![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/KernelTuner/kernel_tuner_tutorial/blob/master/energy/00_Kernel_Tuner_Introduction.ipynb)
  - Code optimizations for energy [[.ipynb](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/energy/01_Code_Optimizations_for_Energy.ipynb)] [![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/KernelTuner/kernel_tuner_tutorial/blob/master/energy/01_Code_Optimizations_for_Energy.ipynb)
  - Mixed precision and accuracy tuning [[.ipynb](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/energy/02_Mixed_precision_programming.ipynb)] [![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/KernelTuner/kernel_tuner_tutorial/blob/master/energy/02_Mixed_precision_programming.ipynb)
  - Optimzing for time vs for energy [[.ipynb](https://github.com/KernelTuner/kernel_tuner_tutorial/blob/master/energy/03_energy_efficient_computing.ipynb)] [![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/KernelTuner/kernel_tuner_tutorial/blob/master/energy/03_energy_efficient_computing.ipynb)

## Kernel Tuner ecosystem

C++ magic to integrate auto-tuned kernels into C++ applications

C++ data types for mixed-precision CUDA kernel programming

Monitor, analyze, and visualize auto-tuning runs

## Communication & Contribution

- GitHub [Issues](https://github.com/KernelTuner/kernel_tuner/issues): Bug reports, install issues, feature requests, work in progress
- GitHub [Discussion group](https://github.com/orgs/KernelTuner/discussions): General questions, Q&A, thoughts

Contributions are welcome! For feature requests, bug reports, or usage problems, please feel free to create an issue.
For more extensive contributions, check the [contribution guide](http://kerneltuner.github.io/kernel_tuner/stable/contributing.html).

## Citation

If you use Kernel Tuner in research or research software, please cite the most relevant among the [publications on Kernel
Tuner](https://kerneltuner.github.io/kernel_tuner/stable/#citation). To refer to the project as a whole, please cite:

```latex
@article{kerneltuner,
  author  = {Ben van Werkhoven},
  title   = {Kernel Tuner: A search-optimizing GPU code auto-tuner},
  journal = {Future Generation Computer Systems},
  year = {2019},
  volume  = {90},
  pages = {347-358},
  url = {https://www.sciencedirect.com/science/article/pii/S0167739X18313359},
  doi = {https://doi.org/10.1016/j.future.2018.08.004}
}
```


# EveryElection
[![Build Status](https://circleci.com/gh/DemocracyClub/EveryElection.svg?style=svg)](https://circleci.com/gh/DemocracyClub/EveryElection) [![Coverage Status](https://coveralls.io/repos/github/DemocracyClub/EveryElection/badge.svg?branch=master)](https://coveralls.io/github/DemocracyClub/EveryElection?branch=master) ![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)

For recording every election in the UK

## Domain Model

### Elections

The elections table stores a list of election objects, each with a semantic ID.

Election IDs sometimes have a parent, and are sometimes a "group ID".

There are two types of group ID:

1. `[type].[date]`, for example `local.2017-05-04` will be the group for all local elections happening on 2017-05-04.
2. `[type].[organiation].[date]`, for example `local.norfolk.2017-05-04` is the Norfolk County Council elections.

Finally an ID is made _per ballot paper_ using `[type].[organiation].[organisation division].[date]` for example `local.norfolk.diss.2017-05-04`.

[See the reference for more information](https://democracyclub.org.uk/projects/election-ids/reference/).

![Graph](docs/graph.png)


# Tiled

Tiled is a **data access** service for data-aware portals and data science tools.
Tiled has a Python client and integrates naturally with Python data science
libraries, but nothing about the service is Python-specific; it also works from
a web browser or any Internet-connected program.

Tiled’s service can sit atop databases, filesystems, and/or remote
services to enable **search** and **structured, chunkwise access to data** in an
extensible variety of appropriate formats, providing data in a consistent
structure regardless of the format the data happens to be stored in at rest. The
natively-supported formats span slow but widespread interchange formats (e.g.
CSV, JSON) and fast, efficient ones (e.g. C buffers, Apache Arrow and Parquet).
Tiled enables slicing and sub-selection to read and transfer only the data of
interest, and it enables parallelized download of many chunks at once. Users can
access data with very light software dependencies and fast partial downloads.

Tiled puts an emphasis on **structures** rather than formats, including:

* N-dimensional strided arrays (i.e. numpy-like arrays)
* Sparse arrays
* Tabular data (e.g. pandas-like "dataframes")
* Nested, variable-sized data (as implemented by [AwkwardArray](https://awkward-array.org/))
* Hierarchical structures thereof (e.g. xarrays, HDF5-compatible structures like NeXus)

Tiled implements extensible **access control enforcement** based on web security
standards, similar to JuptyerHub. Like Jupyter, Tiled can be used by a single
user or deployed as a shared public or private resource. Tiled can be configured
to use third party services for login, such as Google, ORCID. or any OIDC
or SAML authentication providers.

Tiled facilitates **client-side caching** in a standard web browser or in
Tiled's Python client, making efficient use of bandwidth. It uses
**service-side caching** of "hot" datasets and resources to expedite both
repeat requests (e.g. when several users are requesting the same chunks of
data) and distinct requests for different parts of the same dataset (e.g. when
the user is requesting various slices or columns from a dataset).

| Distribution   | Where to get it                                              |
| -------------- | ------------------------------------------------------------ |
| PyPI           | `pip install tiled`                                          |
| Conda          | `conda install -c conda-forge tiled-client tiled-server`     |
| Source code    | [github.com/bluesky/tiled](https://github.com/bluesky/tiled) |
| Documentation  | [blueskyproject.io/tiled](https://blueskyproject.io/tiled)   |

## Example

In this example, we'll serve of a collection of data that is generated in
memory.  Alternatively, it could be read on demand from a directory of files,
network resource, database, or some combination of these.

```
tiled serve demo
# equivalent to:
# tiled serve pyobject --public tiled.examples.generated:tree
```

And then access the data efficiently via the Python client, a web browser, or
any HTTP client.

```python
>>> from tiled.client import from_uri

>>> client = from_uri("http://localhost:8000")

>>> client
<Container {'short_table', 'long_table', 'structured_data', ...} ~10 entries>

>>> list(client)
'big_image',
 'small_image',
 'tiny_image',
 'tiny_cube',
 'tiny_hypercube',
 'low_entropy',
 'high_entropy',
 'short_table',
 'long_table',
 'labeled_data',
 'structured_data']

>>> client['medium_image']
<ArrayClient>

>>> client['medium_image'][:]
array([[0.49675483, 0.37832119, 0.59431287, ..., 0.16990737, 0.5396537 ,
        0.61913812],
       [0.97062498, 0.93776709, 0.81797714, ..., 0.96508877, 0.25208564,
        0.72982507],
       [0.87173234, 0.83127946, 0.91758202, ..., 0.50487542, 0.03052536,
        0.9625512 ],
       ...,
       [0.01884645, 0.33107071, 0.60018523, ..., 0.02268164, 0.46955907,
        0.37842628],
       [0.03405101, 0.77886243, 0.14856727, ..., 0.02484926, 0.03850398,
        0.39086524],
       [0.16567224, 0.1347261 , 0.48809697, ..., 0.55021249, 0.42324589,
        0.31440635]])

>>> client['long_table']
<DataFrameClient ['A', 'B', 'C']>

>>> client['long_table'].read()
              A         B         C
index
0      0.246920  0.493840  0.740759
1      0.326005  0.652009  0.978014
2      0.715418  1.430837  2.146255
3      0.425147  0.850294  1.275441
4      0.781036  1.562073  2.343109
...         ...       ...       ...
99995  0.515248  1.030495  1.545743
99996  0.639188  1.278376  1.917564
99997  0.269851  0.539702  0.809553
99998  0.566848  1.133695  1.700543
99999  0.101446  0.202892  0.304338

[100000 rows x 3 columns]

>>> client['long_table'].read(['A', 'B'])
              A         B
index
0      0.246920  0.493840
1      0.326005  0.652009
2      0.715418  1.430837
3      0.425147  0.850294
4      0.781036  1.562073
...         ...       ...
99995  0.515248  1.030495
99996  0.639188  1.278376
99997  0.269851  0.539702
99998  0.566848  1.133695
99999  0.101446  0.202892
```

Using an Internet browser or a command-line HTTP client like
[curl](https://curl.se/) or [httpie](https://httpie.io/) you can download the
data in whole or in efficiently-chunked parts in the format of your choice:

```
# Download tabular data as CSV
http://localhost:8000/api/v1/table/full/long_table?format=csv

# or XLSX (Excel)
http://localhost:8000/api/v1/table/full/long_table?format=xslx

# and subselect columns.
http://localhost:8000/api/v1/table/full/long_table?format=xslx&field=A&field=B

# View or download (2D) array data as PNG
http://localhost:8000/api/v1/array/full/medium_image?format=png

# and slice regions of interest.
http://localhost:8000/api/v1/array/full/medium_image?format=png&slice=:50,100:200
```

Web-based data access usually involves downloading complete files, in the
manner of [Globus](https://www.globus.org/); or using modern chunk-based
storage formats, such as [TileDB](https://tiledb.com/) and
[Zarr](https://zarr.readthedocs.io/en/stable/) in local or cloud storage; or
using custom solutions tailored to a particular large dataset. Waiting for an
entire file to download when only the first frame of an image stack or a
certain column of a table are of interest is wasteful and can be prohibitive
for large longitudinal analyses. Yet, it is not always practical to transcode
the data into a chunk-friendly format or build a custom tile-based-access
solution. (Though if you can do either of those things, you should consider
them instead!)


[![Build Status](https://github.com/spacetelescope/pysiaf/workflows/pysiaf%20CI/badge.svg)](https://github.com/spacetelescope/pysiaf/actions)
[![Documentation Status](https://readthedocs.org/projects/pysiaf/badge/?version=latest)](https://pysiaf.readthedocs.io/en/latest/?badge=latest)
[![PyPI version](https://badge.fury.io/py/pysiaf.svg)](https://badge.fury.io/py/pysiaf)
[![PyPI - License](https://img.shields.io/pypi/l/Django.svg)](https://github.com/spacetelescope/pysiaf/blob/master/LICENSE.md)
[![DOI](https://zenodo.org/badge/122391513.svg)](https://zenodo.org/badge/latestdoi/122391513)

# pysiaf
Handling of Science Instrument Aperture Files (SIAF) for space telescopes. SIAF files contain detailed geometric focal plane descriptions and relationships for the science instruments. They are maintained in the JWST/HST PRD (Project Reference Database).
pysiaf is a python package to access, interpret, maintain, and generate SIAF, in particular for JWST. Tools for applying the frame transformations, plotting, comparison, and validation are provided.

### Functionalities
* Captures current PRD content, i.e. pysiaf includes a copy of the SIAF XML files. These are maintained to be synchronized with the PRD.
* Transformations between the SIAF frames (Detector, Science, Ideal, Telelescope/V) are pre-loaded and easily accessible.
* Tools for plotting, validation, and comparison of SIAF apertures and files.
* Support for implementing transformations between celestial (RA, Dec) and telescope/V (V2, V3) coordinate systems is provided.
* Input/output: reading SIAF XML, writing XML/Excel/csv etc.
* Captures SI source data and code to generate the SIAF apertures
* Standard python package with installation script, unit tests, documentation.
* Supports working with HST SIAF (read-only).

### Example usage
Check which PRD version is in use:
    `print(pysiaf.JWST_PRD_VERSION)`

Frame transformations (`det`, `sci`, `idl`, `tel` are supported frames):
````
    import pysiaf
    instrument = 'NIRISS'

    # read SIAFXML
    siaf = pysiaf.Siaf(instrument)

    # select single aperture by name
    nis_cen = siaf['NIS_CEN']

    # access SIAF parameters
    print('{} V2Ref = {}'.format(nis_cen.AperName, nis_cen.V2Ref))
    print('{} V3Ref = {}'.format(nis_cen.AperName, nis_cen.V3Ref))

    for attribute in ['InstrName', 'AperShape']:
        print('{} {} = {}'.format(nis_cen.AperName, attribute, getattr(nis_cen, attribute)))

    # coordinates in Science frame
    sci_x = np.array([0, 2047, 2047, 0])
    sci_y = np.array([0, 0, 2047, 2047])

    # transform from Science frame to Ideal frame
    idl_x, idl_y = nis_cen.sci_to_idl(sci_x, sci_y)
````
Plotting (only a small subset of options is illustrated):

````
    import matplotlib.pyplot as plt

    plt.figure(figsize=(4, 4), facecolor='w', edgecolor='k'); plt.clf()

    # plot single aperture
    nis_cen.plot()

    # plot all apertures in SIAF
    for aperture_name, aperture in siaf.apertures.items():
        aperture.plot()
    plt.show()
````
````
    # plot 'master' apertures
    from pysiaf.siaf import plot_master_apertures
    plt.figure(figsize=(8, 8), facecolor='w', edgecolor='k'); plt.clf()
    plot_master_apertures(mark_ref=True)
    plt.show()
````
````
    # plot HST apertures
    siaf = pysiaf.Siaf('HST')
    aperture_names = ['FGS1', 'FGS2', 'FGS3', 'IUVIS1FIX', 'IUVIS2FIX', 'JWFC1FIX', 'JWFC2FIX']

    plt.figure(figsize=(4, 4), facecolor='w', edgecolor='k')
    for aperture_name in aperture_names:
        siaf[aperture_name].plot(color='r', fill_color='darksalmon', mark_ref=True)
    ax = plt.gca()
    ax.set_aspect('equal')
    ax.invert_yaxis()
    plt.show()

````

### Documentation
The primary reference for a description of JWST SIAF is Cox & Lallo, 2017, JWST-STScI-001550: *Description and Use of the JWST Science Instrument Aperture File*, available at https://jwst.stsci.edu/documentation/technical-documents.

pysiaf is documented at https://pysiaf.readthedocs.io/

### Citation
If you find this package useful, please consider citing the Zenodo record using the DOI badge above.
Please find additional citation instructions in [CITATION](CITATION).

### Disclaimer

All parameter values in pysiaf are subject to change. JWST values are preliminary until the JWST observatory commissioning has concluded.

Distortion and other transformations in pysiaf are of sufficient accuracy for operations, but do not necessarily have science-grade quality. For instance, generally only one filter solution is carried per aperture.
For science-grade transformations, please consult the science pipelines and their reference files (see  https://jwst-docs.stsci.edu/jwst-data-reduction-pipeline)

For science observation planning, the focal plane geometry implemented in the latest APT (http://www.stsci.edu/hst/proposing/apt) takes precedence.
The STScI Telescopes Branch provides full support of pysiaf for S&OC operational systems only.

### Contributing
Please open a new issue or new pull request for bugs, feedback, or new features you would like to see. If there is an issue you would like to work on, please leave a comment and we will be happy to assist. New contributions and contributors are very welcome!
 Do you have feedback and feature requests? Is there something missing you would like to see? Please open an issue or send an email to the maintainers. This package follows the Space Telescope [Code of Conduct](CODE_OF_CONDUCT.md) strives to provide a welcoming community to all of our users and contributors.

The following describes the typical work flow for contributing to the pysiaf project (adapted from JWQL):
0. Do not commit any sensitive information (e.g. STScI-internal path structures, machine names, user names, passwords, etc.) to this public repository. Git history cannot be erased.
1. Create a fork off of the `spacetelescope` `pysiaf` repository on your personal github space.
2. Make a local clone of your fork.
3. Ensure your personal fork is pointing `upstream` to https://github.com/spacetelescope/pysiaf
4. Open an issue on `spacetelescope` `pysiaf` that describes the need for and nature of the changes you plan to make. This is not necessary for minor changes and fixes.
5. Create a branch on that personal fork.
6. Make your software changes.
7. Push that branch to your personal GitHub repository, i.e. to `origin`.
8. On the `spacetelescope` `pysiaf` repository, create a pull request that merges the branch into `spacetelescope:master`.
9. Assign a reviewer from the team for the pull request.
10. Iterate with the reviewer over any needed changes until the reviewer accepts and merges your branch.
11. Delete your local copy of your branch.

### Installation
This package is supported in python 3.8 and 3.9

`pip install pysiaf`

Clone the repository:
`git clone https://github.com/spacetelescope/pysiaf`
Install pysiaf:
`cd pysiaf`
`pip install .`

Install in Develop Mode
`pip install -e .`

### Known installation issues

If you get an error upon
`import pysiaf`
that traces back to
`import lxml.etree as ET`
and states
    `ImportError [...] Library not loaded: libxml2.2.dylib
    Reason: Incompatible library version: etree.[...] requires version 12.0.0 or later,
    but libxml2.2.dylib provides version 10.0.0`,
this can probably be fixed by downgrading the version of lxml, e.g.
    `pip uninstall lxml`
    `pip install lxml==3.6.4`

pyqt5 installation issues:
    If using MacOS Mojave, it causes matplotlib to fail without pyqt5. Please take appropriate action to make sure pyqt5 is installed for


# SDG Translations

A project to compile and translate text related to the United Nation's
  Sustainable Development Goals, and then provide those translations as JSON.

These translations are intended primarily for the open-source national reporting platform [Open SDG](https://github.com/open-sdg/open-sdg), but can certainly be used for other NRPs or SDG-related projects.

More information [here](https://open-sdg.org/sdg-translations/).