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
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
Update the program because the same Path_request class is called
that now includes this bidir field
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
As agreed upon during today's coders call, this is something that is
needed by actual users in the field, so let's prioritize their needs
over clarity of output for demo purposes.
Esther and Jonas pointed out that it is much more common to work with
OSNR measurements per 0.1nm rather than per signal bandwidth. This is in
line with what OSAs usually report and what transponder datasheets
specify.
cc #307
Various presentations from Polito are slowly changing to use "GSNR" as a
"Generalized SNR", but it's true that our code does not use this term
anywhere, and that it is not properly explained. Let's wait a bit for
this term to become a bit more mainstream and for updated docs on our
side; then this commit can be safely reverted.
Thanks to Jonas for reporting this.
I think that this SNR value represents the most important output of this
example. There's plenty of debugging info on display already, so let's
make this one more prominent.
I was thinking about moving the highlighting to elements' each __str__()
function, but that felt a bit like layering violation to me. I could
have also changed just the transponder's __str__(). In the end, I think
that repeating just the final GSNR at the link-end transponder makes
most sense here. This is aligned with what we talked about at
yesterday's (on 2019-09-18 -- note that this is a backport from #261)
demo for Microsoft, after all.
This is inspired by #293. The original issue was that the transponder
OSNR was not accounted for. Rather than making the propagate() and
propagate2() more complex, let's move the actual path printing to the
demo code. There's no secret sauce in there, it's just a simple
for-each-print thingy, so let's remove it from the library code.
fixes#262
- Avoid recalculating SNRs in transmission main example since they are already calculated and stored in the Transceiver class
- Also include per channel power (useful for checking tilt) and OSNR ASE in the output
As Jonas pointed out, the code used to contain a check for non-nan
values, effectively skipping channels where the Raman gain was not
explicitly computed.
Now that we do not introduce NaNs into some channels anymore, this
shortcut no longer works. We could either add explicit filtering for
only showing those channels which are covered by the Raman engine, but
then the result would be rather confusing in the non-Raman case. One
could also add another column with the simulated vs. approximated NLI,
but when I tried this, the output looked a bit cluttered.
I think that the best course of action for now is to just show info
about all channels (if asked by the user). So this is just a cleanup for
a condition which is now always on.
There were just these substantial differences:
- the Raman code showed a per-channel SNR summary, this is now
controlled via the `--show-channels` option
- when a Raman fiber is used the `--sim` option for specifying input
simulation parameters is now mandatory
I'm therefore merging these two files even though we've rpeviously
decided not to do this -- consult the review comment at
https://github.com/Telecominfraproject/oopt-gnpy/pull/263#discussion_r310506082
and the discussion during this Tuesday's coders call). If this turns out
to be a problem for autodesign, we can always revert this.
One possible catch is that the final "SNR total" shows NaN for the
default Raman example. That's just the way the simulation engine works
right now, I'm afraid. The `--show-channels` options helps a lot.
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...
save and be able to retrieve the carrier information processed by Edfa
and Fiber elements:
@ input & output of the element
- channel power: ase, nli, signal and total
Signed-off-by: Jean-Luc Auge <jeanluc.auge@orange.com>
adding the counting feature on standard output
adding tsp nb in csv + small bug fixes
small fixes to improve stdout and csv printing
small bug fixes on service aggregation and automatic correction of names
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
