Simphony: A Simulator for Photonic circuits
Project description
Simphony
A Simulator for Photonic circuits
Authors: Sequoia Ploeg, Hyrum Gunther
Developed by CamachoLab at Brigham Young University.
This package is still under development. It initially began as an extension to SiEPIC-Tools, but was ported here once it became large enough to be considered its own stand-alone project. There is a repository, SiEPIC-Simphony, that integrates Simphony with SiEPIC-Tools and KLayout in order to perform photonic circuit simulations using a layout-driven design methodology.
Simphony can be installed via pip using Python 3:
pip install simphony
Please note that Python 2 is not supported. With the looming deprecation of Python 2 (January 1, 2020), no future compatability is planned.
Documentation
Documentation is built on Sphinx. They can be built using the default files by navigation to the docs directory and running:
make html
The docs are written in reST. There is a nice syntax guide with guidelines that we follow in the documentation here. The majority of the documentation is generated from python docstrings written using NumPy documentation format.
The changelogs can be found in docs/changelog/. There is a changelog file for each released version of the software.
Tests
Simphony uses the pytest testing framework. To run all tests, simply execute
pytest
from the toplevel directory.
Developers
This package is available on PyPI and updates are regularly pushed as "minor"
or "micro" versions. Before submitting any pull requests, however, you should
ensure that a pip installation of your updated package installs and functions
properly. To test this, try installing your package locally by removing all
installed versions of Simphony (by running pip uninstall simphony
repeatedly until no installations remain) and running the following commands
(from Simphony's toplevel directory):
python3 setup.py sdist bdist_wheel
pip install dist/simphony-[VERSION].tar.gz
Contributing
All contributions and new features or bug fixes should be worked on in forks or branches of the repository. Issues should be opened, and pull requests should reference and close those issues. This is good versioning and documentation practice.
Maintainers
Remember that all changes are to be integrated through pull requests. Development work should be done in branches or forks of the repository. Once implemented (and tested on their own), these pull requests should be merged into the "master" branch for full testing with the whole program. Each time the package is released on PyPI, the package should have a pull request opened to its corresponding release branch (release-MAJOR.MINOR.x). The hierarchy is then as follows:
- release.* (stable branch)
- master (integration and final testing)
- feature-name (feature development and bug fixes)
Even if you are the lone developer, we follow the methodology here.
Be sure to update the version number manually before pushing each new version to PyPI. Also be sure to amend the changelog. Versions can be pushed to PyPI using the command:
python3 -m twine upload dist/*
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.