gnpy currently uses the same parameter for tx output power and span
input power: this prevents from modelling low tx power effect.
This patch introduces a new tx-cannel-power and uses it to
propagate in ROADM.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Id3ac75e2cb617b513bdb38b51a52e05d15af46f5
default parameters are shared between json and network function,
so it is better to have them on the parameters to avoid circular
dependency when importing modules
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ib9d41852e394586d36f74992c91f67f3330cc552
- Replaced multiple calls to the span_loss function
with recording the span loss result in the fiber elements,
reducing computation time.
- Updated Raman gain estimation based on design target powers to ensure
accurate Edfa gain calculation or gain reduction during design.
- display the computed and design Raman gain in RamanFiber string output
- do not add padding on Raman fibers
- Added to_json function to preserve user input SimParams values,
which were previously overwritten by initializing SimParams
with fake values during design.
Next step is to allow users to balance computation time and
target accuracy of the design by inputing their own SimParams
and ref channels design values.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I1ca4954d0621858cefb3d776a538131992cae3e3
The recent refactor removed a default pref in case of transceivers-OMS
(amplified links starting with a transceiver).
This resulted in a mismatch between input power during design
(default 0 forced in the function) and the design ref power using SI
power_dbm.
This change ensures that the same power is used for the input power
and for the design ref power, and avoid inconsistent gain computatiion.
The code has been using the same power input (SI power_dbm) to define the
power target out of a transceiver and the target out of amplifiers
(at the input of fibers). This will be changed in a future patch.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I610c8df19039bcf156a8ba77c79114b22913a538
Finally, ref_carrier is not meant to change after design since
it is the carrier used for design. So let's move its definition
to networks function. Only ROADM need the ref_carrier baud rate
so let's define a dedicated variable in ROADM to hold it.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ida7e42dd534a04c8df8792b44980f3fd2165ecb6
reference channel is defined during design. No need to convey it
anymore during propagation.
move target_pch_out_db definition to the design phase and change
its name to be consistent with what it contains (dbm)
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I350e4557e8488a614674042de26152ab89b2d245
Remove the visualisation of the effective_pch in amp because actual
and target are the relevant ones. effective_pch was artificially
related to a mix of reference channel and noisy channel (mixed between
on the fly redesign but using actual ROADM equalisation which includes noise
in its actual loss).
the change does no more rely on the target power (which is rounded)
but on the designed gain, which is not rounded.
Propagations are slightly changed for openroadm simulations because of that.
(I verified)
The gain of amp was estimated on the fly with p_spni also in case of
RamanFiber preceding elements. removing p_spani requies that an estimation
of Raman gain be done during design.
This commit also adds this estimation.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I960b85e99f85a7d168ac5349e325c4928fa5673b
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
transmission-main-example and path-request-run functions implement an
on-the-fly redesign based on p_span_i.
Since we remove p_span_i from elements, we will need to properly call
redesign several times before each propagation, to keep the same
behaviour of these functions.
in this commit we simply enable the possibility to mute warnings.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I3aa3d8fc87325033ef69641078bdd7213e0409eb
separate function that adds element, from function that configure them
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ica332223bdf7fc599cb007d7513d7cd62d9c5f9c
input power is computed at design time: so let's record it and
use it instead of p_span_i for reference channel fiber loss computation.
Note that this loss parameter is only used for visualisation purpose.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I16bd792bd6079ce521aafadcf5e21922aa3b4c81
input power is computed at design time: so let's record it and
use it instead of p_span_i for ROADM reference channel loss computation.
Note that this loss parameter is only used for visualisation purpose.
No impact on propagation.
Since this loss is computed for the reference channel used for
design, we need to record input power based on input degrees,
and indicate this information within the call function.
Note that this will be also usefull later on to implement ROADM
parameters
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I64d510fc20df72f07158f400964d592d76dc0ce4
Let's use a clean convention to hold values that are configured,
autodesigned or resulting from propagation.
- edfa.operational.delta_p: holds the value set by the user if any.
This is needed in case of redesign for power sweep for example.
It is never changed.
- edfa.delta_p:
o if power_mode is true, records the value computed by the design.
Applies user defined value except:
If the user has set non possible values (eg leading to saturation),
then the value is corrected at design phase.
If the element is propagated for different conditions than
design, for example leading to saturation, then delta_p might be
different than the value initially computed during design.
o if power_mode is False, it is set to None
- edfa._delta_p: records the value computed during design whatever
the power mode
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I4e130a3abe0a5e3f6c057d89360e50531c168123
Previously saturation was not checked during design if amp type was set.
This commit also applies saturation for these amplifiers.
This changes some of the autodesign result (since range for selection
is changed). For example, this changes some of the gains, or type variety
of amplifier of test files.
The commit also removes one of the rounding in the design phase, and
applies rounding only for printing purpose.
It also adds minor refactor on a function
In order to keep power sweep behaviour in case of saturation, the saturation
check in amplifier element uses initial power targets set by user instead
of a possible autodesign delta_p result.
Note that gain_mode is unchanged: design in gain mode means that delta_p
is set to None during the build process, even if the user defined a value
in operational.delta_p.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Idc5cfc8263cf678473acb6ec490207d9d6ba5c0a
The parameters of the EDFA are explicitely retrieved in the EDFAParams class.
All the defaults are set instead in the gnpy.tool.json_io.AMP class.
Where required, the AMP.default_values are used instead of an empty dictionary.
Change-Id: Iba80a6a56bc89feb7e959b54b9bd424ec9b0bf06
Co-authored-by: Vittorio Gatto <vittoriogatto98@gmail.com>
Constant power per slot_width uses the slot width instead of
baud rate compared to PSD.
This is the equalization used in OpenROADM
add tests for constant power per slot width equalization
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ie350e4c15cb6b54c15e418556fe33e72486cb134
According to the documentation, auto-design will
"Split fiber lengths > max_length", which also makes sense based on the
name of the parameter but with the existing implementation fiber
length could still be longer than max_length after splitting. This
patch makes auto-design respect the specified max_length.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: Ifd83aa4d77206bf10796579df73632fe405e2d54
On a ROADM, the code would previously set the same per-carrier power
regardless of the channel spectrum width. With this patch, carriers are
equalized either by their:
- absolute power (same as before),
- power spectral density (PSD).
Also, it's possible to apply a per-channel power offset (in dB) which
will be applied to a specified channel on top of the selected
power-level or PSD strategy. The same offset can be also selected
through the `--spectrum` option via the `default_pdb` parameter.
The equalization policy can be set via the ROADM model (in the equipment
config) as well as on a per-instance basis.
The PSD is defined as the absolute power over a spectral bandwidth,
where the spectral bandwidth corresponds to the actual spectrum
occupation (without any applicable guard bands), as approximated by the
symbol rate. PSD is specified in mW/GHz. As an example, for a 32 GBaud
signal at 0.01 mW, the PSD is 0.01/32 = 3.125e-4 mW/GHz.
This has some implications on the power sweep and ROADM behavior. Same
as previously (with absolute power targets), the ROADM design determines
the power set points. Target power is usually the best (highest) power
that can be supported by the ROADMs, especially the Add/Drop and express
stages' losses, with the goal to maximize the power at the booster's
input. As such, the `--power` option (or the power sweep) doesn't
manipulate with ROADM's target output power, but only with the output
power of the amplifiers. With PSD equalization, the `--power` option is
interpreted as the power of the reference channel defined in equipment
config's `SI` container, and its PSD is used for propagation. Power
sweep is interpreted in the same way, e.g.:
"SI":[{
"f_min": 191.3e12,
"baud_rate": 32e9,
"f_max":195.1e12,
"spacing": 50e9,
"power_dbm": 0,
"power_range_db": [-1,1,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
}],
...and with the PSD equalization in a ROADM:
{
"uid": "roadm A",
"type": "Roadm",
"params": {
"target_psd_out_mWperGHz": 3.125e-4,
}
},
{
"uid": "edfa in roadm A to toto",
"type": "Edfa",
"type_variety": "standard_medium_gain",
"operational": {
"gain_target": 22,
"delta_p": 2,
"tilt_target": 0.0,
"out_voa": 0
}
},
then we use the power steps of the power_range_db to compute resulting
powers of each carrier out of the booster amp:
power_db = psd2powerdbm(target_psd_out_mWperGHz, baud_rate)
sweep = power_db + delta_power for delta_power in power_range_db
Assuming one 32Gbaud and one 64Gbaud carriers:
32 Gbaud 64 Gbaud
roadmA out power
(sig+ase+nli) -20dBm -17dBm
EDFA out power
range[
-1 1dBm 4dBm
0 2dBm 5dBm
1 3dBm 6dBm
]
Design case:
Design is performed based on the reference channel set defined in SI
in equipment config (independantly of equalization process):
"SI":[{
"f_min": 191.3e12,
"baud_rate": 32e9,
"f_max":195.1e12,
"spacing": 50e9,
"power_dbm": -1,
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
}],
`delta_p` values of amps refer to this reference channel, but are applicable
for any baudrate during propagation, e.g.:
{
"uid": "roadm A",
"type": "Roadm",
"params": {
"target_psd_out_mWperGHz": 2.717e-4,
}
},
{
"uid": "edfa in roadm A to toto",
"type": "Edfa",
"type_variety": "standard_medium_gain",
"operational": {
"gain_target": 22,
"delta_p": 2,
"tilt_target": 0.0,
"out_voa": 0
}
},
Then the output power for a 64 Gbaud carrier will be +4 =
= lin2db(db2lin(power_dbm + delta_p)/32e9 * 64e9)
= lin2db(db2lin(power_dbm + delta_p) * 2)
= powerdbm + delta + 3 = 4 dBm
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I28bcfeb72b0e74380b087762bb92ba5d39219eb3
Mainly changes self.pch_out_db to self.ref_pch_out_dbm in order
to reflect real unit for the value and to remind that this value
is defined for a reference noiseless channel (whose power is recorded
in p_spani in Pref).
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: If0e008c3efc36ce73c9df01c76cf46985543d9fa
Since splitting fibers may result in fibers with loss lower than
specifed padding, the padding should be added after splitting.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: Id75ddf5d81c4c1c52f8f8becfdb005d2fe04c1f8
This fixes#420.
In order to be consistent with the OpenROADM MSA, the input power per
channel used for calculating incremental OSNR and NF should be scaled to
50 GHz slot width.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I64ca3e4cad6399f308827f4161d7c6b89be9d2ca
See GitHub issue #419.
The unit of max_fiber_lineic_loss_for_raman in the default equipment
config file is dB/km but it was compared with Fiber.params.loss_coef
which is in units of dB/m.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I27c8ab03845a72fcda97415843c007078b7b9d06
Currently, a warning about fiber lineic loss being above threshold is
printed even when the warning is triggered by that the previous node is
not a fiber, which is confusing. Additionally, when a warning about
raman is triggered, the code in the following else clause is not
executed, which means that a potential warning about gain level is
disabled. These two warnings are independent and the second one should
not be disabled by the first one.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I8ad58b4ebf6e7df1a949a77d67ed948ef385c47e
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
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
The auto-design feature inserts EDFAs after ROADMs and fibers when they
are not already present in the input topology file. This functionality
can be locally disabled by manually adding a Fused element in the
topology. This patch adds an option to the cli example scripts,
"--no-insert-edfas", which globally disables insertion of EDFAs as well
as automatic splitting of fibers.
Change-Id: If40aa6ac6d8b47d5e7b6f8eabfe389e8258cbce6
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
I believe a previous commit, 3ac08f5, changed the behaviour of span
loss calculation in an unintended way, since now it adds the loss of
consecutive fiber elements even when there is no fused element in
between. This means for example that no padding is added when the loss
of consecutive fibers is higher than the padding specified in the
equipment file even though inline amplifiers will be added between the
fibers in a later step. This patch changes the conditions in the next_
and prev_node_generator so that they stop when two consecutive fibers
are found.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I42c9188c789a98a9b3d7e51d5aae15774d40dde7
Currently, calculated new fiber coordinates, after splitting a fiber by
auto-design, are evenly distibuted. Since coordinates for added inline
edfas are the midpoint between neighboring nodes, this makes the edfas
"look" non-equidistant even if all spans have the same length. I think
it would make more sense to have the fiber coordinates represent the
midpoint of the fiber. That way, the edfa positions will look more
"natural". Here is an attempt to illustrate the difference for a link
with three fiber spans:
Before this patch:
r-----f--e--f--e--f-----r
After this patch:
r---f---e---f---e---f---r
r = roadm
e = edfa
f = fiber
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I6eafe3fcd4c718b0b995a046dbff0fd04bdc42d7
The old code assumed that the Fused node only connects Fiber nodes. In a
sequence of Fused - Amplifier - Fused - Fiber, the Amplifier would be
included by a mistake. In addition, the code was not that easy to read,
and it just instantiated StopIteration without raising that (which would
be an error in a generator context). It was also rather strict, failing
if the iterator was requested for an "edge node" (a transponder), and
one of the exceptions was not actually an f-string.
Finally, the span_loss function would occasionally report wrong values
(for example in the provided test case, span_loss("fused7") would say 1
instead of 17).
Fix this by making sure that prev_node_generator() and
next_node_generator() never return anything but Fiber and Fused nodes,
which made it possible to simplify the span_loss() function. This should
now properly account for the accumulated losses of an arbitrary sequence
of Fiber and Fused elements.
I went over this a few times because set_egress_amplifier() calls
span_loss() on a *ROADM* node type. That does not make any sense, and
the code deals with this "properly" by returning a loss of 0 dB. It was
a bit confusing for me to see that it's actually OK to ask for a "span
loss" that's identified by a ROADM.
A side effect of this code is that Fused instances that are isolated
from the rest of the topology no longer raise an exception. I was
thinking about preserving this (because for GNPy, the only element with
no previous or no next nodes are the transceivers, but then Esther's
test topology contains an isolated `fused4` element. If we want to make
this strict, we can do that easily like this:
--- a/gnpy/core/network.py
+++ b/gnpy/core/network.py
@@ -162,10 +162,12 @@ _fiber_fused_types = (elements.Fused, elements.Fiber)
def prev_node_generator(network, node):
"""fused spans interest:
iterate over all predecessors while they are Fused or Fiber type"""
try:
prev_node = next(network.predecessors(node))
except StopIteration:
- return
+ if isinstance(node, elements.Transceiver):
+ return
+ raise NetworkTopologyError(f'Node {node.uid} is not properly connected, please check network topology')
if isinstance(prev_node, _fiber_fused_types) and isinstance(node, _fiber_fused_types):
yield prev_node
yield from prev_node_generator(network, prev_node)
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Co-authored-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
Change-Id: I41a65e89eef763f82e41e52bc325ed2d488cb601
This is an old pull request rebased and restricted to only raising warning.
The initial work also limited gain, which is finally not a desired behaviour:
an advanced user might want to have this high gain.
the only impact on test is that it raises warnings on almost all amplifiers
on the mesh_topology_exampleV2.xls: indeed all of them are set to low_gain
but without gain specified and the result of autodesign results in higher gains
than supported by this amplifier variety.
This may be confusing for users to see these warnings on an example from gnpy
so I will push a new commit changing the amp types to avoid this.
The alternative would be to push the warnings into the logger, so they
remain invisible, but I think that the example change makes more sense.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Idf0c67137b5b466b07ddc7817f53a82f92a21a5b
Patch 503833 (Fix calculation of gain for first Edfa after Roadm)
introduced a bug when it was rebased on top of the per degree power
feature since per_degree_pch_out_db used for propagation was actually
updated based on calculated prev_dp value.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I39e8f5945d5035b99c70ef577011bba79bb89a72
This allows users to limit the choice of type_variety by auto-design
for an EDFA node by setting a "variety_list" attribute in the input
topology json file. One use-case is switchable gain EDFAs where the
two gain ranges can be modeled by two separate type varieties in the
equipment library. A user may know that such an EDFA will be used in
a node but not which gain range is optimal. The choice of gain range
can then be left to auto-design while not allowing any other
type_variety by specifying the node e.g. like this in the topology:
{
"uid": "Edfa1",
"type": "Edfa",
"variety_list": ["foo_gain_range_1", "foo_gain_range_2"],
...
}
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: Ia69ef78f885e3a61310530b6b80da64e43758211
Currently when an Edfa is inserted by auto-design after a Roadm (i.e.
booster) it gets the same city attribute as the Roadm while an Edfa
inserted before a Roadm (preamp) gets the city attribute from the
preceding fiber. This is illogical and confusing. Also both the Edfa
preamp and booster get coordinates different from the Roadm (halfway
between the Roadm and the neighbor node). Since in practice the preamp
and booster are always colocated with the Roadm I think it makes more
sense to give them the same coordinates.
Also change how uid is assigned to an Edfa connected to a Roadm so that
it indicates whether it is a booster or a preamp.
Change-Id: I98718fe1e2914b5628e7cfd23fc28fb5708a8889
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Currently, auto-design does not work for an OMS starting from a Trx
that is not connected through a Roadm if the topology also contains one
or more Roadms. I don't see a good reason not to support this case,
since a Trx not connected through a Roadm can make sense, e.g. for a
degree-1 node. This is a proposal to remove the restriction.
Change-Id: I14686521a838b30249126b9bd403fa26c848875a
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Currently, if an input topology contains a loop in an OMS, the
set_egress_amplifier method in network.py will go into an infinite
loop. With this patch, such a loop is detected and an error is raised.
Change-Id: Id7cd0cc6d7eaff3af1d9e0309b5c2eb90aeb7454
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
In network.py we are already checking that fibers are properly
connected. Let's check Edfas and other node types as well.
Change-Id: I224b9046729197fef3eb172e9631969a2da13ab5
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
