2 Commits
v2.2a3 ... v2.2

Author SHA1 Message Date
Jan Kundrát
ee92011b21 docs: fix description of gnpy-path-request
Since about f9e0d18 and 94a8f35, we've changed the way how the equipment
config (and also the network topology) is passed around. Update the
README to reflect this.

Change-Id: I338b790fd4d54914c49e5e0aac3f44f2bc9d00ee
2020-06-18 12:14:24 +02:00
Jan Kundrát
9861a22ef9 docs: do not talk about branches anymore
We talked about this during the coders call on 2020-06-02. When this
project started, it was decided to keep the `master` branch essentially
frozen between releases, and concentrate development into the `develop`
branch. Since that time, we've got a decent CI coverage and end-to-end
tests which should guard us against regressions and inaccurate
simulation results. It also seems that our users have a preference to
use tagged releases anyway, so we can get by by deprecating the
`develop` branch.

As agreed during the conf call, from this release on we'll be merging
approved changes directly into the `master` branch, and the `develop`
branch will be retired. We have measures in place that ought to limit
the risk of regression within `master` to an acceptable level.

Change-Id: I0048ba8e36810237667e6930380a9c8570090a26
2020-06-18 11:48:01 +02:00

View File

@@ -31,13 +31,6 @@ There are `weekly calls <https://telecominfraproject.workplace.com/events/702894
Newcomers, users and telecom operators are especially welcome there.
We encourage all interested people outside the TIP to `join the project <https://telecominfraproject.com/apply-for-membership/>`__.
Branches and Tagged Releases
----------------------------
- all releases are `available via GitHub <https://github.com/Telecominfraproject/oopt-gnpy/releases>`_
- the `master <https://github.com/Telecominfraproject/oopt-gnpy/tree/master>`_ branch contains stable, `validated code <https://github.com/Telecominfraproject/oopt-gnpy/wiki/Testing-for-Quality>`_. It is updated from develop on a release schedule determined by the OOPT-PSE Working Group.
- the `develop <https://github.com/Telecominfraproject/oopt-gnpy/tree/develop>`_ branch contains the latest code under active development, which may not be fully validated and tested.
How to Install
--------------
@@ -118,27 +111,16 @@ An experimental support for Raman amplification is available:
Configuration of Raman pumps (their frequencies, power and pumping direction) is done via the `RamanFiber element in the network topology <gnpy/example-data/raman_edfa_example_network.json>`_.
General numeric parameters for simulaiton control are provided in the `gnpy/example-data/sim_params.json <gnpy/example-data/sim_params.json>`_.
Use ``gnpy-path-request`` to run multiple optimizations as follows:
Use ``gnpy-path-request`` to request several paths at once:
.. code-block:: shell-session
$ gnpy-path-request -h
Usage: gnpy-path-requests [-h] [-v] [-o OUTPUT] [network_filename] [service_filename] [eqpt_filename]
$ cd $(gnpy-example-data)
$ gnpy-path-request -o output_file.json \
meshTopologyExampleV2.xls meshTopologyExampleV2_services.json
The ``network_filename`` and ``service_filename`` can be an XLS or JSON file. The ``eqpt_filename`` must be a JSON file.
To see an example of it, run:
.. code-block:: shell-session
$ cd $(gnpy-example-data)
$ gnpy-path-request meshTopologyExampleV2.xls meshTopologyExampleV2_services.json eqpt_config.json -o output_file.json
This program requires a list of connections to be estimated and the equipment
library. The program computes performances for the list of services (accepts
`JSON <docs/json.rst>`__ or `Excel <docs/excel.rst>`__ format) using the same spectrum propagation modules as
``gnpy-transmission-example``.
The output format is based on `draft-ietf-teas-yang-path-computation-01 <https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-01>`_ with custom extensions (e.g., for transponder modes).
This program operates on a network topology (`JSON <docs/json.rst>`__ or `Excel <docs/excel.rst>`__ format), processing the list of service requests (JSON or XLS again).
The service requests and reply formats are based on the `draft-ietf-teas-yang-path-computation-01 <https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-01>`__ with custom extensions (e.g., for transponder modes).
An example of the JSON input is provided in file `service-template.json`, while results are shown in `path_result_template.json`.
Important note: ``gnpy-path-request`` is not a network dimensionning tool: each service does not reserve spectrum, or occupy ressources such as transponders. It only computes path feasibility assuming the spectrum (between defined frequencies) is loaded with "nb of channels" spaced by "spacing" values as specified in the system parameters input in the service file, each cannel having the same characteristics in terms of baudrate, format,... as the service transponder. The transceiver element acts as a "logical starting/stopping point" for the spectral information propagation. At that point it is not meant to represent the capacity of add drop ports.