Before this change, all channels are set to the same
target_pch_out_db powe, whatever their rate. With this change,
we enable 3 equalizations (taht can be mixed)
- power
- power spectral density (psd)
- user defined power delta
the behaviour of the software is changed as follows:
propagation case:
----------------
eqpt config defines the policy for the whole network:
without any other indication in ROADM instances,
"target_pch_out_db" means power equalization
"target_psd_out_mWperGHz" measn psd equalization
(user defined delta depends on -spectrum option inputs)
psd is computed using channel baud rate for the bandwidth
"Roadm":[{
"target_pch_out_db": -20,
xor "target_psd_out_mWperGHz": 3.125e-4, (eg -20dBm for 32 Gbauds)
"add_drop_osnr": 38,
"pmd": 0,
...}]
-> if target_pch_out is present in a roadm, it overrides the general default for this roadm equalization
-> if target_psd_out is present in a roadm, it overrides the general default for this roadm equalization
only one of the two can be present in a roadm
the same per_degree dictionnary is added to handle per_degre psd
similarly to target_pch_out, if a per_degree_psd is defined it overrides the general(network) or general(roadm) settings
eg:
{
"uid": "roadm A",
"type": "Roadm",
"params": {
"target_pch_out_db": -20,
"per_degree_pch_out_db": {
"edfa in roadm A to toto": -18,
}
}
},
means that target power is -20 dBm for all degrees except "edfa in roadm A to toto" where it is -18dBm
{
"uid": "roadm A",
"type": "Roadm",
"params": {
"target_psd_out_mWperGHz": 2.717e-4,
"per_degree_psd_out_mWperGHz": {
"edfa in roadm A to toto": 4.3e-4,
}
}
},
means that target psd is -2.717e-4 mw/GHz for all degrees except "edfa in roadm A to toto" where it is 4.3e-4.
mixing is permited as long as no same degree are listed in the dict
{
"uid": "roadm A",
"type": "Roadm",
"params": {
"target_pch_out_db": -20,
"per_degree_psd_out_mWperGHz": {
"edfa in roadm A to toto": 4.3e-4,
}
}
},
means that roadm A uses power equalization on all its degrees except "edfa in roadm A to toto" where it is power_sectral density
------------------
initial spectrum mix
initial spectrum mix can be defined by user in a json file composed of a list of {"f_min", "f_max", "baud_rate", "spacing" "power_dbm", "roll_off", "tx_osnr"}. these fmin-fmax should not overlap.
this file will be used with transmission main only. (hard to define a mix in case of planning)
if the user does not set power in ths file, it is assumed that the default equalisation is used.
if the user sets initial powers, this mix of power has to be used (p_span0_per_channel refers to this)
if p_span0_per_channel is empty, the equalization of the roadm is used
----------------------
power sweep behaviour in ROADMs:
expected behaviour is that per degree power / psd is not changed by power sweep or change of power of a
propagation request:
target power is the result of the roadm design and is the best (highest) power that can be supported by
roadms given the add power range. the rationale behind that is that to have best OSNR at booster, it is
required to have the highest possible power. but this power is constrained by add/drop and express stages
loss and power out limitation of the amps in these stages. So it is probably not possible to increase it
for limitations issues and not desirable to decrease it for performance issues.
(as a side remark, given the current behaiour, I think that renaming target_pch_out_db into
target_pch_out_dbm would make sense)
so current behaviour when we apply power sweep or --pow option, is that this does not affect the power out
from the ROADM. only the target power at the output of amps
with PSD, the same rule applies: power sweep or --pow option can be used to change the propagated reference
power/psd. the proposed behaviour depends on the OMS add roadm:
- if roadm degree equalization is power, then same behaviour as today
- if roadm degree equallization is psd, then
o --pow is interpreted as the power of the reference channel defined in SI container in eqpt_config
and its psd is used for propagation.
o power sweep is interpreted in the same way with a translation on carriers
eg :
suppose that we have SI in eqpt_config:
"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 psd equalization in roadms
{
"uid": "roadm A",
"type": "Roadm",
"params": {
"target_psd_out_mWperGHz": 2.717e-4,
}
},
{
"uid": "edfa in roadm A to toto",
"type": "Edfa",
"type_variety": "standrd_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 pow
(sig+ase+nli) -20dBm -17dBm
edfa out pow
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 equipement 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
eg
{
"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 outpower 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
If propagated spectrum has mixed rates, then prints results (GSNR and OSNR)
for each propagated spectrum type according to its label.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ie2aff966e7324eb5fc3e58086e43dd39f73da8c8
- to create a reference channel based on SI
- to convert from to watt, mW, dBm, power spectral density ...
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I9b9684c1ad096aa54d01ef3f0242ecd2dcae79aa
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
I think that gnpy/core/equipment.py should contain only stuff which
prepares the equipment_config, not anything "lower level" that is reused
from other places.
Change-Id: I0cd593fd3e5558178ddd0ad8fff5c596e022894a
I decided to keep it around because I know that some people would like
to see those nanometers. Let's make sure it works.
Change-Id: Ib279cc8380a77f478da7a2bbc1e045a718446404
Given that everything else just uses these constants as imported from
numpy, there's no point keeping these wrappers around.
Change-Id: I0e19e05f40dc79d8005e915cf3ffb5e36328421a
This might have nothing to do with the ITU frequency grid (it's really
just about a uniform distribution), so let's give it a more readable
name and more readable parameters.
This looks like the root cause of bug #243, the default values suggested
that this function works in THz.
These defaults are not used anywhere, so let's get rid of something
which adds no value and actively confuses people.
-add f_min & f_max frequency definition in amplifier json
-improve interpolation algorithm to support length differences between the spectrum information and the amplifier ripple and dgt frequency definition
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
-Promote incremental and iterative network design
-Automatic saving of a "network-name_auto_design.json" file
-Results of the autodesign (additional amplifiers, configuration) are
saved to this ..._auto_design.json file
-This file can then be used to run a new simulation just like a normal
json input file
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
* automatic design (when amplifiers are missing from network topology
input) finds the optimum power difference between spans
* The range of this optimum power difference is defined in
eqpt_config[Spans][delta_power_range_db] = [min, max, step]
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
