The Raman engine computes NLI just for a subset of channels; this is an
important speed optimization because the computation is rather CPU
heavy. However, the code just left NaNs in place for NLI of those
channels which were not explicitly simulated.
This is wrong because these NaNs propagate all the way to the total
input/output powers per the whole spectrum, etc, leading to NaNs being
shown to the user.
This patch uses a very simple linear approximation just in order to
prevent these NaNs.
fixes#288
Both of these places referred to "eq. 123 from arXiv:1209.0394", the
only difference (apart from the source of the input parameters, beta2
and asymptotic_length) was calling the two branches "SCI" and "XCI" vs.
"SPM" and "XPM".
In this commit I've only moved the code to a single implementation. The
input data are still being read from the same parameters, of course.
Conceptually, this is just about propagating the input parameters (which
drive the simulation) into all RamanFiber instances. The network module
already contains similar functions, let's move it there.
For some reason, the code allowed using "convenience names" for
accessing properties since commit 58ac717f. To me, this looks like an
obvious anti-pattern because accessing a single property via three
different names only makes the code less readable. Let's kill this
"feature".
In case of the `Power` class, the code used "ase" and "nli" on the
majority of places, so let's use these abbreviations instead of their
spelt-out variants.
SpectralInformation was "clean" already, but there were calls to the
`update()` wrapper around the `namedtuple._replace`. Given that there
were no property aliases, it's safe to just call `_replace()` directly.
In case of the `Pref` class, once again always use `p_span0`, `p_spani`
instead of `p0` and `pi` -- it's a trivial change.
Rather than do the None-dance and document the default value within a
docstring, let's use the default value directly. This is safe because
numbers are immutable.
Because default arguments are evaluated *once*, not every time they are
called, a mutable default value is not "reset", and this happens:
>>> from gnpy.core.node import Node
>>> x=Node('123')
>>> y=Node('456')
>>> print(x.metadata)
{'location': Location(latitude=0, longitude=0, city=None, region=None)}
>>> print(y.metadata)
{'location': Location(latitude=0, longitude=0, city=None, region=None)}
>>> y.metadata['foo']=123
>>> print(x.metadata)
{'location': Location(latitude=0, longitude=0, city=None, region=None), 'foo': 123}
This is easily fixable by using an immutable value as a placeholder
here.
This feature is intended to support designs such as OpenROADM where the
line degree integrates a specific preamp/booster pair. In that case, it
does not make sense for our autodesign to "pick an amplifier". The
restrictions can be activated by:
- Listing them in `eqpt_config.json`, so that they are effective for all
ROADM instances.
- On a per-ROADM basis within the Excel sheet or the JSON definitions.
Restrictions apply to an entire ROADM as a whole, not to the individual
degrees.
If a per-degree exception is needed, the amplifier of this degree can be
defined in the equipment sheet or in the network definition.
If no booster amplifier should be placed on a degree, use the `Fused`
node in place of an amplifier.
Signed-off-by: Esther Le Rouzic <esther.lerouzic@orange.com>
Co-authored-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
I have no idea which one of the existing pypi modules is best for these,
and given that we're using just two escape codes, I think it makes sense
not to bother with a more capable third-party module just for two magic
strings.
Once the actual config-parsing code start raising these exceptions
instead of directly calling sys.exit(), the user experience would
deteriorate due to raw exception traces. There's little value in the
trace itself, so just wrap the whole config loading with pretty error
formatting.
We still do not point to a specific place where that error is defined
(such as a line/column in a given JSON file) because that information is
already lost by the time we perform these checks.
Also, these checks are largely open-coded ad-hoc stuff. Some required
items are not covered, raising KeyError instead. We should get a formal
schema for these...
