Telecominfraproject / oopt-gnpy

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

RamanFiber: no gain ripple from pump spacing #398

Open jktjkt opened 3 years ago

jktjkt commented 3 years ago

Here's what @cgkelly wrote in https://github.com/Telecominfraproject/oopt-gnpy/issues/282#issuecomment-839816140 :

I have tried the Raman simulation by defining a RamanFiber span, and defining the Raman pump powers and frequencies. I get the expected Raman gain, but I do not see any gain ripple due to the spacing of the Raman pumps. (I'm not seeing any gain ripple in general, but this is a broader topic even for EDFA only spans that I'm looking into).

jktjkt commented 3 years ago

@AndreaDAmico , can you please take a look at this?

AndreaDAmico commented 3 years ago

@cgkelly, The implementation of the Raman solver should provide an accurate profile of the power evolution at any position of the fiber span. This profile is based on the shape of the Raman coefficients for the specific fiber and, in general, depends on the pump frequencies and powers and on the propagated spectrum. Can you share more details of your simulation? In any case, if the result is not what you would expect, you can try to change the space resolution and the tolerance within the simulation parameters regarding the Raman solver.

cgkelly commented 3 years ago

I may have been wrong.

When running the example file raman_edfa_example_network.json, with the Raman pump/power levels defined to represent one of our Raman amps, the reported channel powers, although high, do show ripple that roughly aligns with the expected ripple. As well, the effective Raman gain also aligns well with expected. (This gain is inferred from the following EDFA gain). (One possible bug detailed below).

My problem seems to be two-fold: a) What is the location of the reported channel power levels? In the above example, I’m assuming it is at the input of the post-Raman EDFA. However, I cannot find any documentation that states this.

In my 2 span ROADM network with Raman, the channel powers seem to correspond to the output of the ROADM into the ROADM egress amplifier. However, point b) below, this does not seem to be the case when I attempt to ask for the channel power levels at all EDFAs.

b) I want to see the per channel power levels into all EDFAs, but there does not seem to be a straightforward way to do this.

With some suggestions from Esther, I modified the cli_examples.py file, around line 237:

       for elem in path:
            print(elem.name)
            if (hasattr(elem,'effective_gain')):  # Amplifier
                print(vars(elem))
                print('{:>16}{:>16}'.format('Channel(THz)','Power (dBm)'))
                for carrier in infos.carriers:
                    ch_freq=carrier.frequency*1e-12
                    ch_power=lin2db(carrier.power.signal*1e3)
                    print('{:>16}{:>16}'.format(round(ch_freq,2),round(ch_power, 2)))

I do get detailed information about the per amp parameters, and confirmed proper .dvt defined gain ripple with tilt, for example (from the gain profile data), but it appears the ch_power data I am getting does not correspond to the per amp (element) power levels. Without being a python expert, or well versed in the code in general, I’m at a loss on how to obtain the per channel power levels at the amps. However, this information would be very useful for troubleshooting.

In the end, I can only estimate the gain ripple by looking at the per path OSNR. I do see OSNR ripple that does approximately correspond to the pump locations.

Also not clear to me – with detailed Raman simulations, does GNPY also simulate SRS induced gain tilt? I assume it must, in order to properly model pump-pump interactions. (I’m assuming, however, that fiber loss/km wavelength dependency is not yet defined).

Potential Bug?:

When running with a RamanFiber and the Raman pumps defined, due to the expected Raman gain, I am using a lower gain EDFA. GNPY seems to be evaluating the required EDFA gain before taking the Raman gain into consideration, resulting in an erroneous warning message:

