Introduce a new multi-band element that contains a list of Edfa element:
- reads multiple amps out of the element config.
- deduces frequency band from the amp in the list.
no autodesign yet: multi-band amps must have type_variety.
- checks that type variety of individual EDFAs is consistent with multiband
type variety
- demux and mux spectrum when propagate in multiband
- don't add a preamp or booster if a multiband amp is already defined.
The print of channel number is removed from equipment, since the channel number
may now depend on the path's amplifiers. This changes invocation results layout.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I44e77ff82e622cdee4021a7984d660317cb90cf9
redesign True means that network is redesigned using each request
as reference channel. When False it means that the design is made
once and successive propagation use the settings computed with this
design.
Default propogation is without redesign, so that path-request-script
must use the ----redesign-per-request option to behave as before this
commit.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I0084185106d14659a846136620cd17791d551a7d
if user define a delta_p that is reduced because of saturation,
then this initial setting is still kept for power sweep to be sure
that the full amplitude of sweep is used.
SI power = 0 dBm
max power amp1 = 20 dBm,
user_defined_delta_p set by user = 3
80 channels, so pch_max = 20 - 10log10(80) = 0.96 dBm
power_sweep -> power range [-3, 0] dBm
then for initial design,
pref = 0 dBm
computed_delta_p =
min(pch_max, pref + user_defined_delta_p) - pref = 0.96
but for -3 power sweep
pref = -3 dBm
computed_delta_p =
min(pch_max, pref + user_defined_delta_p) - pref =
min(0.96, -3 + 3) - (-3) = 3
so the user defined delta_p is applied as much as possible
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I8fd459c29aa9754ff9d4868af1d8be8642a31913
line numbers are useful for debugging, but the benefit does not
compensate for the painful update of lines in files at each commit
that changes line numbers.
So I have removed those lines only for the test_invocation logs case.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ic1f628d80b204a9a098f3902ebdfd10b480c7613
The option is only set for gnpy-transmission-main.
The spectrum file is a list of spectrum objects, each defining
f_min, f_max and spectrum attributes using the same meaning as SI
in eqpt_config.json for baud_rate, roll_off, tx_osnr. slot_width is
used for the occupation of each carrier around their central frequency,
so slot_width corresponds to spacing of SI.
Unlike SI, the frequencies are defined includint f_min and f_max.
The partitions must be contiguous not overlapping.
Pref.p_span0 object records the req_power, while
ref_carrier records info that will be useful for equalization ie baud_rate.
For now, I have not integrated the possibility to directly use
transceivers type and mode in the list.
User can define sets of contiguous channels and a label to identify
the spectrum bands. If no label are defined, the program justs uses
the index + baud rate of the spectrum bands as label.
Print results per spectrum label
If propagated spectrum has mixed rates, then prints results (GSNR and OSNR)
for each propagated spectrum type according to its label.
Print per label channel power of elements
Per channel power prints were previously only showing the noiseless
reference channel power and only an average power.
With this change, we add a new information on the print:
the average total power (signal + noise + non-linear noise).
If there are several spectrum types propagating, the average per
spectrum is displayed using the label.
For this purpose, label and total power are recorded in each element
upon propagation
Note that the difference between this total power and the existing
channel power represents the added noise for the considered OMS.
Indeed ROADMs equalize per channel total power, so that power displayed
in 'actual pch (dBm)' may contain some noise contribution accumulated
with previous propagation.
Because 'reference pch out (dBm)' is for the noiseless reference,
it is exactly set to the target power and 'actual pch (dBm)' is always
matching 'reference pch out (dBm)' in ROADM prints.
Add examples and tests for -spectrum option
initial_spectrum1.json reproduces exactly the case of SI
initial_spectrum2.json sets half of the spectrum with 50GHz 32Gbauds and
half with 75GHz 64 Gbauds. Power setting is not set for the second half,
So that equalization will depend on ROADM settings.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ibc01e59e461e5e933e95d23dacbc5289e275ccf7
Existing tests only cover short distances, and effect on accumulated
noise, especially when crossing ROADMs with equalization, are not well
reported on elements power prints.
With this long path, I can catch more printing inconsistencies.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I2d0e8ccbbd387a2cd6c645c07f4b5f75e4617c30
The recent commit has added support for OpenROADM v5, the latest
published optical spec sheet. Given that the upstream project has
released v10 YANG files (but still just v3, v4 and v5 XLS sheets with
optical performance numbers), I think it would be rather misleading to
have both versioned and non-versioned config files -- especially when
the unversioned one refers to the oldest release, not the newest one.
Change-Id: I04109341724b51d276660d400c923dc28561aef2
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
Esther mentioned that it is useful for her to be able to convert from
XLS files to JSON files. Let's add a full blown script for this.
I've also taken the liberty to refactor the code a bit so that there's
no default value, and to modernize everything with pathlib a little bit.
Change-Id: I80e50fc1280003910242ce1ff9fc9ae66e6d275b
I would like to create a package for distribution to PIP, and this seems
like the path of least resistance.
This is, apparently, the way for shippign arbitrary data with Python
[1]. I've at least tried to make it user-firendly via adding a simple
utility which just prints out whatever that data path is.
[1] https://python-packaging.readthedocs.io/en/latest/non-code-files.html
Change-Id: I220ecad84b1d57d01e3f98f15befc700bd97c0b8
Since Ic4a124a5cbe2bd24c56e4565d27d313fe4da703f, there was no automated
test which would check if the generated examples *really* work. When I
was playing with this, I managed to break it at least once (especially
when working on overriding sys.args, i.e.,
I53833a5513abae0abd57065a49c0f357890e0820).
This now requires an equivalent of `pip install` before the tests can be
run.
Change-Id: I595a3efe29b3ee13800c5cb71f28a5f370988617
I would like to avoid that extra fork to a child Python interpreter (it
looks like something that can be easily avoided). It's something that's
possible now that the code ships just some trivial wrappers (which are,
in turn, needed for setuptools' `console_scripts`).
This cannot use the `capsysbinary` fixture for wrapping of stdout/stderr
due to something in pytest which already got fixed, but has not been
released yet (May 2020). Let's use `capfdbinary` which works fine.
Change-Id: Ic4a124a5cbe2bd24c56e4565d27d313fe4da703f
See-also: https://github.com/pytest-dev/pytest/pull/6926
This will make it simpler to update coverage info. The pytest-cov plugin
that we're already using apparently makes this behavior supported, nice.
Change-Id: Ieafc0da99a8c325f5f2286ed11e66069e244e43b
