Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.dgt vector not properly read or interpolated #397

Closed
cgkelly opened this issue May 12, 2021 · 9 comments
Closed

.dgt vector not properly read or interpolated #397

cgkelly opened this issue May 12, 2021 · 9 comments

Comments

@cgkelly
Copy link

cgkelly commented May 12, 2021

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
Copy link
Contributor

ojnas commented May 12, 2021

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
Copy link
Author

cgkelly commented May 12, 2021

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

@cgkelly cgkelly closed this as completed May 12, 2021
@ojnas
Copy link
Contributor

ojnas commented May 12, 2021

@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
Copy link
Author

cgkelly commented May 12, 2021 via email

@cgkelly
Copy link
Author

cgkelly commented May 12, 2021 via email

@cgkelly cgkelly reopened this May 12, 2021
@ojnas
Copy link
Contributor

ojnas commented May 12, 2021

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

@ojnas
Copy link
Contributor

ojnas commented May 12, 2021

@cgkelly, see reply above

@cgkelly
Copy link
Author

cgkelly commented May 12, 2021 via email

@jktjkt
Copy link
Collaborator

jktjkt commented May 16, 2021

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.

@jktjkt jktjkt closed this as completed May 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants