Telecominfraproject / oopt-gnpy

Optical Route Planning Library, Based on a Gaussian Noise Model
http://telecominfraproject.com
BSD 3-Clause "New" or "Revised" License
198 stars 87 forks source link

.dgt vector not properly read or interpolated #397

Closed cgkelly closed 3 years ago

cgkelly commented 3 years ago

I have defined .dgt vectors for the advanced edfa models, and also assigned non-zero gain tilts. I expected the gain ripple to translate into OSNR ripple at the output of a path, but did not see any ripple.

With some help from Esther, I added some lines to cli-examples.py to attempt to debug this (is there a better way to get more information about gain/OSNR evolution along a path, for such debugging purposes? )

around line 238, after 'for elem in path:', added if (hasattr(elem,'effective_gain')):
print(vars(elem))

I used the hasattr to check if the element is an amp, to avoid an excessive data dump. The result shows that the GNPY used .dgt vector starts with a very similar (but not exact) value to the first one defined in my .dgt vector, but the remaining values did not vary much, and did not reflect my .dgt vector.

Going through the closed issues, it appears there was an issue in interpolation when freq. was defined in THz instead of Hz (or vice versa); my amp models have start/stop freq's in Hz, and so does the SI data in my eqpt_config file, so it appears this is correct. Comparison graph attached.

defined vs GNPY used .dgt vectors.pptx

ojnas commented 3 years ago

Is it the interpol_dgt vector you are looking at? With start/stop freq you are referring to f_min/f_max in the advanced amp config file? It sounds like an interpolation issue but it is difficult to say without more info. Would it be possible to share input files for which this happens so that I can try to reproduce the issue?

cgkelly commented 3 years ago

Update - this appears to be resolved by removing fmin, fmax from the amplifier.json files.

ojnas commented 3 years ago

@cgkelly, removing f_min and f_max is not really a solution since then it will just use 191.35 THz and 196.1 THz by default (which may or may not match your defined DGT values). There must be some error in how you define these values in the json file. If you could just copy and paste that part of the file here I could maybe identify the issue.

cgkelly commented 3 years ago

I had fmin, fmax defined in both the SI section of the eqpt_config.json file:

"SI": [ { "f_min": 191300000000000, "baud_rate": 32000000000, "f_max": 196100000000000,

And in the amp .json files:

"nf_fit_coeff": [ -0.0030742, 0.0032491, -0.10437, 4.6595 ], "f_min": 191300000000000, "f_max": 1961000000000000,

(with the nf ripple, gain ripple, dvt vectors following).

Eliminating the two highlighted entries (per amp json file) solve the problem. Thus, it does appear to be related to the old (closed) issue with regard to interpolation problems.

Thanks, Colin From: Jonas Mårtensson @.> Sent: Wednesday, May 12, 2021 1:47 PM To: Telecominfraproject/oopt-gnpy @.> Cc: Kelly, Colin (Nokia - CA/Ottawa) @.>; State change @.> Subject: Re: [Telecominfraproject/oopt-gnpy] .dgt vector not properly read or interpolated (#397)

Is it the interpol_dgt vector you are looking at? With start/stop freq you are referring to f_min/f_max in the advanced amp config file? It sounds like an interpolation issue but it is difficult to say without more info. Would it be possible to share input files for which this happens so that I can try to reproduce the issue?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/Telecominfraproject/oopt-gnpy/issues/397#issuecomment-839933507, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATEPR47W7RHRBJ3LA2BDARDTNKWH3ANCNFSM44YY25KA.

cgkelly commented 3 years ago

Yes, thanks - I realize the limitation of this approach, but I had aligned my .dgt frequencies with the SI grid via matlab. I should reopen the issue, however, as it isn’t resolved.

Colin

From: Jonas Mårtensson @.> Sent: Wednesday, May 12, 2021 1:54 PM To: Telecominfraproject/oopt-gnpy @.> Cc: Kelly, Colin (Nokia - CA/Ottawa) @.>; Mention @.> Subject: Re: [Telecominfraproject/oopt-gnpy] .dgt vector not properly read or interpolated (#397)

@cgkellyhttps://github.com/cgkelly, removing f_min and f_max is not really a solution since then it will just use 191.35 THz and 196.1 THz by default (which may or may not match your defined DGT values). There must be some error in how you define these values in the json file. If you could just copy and paste that part of the file here I could maybe identify the issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Telecominfraproject/oopt-gnpy/issues/397#issuecomment-839938235, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATEPR46236TNOT7ARBQYS63TNKXDTANCNFSM44YY25KA.

ojnas commented 3 years ago

Looks like f_max has one 0 to many in your amp json file. That would explain why the interpolated values look wrong.

ojnas commented 3 years ago

@cgkelly, see reply above

cgkelly commented 3 years ago

Thanks for the catch...obvious now.

Colin

From: Jonas Mårtensson @.> Sent: Wednesday, May 12, 2021 2:05 PM To: Telecominfraproject/oopt-gnpy @.> Cc: Kelly, Colin (Nokia - CA/Ottawa) @.>; State change @.> Subject: Re: [Telecominfraproject/oopt-gnpy] .dgt vector not properly read or interpolated (#397)

Looks like f_max has one 0 to many in your amp json file. That would explain why the interpolated values look wrong.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/Telecominfraproject/oopt-gnpy/issues/397#issuecomment-839945047, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATEPR45KFBV2DJMUQYHIZGDTNKYKZANCNFSM44YY25KA.

jktjkt commented 3 years ago

I looked into how we could prevent a case like this in future. In the upcoming YANG work, the amplifier's f_min and f_max are range-limited, so you should hopefully get a helpful error message. Also, the DGT vector will be passed not as a "list of numbers", but rather as an explicit mapping from the frequency to the DGT value at that point -- and the frequencies will be range-checked.

So I think we'll be covered, and this one can be closed.