Raman amp losses

[cgkelly]

The "detailed" Raman amplifier, defined by using the Raman pump powers/frequencies, does not have an obvious method to include post pump losses that determine the net gain instead of just the on-off gain. Thus, the resulting power levels into the following EDFA are too high, ie. they don't reflect the loss of the passive components within the Raman amplifier.

I thought about using the conn. out loss to accomplish this, but for EDFAs, this loss represents the connector (or patch panel) loss between the fiber plant and the EDFA input. For a Raman amplifier, this loss, if the same, should affect the pump powers into the fiber, and thus the Raman on-off gain.

[email protected] suggested that the Raman gain may not be affected by this conn. loss, in which case the conn. loss could be used to represent the Raman output losses. However, would represent a change in definition of the meaning of this loss. Furthermore, if the pump powers are not adjusted by the patch panel losses, the user has to adjust the pump powers to include any expected patch panel losses. I think a better approach would be to have the Raman pump powers adjusted by the conn. loss and have an extra parameter to capture the Raman to EDFA losses. (The pump powers need to be attenuated by the conn. loss, and the Raman amplified signal powers need to be attenuated by both the Raman to EDFA losses as well as the conn. loss).

[jktjkt]

I wonder what input files are being used here -- in the current master, there's that "faux raman" amplifier which is emulated via a possibly negative NF. You are definitely not using this one because you mention specifying actual pumps. So it might refer to the RamanFiber with some raman_pumps set. I understand that thing as a "magic way of injecting some pump power in" because there is no tangible element apart from the Fiber (well, Raman Fiber). There is no reference to the equipment library (as we do with regular EDFAs). So, in case of a RamanFiber, I would expect all the pump power insertion losses to be already accounted for when one sets the pump frequency and power, and for the RamanFiber's conn_in and conn_out to only affect the signal, not the Raman pump power.

Can you describe the input data that you're using, and what you think should be the correct behavior?

[ojnas]

Let me try to illustrate where potential confusion may arise. With a standard Fiber element we have this:

Fiber -> connectors (patch panel) -> EDFA

The Fiber con_out, as specified in the topology file, here represents the loss of the connectors (patch panel). With a RamanFiber element, what we are trying to model is this:

RamanFiber -> connectors (patch panel) -> "Raman box" -> connectors -> EDFA

The "Raman box" here contains the pumps as well as combiners and other required components that also introduce loss. Since con_out represents the loss of the connectors following the fiber in the standard case, the same could be expected to be true for the RamanFiber, in which case con_out would also attenuate the pump powers. In addition, there are now additional lossy components inside the "Raman box" as well as between this and the EDFA.

I don't have a strong opinion on whether we should try to modify the code according to @cgkelly's proposal. But if we keep the code as is, we could at least try to make it clear in the documentation that con_out has slightly different interpretations for Fiber vs. RamanFiber (where for RamanFiber it would represent loss of combiners, etc. + the connectors between the "Raman box" and the EDFA) and that any Raman pump power losses introduced by the connectors (patch panel) after the RamanFiber must by manually accounted for when setting the pump power levels.

[cgkelly]

Hi Jonas, I was thinking of having the Raman pump power profile (and of course wavelengths) predefined for the Raman amp type (# pumps) and fiber type, and have the Raman gain determined by the fiber plant conditions (loss/km, connector loss). However, I realized this won’t work well as the power ratios between the pumps are dependent on the achieved or target gain. This means that while the approximate pump powers may be known before-hand, they are usually adjusted by the Raman vendors software (with calibration tables). This means the detailed simulations are perhaps useful for emulating the Raman gain ripple or NF vs wavelength for a predetermined fiber and connector loss, but most system vendors already have tools for design purposes. Thus, I think the current implementation for detailed analysis is OK: The defined pump powers are the powers launched into the network fiber (ie after the conn. loss), and this means the connector loss could be repurposed to represent any Raman to EDFA component insertion losses. As well, when I tried using the detailed Raman on a 5 span network, GNPY slowed down considerable, and thus trying to use the detailed Raman amp model for simulation of a 2000km LH network, for example, is not practical. This also means for practical simulations, the use of a black box representation of the Raman (ie EDFA model with a low NF) should suffice. For this, it would be very convenient if the combination of a counter-propagating Raman and following EDFA could somehow be captured, at least in the excel topology input, on a single line, instead of having to define additional nodes /links. (I have not looked into how to define such a cascade yet, so let me know if I’m wrong here). There are a couple of implications in using this black-box approach: a) For SRS simulations, my understanding is we still need to define the fibers as Raman fibers. (Does this work without any specified Raman pump powers/frequencies? I have not tried this, but will). However, I suspect this will still result in a significant speed hit. Thus, it may be useful to use a heuristic algorithm to estimate the SRS induced tilt, based on full load assumptions b) The impact of Raman gain on nonlinear calculations (Leff) should somehow be captured, if detailed Raman calculations are not used. This also highlights the limitation of using an EDFA model to represent the Raman, as for proper nonlinear calculations, the core has to know the black box amp model represents a Raman amp, not an EDFA. Thanks, Colin From: Jonas Mårtensson ***@***.***> Sent: Monday, May 31, 2021 6:10 PM To: Telecominfraproject/oopt-gnpy ***@***.***> Cc: Kelly, Colin (Nokia - CA/Ottawa) ***@***.***>; Mention ***@***.***> Subject: Re: [Telecominfraproject/oopt-gnpy] Raman amp losses (#403) Let me try to illustrate where potential confusion may arise. With a standard Fiber element we have this: Fiber -> connectors (patch panel) -> EDFA The Fiber con_out, as specified in the topology file, here represents the loss of the connectors (patch panel). With a RamanFiber element, what we are trying to model is this: RamanFiber -> connectors (patch panel) -> "Raman box" -> connectors -> EDFA The "Raman box" here contains the pumps as well as combiners and other required components that also introduce loss. Since con_out represents the loss of the connectors following the fiber in the standard case, the same could be expected to be true for the RamanFiber, in which case con_out would also attenuate the pump powers. In addition, there are now additional lossy components inside the "Raman box" as well as between this and the EDFA. I don't have a strong opinion on whether we should try to modify the code according to @cgkelly<https://github.com/cgkelly>'s proposal. But if we keep the code as is, we could at least try to make it clear in the documentation that con_out has slightly different interpretations for Fiber vs. RamanFiber (where for RamanFiber it would represent loss of combiners, etc. + the connectors between the "Raman box" and the EDFA) and that any Raman pump power losses introduced by the connectors (patch panel) after the RamanFiber must by manually accounted for when setting the pump power levels. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#403 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ATEPR43EG6SHBVOP4HLIA7LTQP3KZANCNFSM453KGMVQ>.