There are 96 channels propagating Power mode is set to False => it can be modified in eqpt_config.json - Span [1;31;40mWARNING[0m: WARNING: effective gain in Node west edfa in I1 is above user specified amplifier AWBILA_LG max flat gain: 16dB ; required gain: 24.299999999999997dB. Please check amplifier type. [1;31;40mWARNING[0m: WARNING: effective gain in Node Edfa_preamp_roadm R2_from_fiber (I1 → R2)- is above user specified amplifier AWBING_LG max flat gain: 17dB ; required gain: 24.5dB. Please check amplifier type.

However, in this case, the actual “AWBILA” EDFA gain is subsequently set to 12.8 dB (expected), not the above required gain estimate of 24.5 dB.

Regards, Colin

From: Jan Kundrát @.> Sent: Sunday, May 16, 2021 1:28 PM To: Telecominfraproject/oopt-gnpy @.> Cc: Kelly, Colin (Nokia - CA/Ottawa) @.>; Mention @.> Subject: Re: [Telecominfraproject/oopt-gnpy] RamanFiber: no gain ripple from pump spacing (#398)

@AndreaDAmicohttps://github.com/AndreaDAmico , can you please take a look at this?

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

ojnas commented 3 years ago

@cgkelly, I'll try to answer some of your questions:

What is the location of the reported channel power levels?

When using transmission_main_example (and gnpy.app as well) channel power levels are reported as seen by the final transceivers. For raman_edfa_example_network.json this means it is at the output of the post-Raman EDFA.

In my 2 span ROADM network with Raman, the channel powers seem to correspond to the output of the ROADM into the ROADM egress amplifier.

Yes, it is at the output of the ROADM but I'm not sure what you mean by "ROADM egress amplifier" in this case. I assume the final Roadm element is connected directly to the Transceiver element so the signal will not pass through any egress amplifier. Since the Roadm element performs channel equalization the reported power levels will all be equal so in most cases this information will not be very interesting (the reason why you see a ripple with raman_edfa_example_network.json is that this example topology doesn't include any ROADMs).

I want to see the per channel power levels into all EDFAs, but there does not seem to be a straightforward way to do this.

No, currently there isn't but I agree it would be a nice feature to have. I think the problem is mainly how to present this in a clear way in a pure text-based interface (I have some idea how to do it in gnpy.app but I didn't have time to implement it yet).

With some suggestions from Esther, I modified the cli_examples.py file (...) but it appears the ch_power data I am getting does not correspond to the per amp (element) power levels.

No, this does not work since infos.carriers is never updated inside the outer for loop so you will just print the same information (at the ROADM output) multiple times. You could try to put your inner for loop inside the for loop in the propagate function in request.py instead (but replace infos.carriers with si.carriers).

Also not clear to me – with detailed Raman simulations, does GNPY also simulate SRS induced gain tilt? I assume it must, in order to properly model pump-pump interactions. (I’m assuming, however, that fiber loss/km wavelength dependency is not yet defined).

I'll leave this for @AndreaDAmico to answer.

Potential Bug?

Yes, I think what you describe could be considered a bug. The problem is that the GNPy auto-design feature is completely unaware of Raman gain. In your case, since you specify the EDFA type, this just results in a false warning which you can ignore. A bigger problem is that if you don't specify the EDFA type, auto-design will pick a type with higher gain than necessary. We should change this behaviour somehow.

AndreaDAmico commented 3 years ago

Also not clear to me – with detailed Raman simulations, does GNPY also simulate SRS induced gain tilt? I assume it must, in order to properly model pump-pump interactions. (I’m assuming, however, that fiber loss/km wavelength dependency is not yet defined).

I'll leave this for @AndreaDAmico to answer.

In the current version, using the RamanFiber you will obtain the entire SRS profile, including the induced gain tilt and, if provided, the fiber loss/km wavelength dependency.

ojnas commented 3 years ago

@cgkelly, here is a version of request.py that will print per channel power levels before and after every EDFA. Unzip it and replace the existing file in the gnpy/topology folder.

request.zip

cgkelly commented 3 years ago

Thankyou!

From: Jonas Mårtensson @.> Sent: Thursday, May 20, 2021 2:11 PM To: Telecominfraproject/oopt-gnpy @.> Cc: Kelly, Colin (Nokia - CA/Ottawa) @.>; Mention @.> Subject: Re: [Telecominfraproject/oopt-gnpy] RamanFiber: no gain ripple from pump spacing (#398)

@cgkellyhttps://github.com/cgkelly, here is a version of request.py that will print per channel power levels before and after every EDFA. Unzip it and replace the existing file in the gnpy/topology folder.

request.ziphttps://github.com/Telecominfraproject/oopt-gnpy/files/6517643/request.zip

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

ojnas commented 3 years ago

@cgkelly, now you can also get a plot of the spectrum after each element in gnpy.app.

cgkelly commented 3 years ago

Hi Andrea,

You mention that the fiber’s wavelength loss/km, if provided, is included if using RamanFibers. However, how is this specified? There is nothing I can find in the documentation.

Thanks, Colin

From: AndreaDAmico @.> Sent: Wednesday, May 19, 2021 8:03 AM To: Telecominfraproject/oopt-gnpy @.> Cc: Kelly, Colin (Nokia - CA/Ottawa) @.>; Mention @.> Subject: Re: [Telecominfraproject/oopt-gnpy] RamanFiber: no gain ripple from pump spacing (#398)

Also not clear to me – with detailed Raman simulations, does GNPY also simulate SRS induced gain tilt? I assume it must, in order to properly model pump-pump interactions. (I’m assuming, however, that fiber loss/km wavelength dependency is not yet defined).

I'll leave this for @AndreaDAmicohttps://github.com/AndreaDAmico to answer.

In the current version, using the RamanFiber you will obtain the entire SRS profile, including the induced gain tilt and, if provided, the fiber loss/km wavelength dependency.

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

AndreaDAmico commented 3 years ago

@cgkelly , you can specify the loss/km wavelength dependency using the loss_coef field within the parameters of the fiber. In particular, this parameter can be defined as a dictionary that includes two specific keys, loss_coef_power and frequency, containing as values a loss coefficient array and the relative frequency array, respectively.

ojnas commented 3 years ago

@AndreaDAmico, specifying wavelength dependent loss in this way does not really work in the latest release or with the code in the current master. There are a number of issues, which I think you have fixed in the new (still to be merged) patch series.

@cgkelly, for now you can test this functionality in gnpy.app if you want. As Andrea explained, instead of defining loss_coef as a scalar value, you can define it for a RamanFiber in the topology file like this:

"loss_coef":  {
    "frequency": [191.3e12, 195.1e12],
    "loss_coef_power": [0.208, 0.2]
}

This example only has two frequencies and loss values but you can specify any frequencies and loss values you want and the code will interpolate in between.

@jktjkt, @EstherLerouzic, @AndreaDAmico, since wavelength dependent loss seems to be a highly requested feature (see e.g. #318 in addition to this issue), would it make sense to break out these relatively simple fixes and merge them earlier? Or do you think this is unnecessary work and it's better to wait until the whole new patch series is ready?