Fiber latency evaluated during propagation. The speed of ligth in fiber is evaluated as the vacuum speed of ligth divided by the core reflective index n1.
The latency in the transceiver is evaluated in ms.
Change-Id: I7a3638c49f346aecaf1d4897cecf96d345fdb26c
In previous version, the lumped losses where not included in the fiber loss, creating an inaccurate overall power balance.
Change-Id: I98a4d37b9cc0526218fe3c6f2b9318b6fa797901
PEP 484 says that `float` also implicitly allows `int`, so there's no
need to use `Union[int | float]`.
Fixes: #450
Change-Id: Ib1aeda4c13ffabd47719c1e0886e9ebcf21a64e0
in case parameters are not correct, catch the ParameterError
and raises it again with the uid of the ROADM to ease debug
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I1f85f0e9e9226fc613d35611774c739adb2104c7
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
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
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
Move the docs to a place where that variable is declared, not to the
place where it's computed.
Co-authored-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-id: I17dff12c1e81827dfb4be869e59c9be85797dba4
The idea behind this change is to reproduce the exact same behaviour as
with the scalar, but accounting for variable levels of powers.
- delete the neq_ch: equivalent channel count in dB because with mixed
rates and power such a value has limited utility
- instead creates a vector that records the 'user defined' distribution
of power.
This vector is used as a reference for channel equalization out of the
ROADM. If target_power_per_channel has some channels power above
input power, then the whole target is reduced.
For example, if user specifies delta_pdb_per_channel:
freq1: 1dB, freq2: 3dB, freq3: -3dB, and target is -20dBm out of the
ROADM, then the target power for each channel uses the specified
delta_pdb_per_channel.
target_power_per_channel[f1, f2, f3] = -19, -17, -23
However if input_signal = -23, -16, -26, then the target can not be
applied, because -23 < -19dBm and -26 < -23dBm, and a reduction must be
applied (ROADM can not amplify).
Then the target is only applied to signals whose power is above the
threshold. others are left unchanged and unequalized.
the new target is [-23, -17, -26]
and the attenuation to apply is [-23, -16, -26] - [-23, -17, -26] = [0, 1, 0]
Important note:
This changes the previous behaviour that equalized all identical channels
based on the one that had the min power !!
TODO: in coming refactor where transmission and design will be properly
separated, the initial behaviour may be set again as a design choice.
This change corresponds to a discussion held during coders call. Please look at this document for
a reference: https://telecominfraproject.atlassian.net/wiki/spaces/OOPT/pages/669679645/PSE+Meeting+Minutes
- in amplifier: the saturation is computed based on this vector
delta_pdb_per_channel, instead of the nb of channels.
The target of the future refactor will be to use the effective
carrier's power. I prefer to have this first step, because this is
how it is implemented today (ie based on the noiseless reference),
and I would like first to add more behaviour tests before doing
this refactor (would it be needed).
- in spectralInfo class, change pref to a Pref object to enable both
p_span0 and p_spani to be conveyed during propagation of
spectral_information in elements. No refactor of them at this point.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I591027cdd08e89098330c7d77d6f50212f4d4724
Previous check was made on reference channel computation.
Now we use the actual total input power to compute the actual gain.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I3e0db72fdb030a49e2b06cdcfb442b5e642c1777
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
The lumped losses are used in the computation of the loss/gain profile
through the fiber whether the Raman effect is considered or not. The
computed power profile is used to calculate the related NLI impairment.
Using the 'gn_model_analytic' method, the lumped losses are taken into
account as the contribution of an additional total loss at the end of
the fiber span. In case the 'ggn_spectrally_separated' is selected, the
method uses the computed power profile according to the specified z and
frequency arrays. The lumped losses are so considered within the NLI
power evolution along the fiber.
Change-Id: I73a6baa321aca4d041cafa180f47afed824ce267
Signed-off-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
* changes:
Add PMD and PDL in amplifiers
Introduce PDL accumulation and penalty calculation
Calculate CD and PMD penalty
Set PMD for ROADMs in OpenROADM eqpt_config according to MSA spec
Fix formatting of OpenROADM eqpt files
The recent commit 77925b2 removed the to_json method from RamanFiber
class, which means that operational parameters (temperature and
raman_pumps) were not included when converting a topology to json and
saving it. This patch restores it.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: Icbea349c1ffaa2f216533b84c8edf5c8b59765f9
Both PMD and PDL is set to 0 by default. Values from the OpenROADM MSA
for ILAs are included in corresponding eqpt files.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I79611db3ae798e9dadc47ee39161dc1e242f2595
This fixes#421
As a first step PDL is specified in the eqpt library for ROADMs only.
In a later step, PDL (as well as PMD) should be specified also for amps
and possibly for fibers. PDL values from the OpenROADM MSA for ROADMs
are included in the corresponding eqpt files.
The acculumation rule for PDL is the same as for PMD as shown in:
"The statistics of polarization-dependent loss in optical communication
systems", A. Mecozzi and M. Shtaif, IEEE Photon. Technol. Lett., vol.
14, pp. 313-315, Mar 2002.
PDL penalty is specified and calculated in the same way as for CD and
PMD, i.e. linear interpolation between impairment_value/penalty_value
pairs. This patch includes penalty specification for OpenROADM trx
modes according to the MSA.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: Ib0ab383bcaee7d7523ffc3fa9a949d76c8c86ff7
The penalties are calculated and presented separately from the GSNR.
They are also taken into account when optimizing trx mode and verifying
path feasibility in path_requests_run processing.
Penalties are specified in the eqpt_config file as part of trx modes.
This patch includes specifications for OpenROADM trx modes.
Penalties are defined by a list of
impairment_value/penalty_value pairs, for example:
"penalties": [
{
"chromatic_dispersion": 4e3,
"penalty_value": 0
},
{
"chromatic_dispersion": 18e3,
"penalty_value": 0.5
},
{
"pmd": 10,
"penalty_value": 0
},
{
"pmd": 30,
"penalty_value": 0.5
}
]
- Between given pairs, penalty is linearly interpolated.
- Below min and above max up_to_boundary, transmission is considered
not feasible.
This is in line with how penalties are specified in OpenROADM and
compatible with specifications from most other organizations and
vendors.
The implementation makes it easy to add other penalties (PDL, etc.) in
the future.
The input format is flexible such that it can easily be extended to
accept combined penalty entries (e.g. CD and PMD) in the future.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I3745eba48ca60c0e4c904839a99b59104eae9216
In this change, the RamanSolver is completely restructured in order to obtain a simplified and faster solution of the Raman equation. Additionally, the inter-channel Raman effect can be evaluated also in the standard fiber, when no Raman pumping is present. The same is true for the GGN model.
The Raman pump parameter pumps_loss_coef has been removed as it was not used. The loss coefficient value evaluated at the pump frequency can be included within the fiber loss_coef parameter.
This change induces variations in some expected test results as the Raman profile solution is calculated by a completely distinct algorithm. Nevertheless, these variations are negligible being lower than 0.1dB.
Change-Id: Iaa40fbb23c555571497e1ff3bf19dbcbfcadf96b
Modification of the Fiber and the NliSolver in order to properly propagate the new definition of the spectral information taking advantage of the numpy array structures.
In the previous version, the propagation of the spectral information was implemented by means of for cycles over each channel, in turn.
In this change the propagation is applied directly on the newly defined spectral information attributes as numpy arrays.
Additional changes:
- Simplification of the FiberParameters and the NliParameters;
- Previous issues regarding the loss_coef definition along the frequency are solved;
- New test in test_science_utils.py verifing that the fiber propagation provides the correct values in case of a few cases of flex grid spectra.
Change-Id: Id71f36effba35fc3ed4bbf2481a3cf6566ccb51c
Squeeze function has been replaced by asarray. Using 'get' function
instead of if condition for the dictionaries. Frequency reference
derived from wavelength reference of 1550 nm.
Change-Id: I815ad8591c9e238f3fc9322ca0946ea469ff448f
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
On certain values of loss_coef, the computation loss_coef * 1e-3 * 1e3
results in x.0000000000000000y values:
eg if 0.21 is provided in the topology file, then parameters.FiberParams
changes this to _loss_coef = 0.00021
and elements.Fiber.to_json prints 0.21000000000000002
This is a normal floating point behaviour, but is rather confusing.
In order to remove this unwanted decimal, I propose to round the printings
in to_json
https://docs.python.org/3/tutorial/floatingpoint.html
The change also add this round for gain, because in power mode
the gain is computed based on loss and loss may have this floating value.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ib3287a794e7da985eabf0af914c0e1ef4914e857
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)
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
We ship "some" DGT values which effectively mask this, but it's possible
to provide a "trivial" DGT vector such as [0, 0]. When that happens, the
code was failing with a numpy-level warning related to a division by
zero.
The code tried to be ready for this by trying to catch an exception, but
this relied on a particular numpy behavior upon zero division which was
not set up properly. For the added fun, there are two possible cases of
division by zero:
- on a zero tilt, it's a case of `0.0 / np.float64(0.)`, which is
controlled via "invalid",
- on a non-zero tilt, it's a case of `<float> / np.float64(0.)`, which
leads to "divide".
Let's just check for zero instead of wrestling exceptions.
Change-Id: I7a3c0b6b9b85e90a8a7201b7c7a56a5a44c27d69
I dig through the git log, and it looks like something which was never
used after some refactorings 3+ years ago.
Change-Id: I3633a59d8f2720932fa32c885ee5be643e640a46
The __str__ method of the Fiber element class rounded the fiber length
to an integer but then formatted it with two decimal places, which
doesn't make sense. With this patch, two decimal places are kept.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I03b886dff7ba624929ccc85b4d77d8d6a7cbcfb4
The NF calculated by the preamp model is compliant with the MW-MW noise
mask in the OpenROADM MSA spec. The booster is noise-free, which is
modeled by setting the NF to zero (-inf in dB units). This is obviously
unphysical but it is the simplest way to model the total noise
contribution from a ROADM, including preamp and booster, that is
compliant with the the OpenROADM MSA.
This also introduces two new EDFA type varieties,
"openroadm_mw_mw_preamp" and "openroadm_mw_mw_booster" in the equipment
library. I would prefer to also change the names of the existing
"openroadm" type_def and "standard"/"low_noise" type_variety,
representing an OpenROADM inline-amplifier, for better consistency but
this probably needs to be discussed first.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I7344ff53623f166649efb389c95c04ff92718e35
Signed-off-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
Co-authored-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
As pointed out in GitHub issue #390, the normal convention for the sign
of amplifier tilt is to define it with regard to wavelength, i.e.
negative tilt means lower gain for longer wavelengths (lower
frequencies). Currently GNPy uses the opposite convention, which this
patch proposes to change.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I8f7829a3b0b0b710f7da013c525630a60b22a2b5
Currently the tilt_target defined by a user is applied over the band of
propagating channels. This means for example that if only two channels
are propagated, the difference in gain between the two channels will be
equal to the tilt_target, independently of how close the two channels
are in frequency. I think it makes more sense to always define the
tilt_target over the full operational bandwidth of the amplifier.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I4f29de2edc4d0de239b34e0d8d678d964b6a0af3
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
When loading the equipment file in json_io.py we should raise an error
if an Edfa type_variety specifies a NF type_def that is not
implemented. This should also allow to remove the assert statement in
the _nf method in the Edfa class.
Change-Id: Ida0bb19829c0ee54ecbe3e2f74ea7c22eb24f6a2
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Currently, the RamanFiber class does not implement its own to_json
method but inherits it from the parent Fiber class. This means that
operational parameters (temperature and raman_pumps) are not included
(and therefore not picked up by the network_to_json method in
json_io.py). So if a user saves the topology, e.g. using the
--save-network option, and later uses that saved topology as input,
the result will be wrong.
This patch includes the operational parameters in to_json.
Change-Id: I07c09a4d122858ff412373623d8c0a087a3e11ec
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
