All other noise models set the `nf_def` variable, so let's make the YANG
code simpler by remembering the amplifier NF model like that.
Change-Id: I341e4ac296c25bf9f27a98a7e4e92e0fd1546021
Well, sleeping ain't fun. A red warning is plenty. In case of API
access, there's none, but that's just the APIs are.
Change-Id: I2fb0c051a9c3bb7f2ef2264083686e929c27ec2c
Fixes: 6a6591e4 (Add a warning message when attributes are missing in eqpt_config.json)
It was only assigned to in `read_service_sheet`, and it's safe to remove
it also in `convert_service_sheet`.
Change-Id: Ia832cd8fea2d864e920907e455e834a3c3a724dd
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>
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>
The equipment library has, so far, used completely different namespaces
for `Fiber` and `RamanFiber` definitions. It was possible to define a
"SSMF" fiber whose properties, such as CD or PMD, would differ when used
as a Fiber vs. the RamanFiber object in the networking topology. That is
likely a bug of the equipment library, so this patch makes sure that a
configuration like that cannot be used.
I came across this when working on the YANG support where both fiber
types are defined in a common namespace, and the difference between them
is determined by lack or presence of a sub-container with the Raman
properties.
Change-Id: I8e86bed80eb1794b8abd4e1ecd96398d395f81f2
A recent patch introduced the possibility to define an Edfa in the
topology file without specifying its type_variety:
https://review.gerrithub.io/c/Telecominfraproject/oopt-gnpy/+/488967
But with the current implementation, if a user specifies a type_variety
that is missing from the equipment configuration file (e.g. because of
a spelling mistake) this is silently ignored and the type_variety is
instead selected by auto design. I think this is not desired since it
can lead to confusing results. This patch proposes to raise an error
when the specified type_variety is missing while still allowing the user
to not specify type_variety or set type_variety = '' for selection by
auto design.
A recently introduced test actually does exactly this, i.e. it defines
Edfas with type_variety = 'std_high_gain' even though this type variety
does not exist in the equipment config file used by the test. Therefore
this patch also modifies the topology file used by that test.
Change-Id: I7d2a1aa6d633b62d51a99b07e8270cafcbad505f
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
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
There's no reason for this, in fact, the code got easier to read when
that detour to disk gets removed.
Change-Id: I45db215898da962e625a7fea6eda57744e21ff8a
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
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
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
