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
