oopt-gnpy
oopt-gnpy copied to clipboard
New printing is not equivalent as before in power sweep mode
Before #299 , printing after powersweep displayed OSNR and SNR in bandwidth and in 0.1nm. Now only prints SNR in bandwidth. I suggest to print again all previous values to keep the same level of information. Moreover final highlighted values should rather be the SNR in 0.1nm, because this is the value to be compared to the OSNR threshold of transceiver (it is always specified in 0.1nm) so instead of printing this: `` print(f' Final SNR total (signal bw): {ansi_escapes.cyan}{mean(destination.snr):.02f} dB{ansi_escapes.reset}')
``
I suggest to print the last element as it was before and replace snr by snr_01nm in the previous line
Moreover final highlighted values should rather be the SNR in 0.1nm, because this is the value to be compared to the OSNR threshold of transceiver (it is always specified in 0.1nm)
I agree, I also prefer SNR in 0.1nm.
I suggest to print the last element as it was before
Always doing that as well as printing a final highlighted value would result in this value being printed three times when not doing power sweep, which seems a bit much.
Indeed, I suggest to have last element print as before, only in this power sweep mode ! I can make a pr on that it this sounds good to you
Thanks, I did not know that the OSNR at 0.1nm is a better value of these two to report. I will push this one.
In general, though, I would prefer the "demo examples" to only print so much that people can follow their output. There's always the CSV output which is more suitable for extracting all the details for additional processing.
Just wondering -- if doing the power sweep, what is the value in seeing the final GSNR and the ASE contribution separately, and both of these two in 0.1nm and channel-bw?
Although called "examples", these programs are not only for demo and are used for studies. Power sweep is an advanced feature in my opinion to help a user tune the power. If you remove information from its output and force user to open a csv each time he does a propagation that's not easing his experience. OSNR and SNR values are useful to see NL penalty evolution, and 0.1 and bandwidth values to fairly compare values with two different baudrate. if I can have all this on my output running for several eqpt_config, I can easily analyse. If I have to open csv and save its content several times that's not easy for me. And I would like to reflect your question: what is the value of changing behaviours for which we had no issues ?
When I use "Transmission_main_example.py" to simulate some propagations, displayed informations such OSNR and gSNR in 0.1nm and optical signal bandwidth are very useful. If some users appreciate to open a CSV file to access these informations, it is another option, but it does not have to become the option. Also, it is important to keep the information we are talking about as they were previously displayed. I agree with Esther comments on this topic.
@EstherLerouzic wrote:
OSNR and SNR values are useful to see NL penalty evolution, and 0.1 and bandwidth values to fairly compare values with two different baudrate.
Thanks for your feedback, Esther. I'll take your word that all of these information should be displayed by default, then.
I would appreciate if you could clarify about the 0.1nm vs. bandwidth OSNR measurements, though. I currently do not understand why both are needed or how they help work with different modulation rates. Please feel free to say that this is "optics 101" if that's the case :).
And I would like to reflect your question: what is the value of changing behaviours for which we had no issues ?
The issue is "GNPy shows a wall of text as an output, making it hard to scan the result for 'that key metric' on which to judge the network layout". Perhaps the set of people that I demoed GNPy to is much less advanced compared to your colleagues, but the takeaway I got when demoing the example on, e.g., ECOC, was that it shows a ton of information. Also, nobody pointed it out to me that the GSNR value to be shown as a primary one should be @0.1nm, not for the signal bandwidth.
@bgwiader wrote:
When I use "Transmission_main_example.py" to simulate some propagations, displayed informations such OSNR and gSNR in 0.1nm and optical signal bandwidth are very useful. If some users appreciate to open a CSV file to access these informations, it is another option, but it does not have to become the option. Also, it is important to keep the information we are talking about as they were previously displayed. I agree with Esther comments on this topic.
Thanks for sharing your feedback as well, @bgwiader , I really appreciate hearing from our users!
Esther confirmed during today's call that it's indeed a use case for Orange to see both SNR-per-0.1nm and SNR-per-channel-bandwidth at the same time, so I'll be placing these back for the power sweep mode.
generally speaking:
- generalized SNR in 0.1nm is the most important value as stated above because it is an end result to be compared with the Required OSNR of the transponder, which is always given in 0.1nm. => this value provides the end to end path acceptation for a given transponder.
- generalized SNR in signal bandwidth is useful because it is the only value that can be compared between transponders with different baud rates. => this value gives insigth on the line performance, it should be roughly the same whatever the transponder used, providing they have been power optimized. Therefore it is also a very important information
- optical OSNR in 0.1nm when compared to the generalized SNR in 0.1nm gives information on the system non linearities; it is typically less than 2dB higher. => large or small differences give insight on whether the system is power limited, (very long spans for example) or badly optimized (too much lauunched power). It may also be used to compare with vendor tools results, as [unfortunately] the generalized SNR is not yet readily available from these proprietary tools. Hope this helps, regards