See GitHub issue #368
The out_voa attenuation of the previous Edfa is currently not taken
into account when calculating power target for an Edfa in gain mode.
This makes the calculated gain target (in case of autodesign) for
the following Edfa in the chain incorrect and also impacts automatic
amplifier selection.
Change-Id: Idc473762ccf7b021a0885c7ce20de1abb66eb075
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
See issue reported in #360
In autodesign, currently the calculation of gain for the first Edfa
after a Roadm is incorrect when the reference channel power is
different from 0 dBm. The bug is somewhat hidden by the fact that the
gain is anyway updated during propagation in power mode, taking the
reference channel power into account. But the gain reported by the
to_json function of Edfa elements before propagation will be wrong.
And more seriously, the incorrect gain will impact the Edfa selection
in autodesign.
Change-Id: I004de102832c3a0786435e21e71b0444d8901604
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
- add the per degree info using the EXACT next node uid as identifier
of the degree when a node is a roadm
- add the degree identifier on the propagate and on the call functions
- use the per degree target_pch_out_db defined in json entry for the
target power in network build
- verifies existence of the per degree power target in order to support
partial per degree target power definition
- correct test data files for expected auto design results that now
should include the per degree information, even if it is the same
for all degree.
- in order to enable per degree power definition on direction where
booster is not defined, enable the declaration of edfas in json without
specifying type variety
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I5004cbb250ca5fd6b6498ac9d4b9c4f28a65efee
The current implementation based on scipy interp1d fails when
predecessor and successor of the fiber to be split have the same
longitude. In this case the new latitudes become NaN. This patch
fixes the bug.
Change-Id: I7c5dc4d410630a6b4b773d36cc192db8271a4346
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Other functions used be build_network raises NetworkTopologyError when
a fiber is not properly connected but this handling was missing from
add_connector_loss.
Change-Id: Id08cd4a9bad15f755d364a31ff3d38993d034447
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
We agreed that `gnpy.core` should only contain stuff for propagating
wavelengths. Conceptually, JSON parsing and even instantiating these
network elements from data obtained through JSON is *not* something that
is on the same level -- and this will become more important when we move
into YANG format in future.
Also, instead of former `gnpy.core.equipment.common`, use
`gnpy.tools.json_io._JsonThing`. It is not really an awesome name :),
but I think it sucks less than a thing called "common" which would be no
really longer any "common" in that new file.
Change-Id: Ifd85ea4423d418c14c8fae3d5054c5cb5638d283
Similarly to I7ab9f64d7ac2042e8a16d031ba5562a6eb412471, it's better to
be explicit about what's going on. It makes it easier to reason about
the code.
Change-Id: Ic7f4a590567f1f5903222be8dae53521424d8f77
This will be needed by one of the follow-up commits which move JSON
manipulation into a single file. We have to distinguish between "Roadm"
the JSON representation and "Roadm" the network element which propagates
spectrum.
Change-Id: I6888842c57c3a57849fabe75d0ff6f5bbfab426a
I think that equipment.py should be only concerned with constructing
network elements from JSON data.
Change-Id: I777835b02a23b76fb1d40c3a966e72b606e9c205
The TL;DR behind this patch is that it's better to have a utility
conversion function instead of having multiplier LUT and open code which
implements the conversion.
The FiberParams handling looked fishy -- apparently, it was keeping the
multiplier around, but it was unconditionally setting the units to
meters, anyway. Given that the units were not being preserved anyway
(everything got converted to meters), and that the multipler was not
used anywhere, let's refactor the code to just convert to meters using
our new utility function, and remove the unused argument.
Change-Id: Id886d409a4046f980eed569265baefd97db841bd
This mainly reverts some auto-fix-ups done in
I2f0fca5aa1314f9bb546a3e6dc712a42580cd562 which do not make that much
sense. By reverting them by hand, it's (hopefully) easy to see what is
just a tool work and what is an opinionated preference.
Change-Id: I6cb479e34b552fadc85c41b4b06b24e60c87b4a3
Conceptually, this is just about propagating the input parameters (which
drive the simulation) into all RamanFiber instances. The network module
already contains similar functions, let's move it there.
This feature is intended to support designs such as OpenROADM where the
line degree integrates a specific preamp/booster pair. In that case, it
does not make sense for our autodesign to "pick an amplifier". The
restrictions can be activated by:
- Listing them in `eqpt_config.json`, so that they are effective for all
ROADM instances.
- On a per-ROADM basis within the Excel sheet or the JSON definitions.
Restrictions apply to an entire ROADM as a whole, not to the individual
degrees.
If a per-degree exception is needed, the amplifier of this degree can be
defined in the equipment sheet or in the network definition.
If no booster amplifier should be placed on a degree, use the `Fused`
node in place of an amplifier.
Signed-off-by: Esther Le Rouzic <esther.lerouzic@orange.com>
Co-authored-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
-separate edfa and raman_list of acceptable amplifiers to better
customize criteria between edfa and raman amplifiers
for example min gian requirement: no extended min gain range for raman
amplifiers because there is always an edfa solution, which is better for
small gains.
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
- in auto-design, Raman is already not used if lineic fiber loss >
eqpt_config.json [Span][max_fiber_lineic_loss_for_raman]
- this commit ensures that a warning is displayed even when auto-desing
is not used (when the network equipment configuration is imported from
json or xls topology)
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
EOL span ageing was added for each connector "to be fused" span
=> now, EOL ageing is only added to the last span of the fused spans
section.
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
when constraints such as include noe or disjuntion is applied
the candidates are sorted with shortest path in length first
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
add weight = length of fiber nodes on connections wher from_node is a fiber
add weight = 0.01 km on other edges
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
warning message when extended gain range or power requirements cannot be met
and power is reduced
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
power mode no longer reads operational_gain:
now reads operational.dp_db
or calculate optimum dp_db from next span loss
gain_mode:
reads operational.gain_target
or use gain_from_dp
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
squash to dp
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
tolerate 3dB below min gain in amplifier selection
this is to allow selection of high power amps even if they are below min
gain
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
used for amplifier selection in auto-design
but it is possible to manually use and set an amplifier beyond its
extended_gain_range
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
support min gain for raman auto-design:
raman amplification is only considered for a span if its gain > specified
min gain of the raman hybrid in eqpt_config
auto-design was checked succesfully when enabling a mix of 6 possible different
amplifiers: low gain, medium gain, hybrid ramans, high power and high
gain amplifiers. They were picked as expected.
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
