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
The option is only set for gnpy-transmission-main.
The spectrum file is a list of of spectrum objects, each defining
fmin, fmax and spectrum attributes using the same definition as SI
in eqpt_config.json. the object list should be contiguous spectrum
definitions and not overlapping. 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, th program justs uses
the index + baud rate of the spectrum bands as label.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ibc01e59e461e5e933e95d23dacbc5289e275ccf7
Flexgrid precision is 6.25GHz so --show-channels should be at least 5 digits
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I7de4254ab18508320133371e0d8cc8b5e08f0d2f
A new function is added to use requests specs based on transceivers
and on user definition of mixed rates and powers.
Propagation functions are changed so that, if the user defines a
specific distribution, then they use it else they use as before,
all identical channels based on the initial request. In this case,
as before this change, we assume full load, with same channel for
the spectral info and not the resulting mixt of channels after
routing.
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Icf56396837b77009e98accd27fcebd2dded6d112
This change siplifies the structure of the simulation parameters, removing the gnpy.science_utils.simulation layer, provides some documentation of the parameters and define a mock fixture for testing in safe mode
Change-Id: If5ef341e0585586127d5dae3f39dca2c232236f1
For this commit only the first element from the {N, M} list is read
and assigned.
This is better than not reading this value at all.
the commit also updates test_files and test data files with correct
values for the effective_freq_slot attribute
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I1e60fe833ca1092b40de27c8cbfb13083810414e
We have a test which compares the raw output of GNPy against a fixed
expected output. That comparison of course chokes when forward slashes
and backslashes are used, which breaks the test suite on Windows. Let's
try to solve this by always using forward slashes if possible. The way
to go is via pathlib's as_posix(), but that one can possibly return an
absolute path -- which cannot work in a test suite, obviously. So one
can workaround that via calling a Path.relative_to(), but that one
chokes on paths which require at least one "path up" component (`..`).
I posted a patch which use brute force here, but Jonas is right, better
just don't print that output in the test suite in the first place.
Change-Id: I762ddb58a2042120c7b20414152a06a3ed72048d
Bug: https://github.com/Telecominfraproject/oopt-gnpy/issues/358
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
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>
ParametersError is a sub class of ConfigurationError so the
corresponding except clause should be placed before. Otherwise the
ConfigurationError will be matched first instead of the more specific
ParametersError.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I67156dd7321101693fdf061d77937d4e75462593
Since 30234f913c, the code just added the
"system margins" to each transponder's minimal required OSNR. That's
simple and straightforward, but I think that mutating "equipment
library" in response to a "global simulation parameter" is not really
the right way to go.
Make this explicit; always check the resulting OSNR against the
transponder's minimum plus the margin.
I got into this when checking the fixups that are performed within the
JSON loader. I don't think that the JSON loader is an appropriate place
for this.
Change-Id: Ic8f8385cbbb29dc0d769462f17caad47c2b36940
Since build_network can raise NetworkTopologyError and
ConfigurationError we should handle these in cli_examples instead of
crashing.
Change-Id: I4b84831c74be7f1c88253c938f3f67b2d204630e
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
There are two propagation functions in request.py, propagate and
propagate2. The propagate2 function saves and returns spectral infos
from before and after every element of the path. In most cases only the
final spectral info after propagation is needed (there is currently
nothing in the code using anything more). On the other hand, the
propagate function just returns the path which is unnecessary since that
is modified in place. This patch proposes to instead return the final
spectral info from the propagate function.
Since propagate2 is now redundant, it can be removed.
Change-Id: I3a0f7310a7d5f9c93dc5f257e051c7d45e20c6fe
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
This is effectively a revert of commit 771af49 which added a
commented-out feature for printing out carrier info of the first hop.
On one hand, I'm reluctant to remove this, because apparently this was
not added by an accident, the PR #193 explicitly speaks about a
suggestion from Dave Boertjes for this feature -- and the git history
with merges looks like this one was actually pulled in as a single
commit. On the other hand, it is apparently not used anywhere, and all
of the required information is already available in some other manner --
for example, one can easily follow the path and add these prints to the
propagation, or just walk the path manually.
Digging further, I removed some of similar print() statements in
acafc78, and then restored some commented-out print()s via ec9eb8d (also
see the discussion in #299), which were then removed by Esther in
8107dde. So my TL;DR version is that this is dead code, and that
apparently the *real* use case is having total insight into the spectrum
info along the path (e.g., #246). That should, IMHO, be handled by
proper processing of the resulting data in a nice UI.
Change-Id: I366d33f98e230f4cb60a6d4b791707f7604f8d65
This is a feature that was requested by Esther due to their workflows at
Orange. There's also a standalone converter avaialable as
`gnpy-convert-xls`.
Change-Id: I1a483d168db0744fbf115e05e679e13b57d79398
There's no need to limit this to just the transmission_main_example, so
let's unify this handling.
Change-Id: I585f407c7f80da12fd33baf7261c35c736d78df2
I think this is a little bit cleaner that duplicating the info about the
default for some of these options.
Change-Id: If218a26ede3e71628f4839b4e505c4f4aa217699
Let's use the --option format instead of positional arguments; that way
it's more obvious that it can be omitted. Note that this constitutes a
change of behavior for the path_requests_run example.
Change-Id: Ic6653cf419e1a8573c3585190a88fc51500f549d
Try to indicate whether an option takes just JSON, or a JSON or an XLS
file. Also add some extra descriptions.
Change-Id: Ifb81d46f6ac659da79b08201a414822e9c318a1e
We talked about this earlier today on a call, and agreed with Esther and
Alessio that this is probably a relict from the past. The file does not
appear to contain much useful information, anyway, so let's try to
remove it and wait if someone complains.
Change-Id: I215eeb37498b28b15ece2300f4bbdd184ac52f4a
This is something which got added in bc9eee32, but it never got
finalized to have a user-visible effect. To the best of my knowledge, it
only created a file which was never used.
I removed code which created that file in 0d542f22, so let's clean up
the rest.
I think this should also restore functionality of running convert.py in
a standalone mode. Looking at the ArgParser, the invocation never
considered the names_matching parameter.
Change-Id: Id0f4aa1db2d22233f74fb273176168a16ace4072
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
It's a bad habit to write files into the source code repository. It will
also become impossible if gnpy is installed into a systemwide, possible
read-only location.
The old behavior can be reactivated by using an extra option to tell
GNPy where to put the generated file.
Change-Id: I9ad43890ca5886f516885de5938a4778870a06c5
The main reason for doing this is becasue of the next commit which
re-adds testing of the generated wrappers.
Change-Id: I7137c6cf7a5b414fc708a15b125eaf88e996366c
...which will be done in the next commit. One has to be careful with
sys.argv here because it uses different indexing than when passing args
explicitly.
Change-Id: I53833a5513abae0abd57065a49c0f357890e0820
This converts our first free-standing example entry point into a
function. It will become very handy when we start distributing these
entry points via setuptools.
Change-Id: Icd2e4658337f93cd0b0301978e2dc640de0cc72b
This also moves SimParams handling to a single place. As a result,
path_requests_run has just become Raman-aware (to the minimal possible
extent, OK).
Change-Id: I4e31af5c67335963ddab567d304f48a899cd569e
