For this commit only the first element from the {N, M} list is read
and assigned.
This is better than not reading this value at all.
the commit also updates test_files and test data files with correct
values for the effective_freq_slot attribute
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I1e60fe833ca1092b40de27c8cbfb13083810414e
if the user has specified a nb of slot and has not specified a mode
it may happen that the nb of slot is finally not large enough to support
the requested traffic: then blocking reason is 'NOT_ENOUGH_RESERVED_SPECTRUM'
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I8d4c4df5fa97e37aefac8d9ee0d93c901505fa55
When a path is blocked for 'NO_FEASIBLE_MODE' reason, and bidir is true,
the request attributes are filled with the last explored mode values
(baudrate notably), and the reversed path is propagated with this last
explored mode specs. if this reversed path is also not feasible the blocking
reason was overwritten with a 'MODE_NOT_FESIBLE' reasonn, because
baudrate is filled in the request attribute.
This change ensure that the blocking reason (if it exists) is not overwritten.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: If80a37d77e2b967a327562c733a44e7f78f1c544
This adds a separate OpenROADM eqpt config file corresponding to the
latest version of the MSA:
https://0201.nccdn.net/4_2/000/000/071/260/20210629_open-roadm_msa_specification_ver5.0.xlsx
The existing config file corresponding to the old version is kept for
backward compatibility. The new version introduces the following
changes:
* New definition of incremental OSNR for a ROADM based on polynomial
(see also previous commit).
* ROADM add path OSNR changed from 30 dB to 33 dB
* New transceiver mode: 200 Gbit/s, 31.57 Gbaud, DP-16QAM
* Tx OSNR for transceiver mode 100 Gbit/s, 31.57 Gbaud, DP-QPSK changed
from 35 dB to 36 dB
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: Ieb7d33bd448ed9d0cb8320ed190019c9aa94c9ef
The latest version 5.0 of the OpenROADM MSA changes the definition
of the incremental OSNR mask of a ROADM to a polynomial:
https://0201.nccdn.net/4_2/000/000/071/260/20210629_open-roadm_msa_specification_ver5.0.xlsx
A new preamp type variety corresponding to the updated specification is
added to the default eqpt config file while also keeping the type
variety corresponding to the old specification for backward
compatibility.
The updated specification includes both typical and worst case values.
These are added as separate type varieties to let the user choose which
values to use. Note that the specification with typical values is
identical to the existing OpenROADM ILA standard type variety but a new
type variety is still added for clarity.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I2de5e9db69f9ae3b218e30a3b246bd9b83cef458
Auto-design tries to split fibers longer than the max_length parameter
specified in the eqpt config file. When calculating new fiber lengths,
it uses a target_length parameter, which is currently hardcoded to 90
km. If the user specifies a max_length that is shorter than the
target_length and the topology includes any fiber that is longer than
the max_length but shorter than the hardcoded target_length, the
calculation crashes with a ZeroDivisionError. This patch limits the
target_length parameter so that it can't be longer than max_length.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: Id0851fcf79ab0b1a05832e22ee7e9cf63691446c
Previous set of tests did not correctly check the combinations of
disjunction and route constraint. This new set tests specific cases
with several demands in one synchronization vector with and without
route constraint, and the case where both disjunction constraint and
route can not be met (STRICT and LOOSE cases)
+ minor refactor on test_disjunction
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Id5a5902e6945185922ce5743ac97d15dbc777af2
When delta_p or target_pch_out_db is None (resulting e.g. from
operating in gain mode) the current logic replaces a whole printed
line with 'None' which does not look very nice in the script outputs.
With this patch, the parameter information is kept in the printout
like this:
Delta_P (dB): None
target pch (dBm): None
Change-Id: Ie52ce7353a708a174cf9d769918a6136eefbf444
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Fixes: 225cafa8 (Floating point formatting of elements' operational parameters)
I've been getting reports that the test suite is broken on Windows (the
usual set of problems such as CRLF line endings and backslashes in path
names), so let's make sure we have a way of reproducing this.
Unfortunately, we don't have a Windows image in Zuul, so this will be a
post-merge CI I'm afraid :(.
Change-Id: Ibd539764d6e40693b95a9b231324bd0216e4a207
Let's use the text mode everywhere because Unicode codepoints is what
matters. The only catch on Windows turned out to be the default file IO
encoding; forcing UTF-8 there fixes all issues in the CI (and it makes
sense because that file was written out in a UTF-8 locale, and the
system which runs the test suite might be set to something else.
This was a rather interesting debugging experience; passing logs over
the web and handling "strange" characters as utf-8 did not help.
Change-Id: I1fdbe3a115458558b27a81f9eab8e58c9605bae7
Bug: https://github.com/Telecominfraproject/oopt-gnpy/issues/358
We have a test which compares the raw output of GNPy against a fixed
expected output. That comparison of course chokes when forward slashes
and backslashes are used, which breaks the test suite on Windows. Let's
try to solve this by always using forward slashes if possible. The way
to go is via pathlib's as_posix(), but that one can possibly return an
absolute path -- which cannot work in a test suite, obviously. So one
can workaround that via calling a Path.relative_to(), but that one
chokes on paths which require at least one "path up" component (`..`).
I posted a patch which use brute force here, but Jonas is right, better
just don't print that output in the test suite in the first place.
Change-Id: I762ddb58a2042120c7b20414152a06a3ed72048d
Bug: https://github.com/Telecominfraproject/oopt-gnpy/issues/358
As mentioned in GitHub issue #409, an out_voa value for an EDFA
explicitly set in the topology file is not taken into account by
auto-design when calculating target power and gain. I think it is
more logical if the target power resulting from the optimization
algorithm represents the desired power into the fiber. This is also
more consistent with the behaviour for an automatically set out_voa
value when out_voa_auto is set to true.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I7e58b61d0bf30728c39d36404619dbe370c12f2b
When `pytest` is run with `-vv`, it shows a diff of multiline strings
and dict just fine. The only drawback is that there's the raw string
with newlines shown as "\n", however, *then* the nice diff pretty
printing kicks in, and the result is:
E Common items:
E {'response-id': '5'}
E Differing items:
E {'path-properties': {'path-metric': [{'accumulative-value': 21.68, 'metric-type': 'SNR-bandwidth'}, {'accumulative-val...EDFA', 'link-tp-id': 'east edfa in Rennes_STA to Stbrieuc', 'node-id': 'east edfa in Rennes_STA to Stbrieuc'}}}, ...]}} != {'path-properties': {'path-metric': [{'accumulative-value': 21.68, 'metric-type': 'SNR-bandwidth'}, {'accumulative-val...EDFA', 'link-tp-id': 'east edfa in Rennes_STA to Stbrieuc', 'node-id': 'east edfa in Rennes_STA to Stbrieuc'}}}, ...]}}
E Full diff:
E {
E 'path-properties': {'path-metric': [{'accumulative-value': 21.68,
E 'metric-type': 'SNR-bandwidth'},
E {'accumulative-value': 28.77,
E 'metric-type': 'SNR-0.1nm'},
E {'accumulative-value': 23.7,
E 'metric-type': 'OSNR-bandwidth'},
E {'accumulative-value': 30.79,
E 'metric-type': 'OSNR-0.1nm'},
E {'accumulative-value': 0.0019952623149688794,
E 'metric-type': 'reference_power'},
E {'accumulative-value': 20000000000.0,
E 'metric-type': 'path_bandwidth'}],
...
... now, it's a bit annoying that there's too much output, but
... that's just for context; the offending lines will be properly
... marked, see --\
... |
... v
...
E {'path-route-object': {'index': 17,
E - 'num-unnum-hop': {'gnpy-node-type': 'transceiver',
E ? ^ ^^^^^^^ - ^ ^^^^^^^^^ -
E + 'num-unnum-hop': {'link-tp-id': 'trx '
E ? ^^ ^ ^^^ ^^
E - 'link-tp-id': 'trx '
E 'Lannion_CAS',
E 'node-id': 'trx '
E 'Lannion_CAS'}}},
E {'path-route-object': {'index': 18,
E 'label-hop': {'M': 6,
E 'N': -274}}},
E {'path-route-object': {'index': 19,
E 'transponder': {'transponder-mode': 'mode '
E '2',
E 'transponder-type': 'vendorA_trx-type1'}}}]},
E 'response-id': '5',
E }
tests/test_parser.py:312: AssertionError
Change-Id: I60b4e3bfa432a720a381bf2c0a9f0288e989dab2
GNPy 2.3.1
Just some release automation on top of v2.3. If you're already on v2.3,
there's no need to update; this release does not contain any
user-visible changes.
Change-Id: I0473a0bb43be596cf376cf18eb8a546b53aa0214
Pushes to master should create a "development" tag. Tags should create
something prettier.
We need the git checkout for proper package versioning, hence that magic
`context` thing, and also that magic `echo`.
Change-Id: I79fcb800cc079e8486c3795f36aa1993676cee49
Our landing page on PyPI was not displaying the longer version of the
README, just a one-sentence summary. It turns out that `pbr` can indeed
read the README file, but specifying the `description` overrides that
with no warning. Yay.
Change-Id: Ic03412928fe09f5edab4a7b9f4297a485a740cd0
We're using PBR, so let's make sure we don't get a package that's marked
as version 0.0.0.
Bug: https://github.com/actions/checkout/issues/217
Change-Id: Icd8264a798f9a1a404e21a9b64317c57662d53fe
This might be a wee bit controversial, I guess, because the Zuul jobs
look like there's a dedicated playbook for that
(playbooks/python/release.yaml). However, that would be one extra VM
launch, which feels wasteful. Let's waste the CPU cycles elsewhere --
during each "regular test build", produce a wheel as well.
It looks that these "wheels" are *the* format for distributing Python
packages now -- including the source code, of course. Since there's no
real support for tag review in Gerrit, I don't think I need Zuul for
release management, either, so I'll just rely on GitHub actions for
release upload, I guess. And for that, I need to "somehow" create a
wheel anyway, so let's just do this all the time to ensure that it
really works and never stops working.
Change-Id: Ib86852a386673cd4929a8059b19fa527cd4d5955
We have Zuul, and we're happy with it; however, every now and then
there's a problem with the managed infrastructure, and there's also
people who contribute patches as GitHub PRs.
Change-Id: I405c5806ed9ad2e7f59f9b2394daf068b373e425
Our landing page on PyPI was not displaying the longer version of the
README, just a one-sentence summary. It turns out that `pbr` can indeed
read the README file, but specifying the `description` overrides that
with no warning. Yay.
Change-Id: Ic03412928fe09f5edab4a7b9f4297a485a740cd0
We're using PBR, so let's make sure we don't get a package that's marked
as version 0.0.0.
Bug: https://github.com/actions/checkout/issues/217
Change-Id: Icd8264a798f9a1a404e21a9b64317c57662d53fe
This might be a wee bit controversial, I guess, because the Zuul jobs
look like there's a dedicated playbook for that
(playbooks/python/release.yaml). However, that would be one extra VM
launch, which feels wasteful. Let's waste the CPU cycles elsewhere --
during each "regular test build", produce a wheel as well.
It looks that these "wheels" are *the* format for distributing Python
packages now -- including the source code, of course. Since there's no
real support for tag review in Gerrit, I don't think I need Zuul for
release management, either, so I'll just rely on GitHub actions for
release upload, I guess. And for that, I need to "somehow" create a
wheel anyway, so let's just do this all the time to ensure that it
really works and never stops working.
Change-Id: Ib86852a386673cd4929a8059b19fa527cd4d5955
We have Zuul, and we're happy with it; however, every now and then
there's a problem with the managed infrastructure, and there's also
people who contribute patches as GitHub PRs.
Change-Id: I405c5806ed9ad2e7f59f9b2394daf068b373e425
We discussed this at one of the recent coder calls; the motivation
includes better mypy type hint support, especially in numpy, but also in
the language core, and of course the dataclasses.
Change-Id: I8ffee28c33f167cbcba978c85486e58a1b8c99be
All other noise models set the `nf_def` variable, so let's make the YANG
code simpler by remembering the amplifier NF model like that.
Change-Id: I341e4ac296c25bf9f27a98a7e4e92e0fd1546021
The current JSON data loader preserves (some) integers as integers. When
printed, the value might not contain any decimal points. The YANG patch
series, however, forces floats when floats are expected (while still
allowing None). This makes the output subtly different.
Change-Id: I0e0c013eb3abddb4aeac1ba43bf0d473fed731d4
The term "GSNR" is well established by now. I think it's time we start
using it in our own result outputs instead of alternatives like "total
SNR" or just "SNR".
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I1fc65f6db1e3b2d7cfe974875174132fe5b28d3b
