Skip to content

Bugs found in NLI calculation, endpoints restrictions, single-channel EDFA, and gnpy-path-request spectrum handling #545

@Hamzegh

Description

@Hamzegh

Hi — thanks for the great project. I am Hamze Ghorbani Koujani and I’m using GNPy 2.13. I found a few issues that affect realistic multi-OLS/production use. It's likely that you have already encountered these bugs. I’ve listed each problem below with observed vs expected behavior and a suggested fix where applicable.


Environment

  • GNPy version: 2.13
  • Python version: 3.12.11

1) NLI computed using only signal power (mismatch with ROADM equalization and other elements workflow)

Observed:
The ROADM element equalizes total channel power (P_sig + P_ASE + P_NLI) to the configured per-channel target. However, in Fiber.propagate the NLI is computed and added at the fiber input via NliSolver.compute_nli(...) using only the signal power per channel (P_sig). As a result the NLI calculation ignores ASE + existing NLI that have already been added/equalized by upstream nodes, which leads to incorrect NLI accumulation when multiple OLSs are chained.

Expected:
NliSolver.compute_nli should consider the actual channel power entering the fiber, i.e. (P_channel = P_sig + P_ASE + P_NLI), when computing NLI contributions.

Suggested change:
Adjust SpectralInformation and differentiate between P_sig and P_channel, as almost all other elements are using (P_channel = P_sig + P_ASE + P_NLI). Or, adjust NliSolver.compute_nli(...) to derive the total channel power and use that as the power argument for NLI computation. This keeps NLI consistent with other elements especially ROADMs.


2) Sources/Destinations limited to TRXs (should allow ROADMs per TIP OOPT)

Observed:
Currently the GNPy API requires Source and Destination to be TRX objects. Per the TIP OOPT MUST Optical Whitepaper and O-OLS network definitions, it must be possible to set ROADMs as endpoints (source/destination) for path requests and simulations.

Expected:
GNPy should accept ROADMs as valid endpoints (in addition to TRXs), or clearly document the limitation and provide a conversion/helper to create the equivalent TRX endpoint when needed.

Suggested change:
Relax the endpoint validation or extend the model so ROADMs can be endpoints in path requests/simulations, or add a dummy transceiver. This enables modeling OLSs and inter-OLS behavior more faithfully.


3) Single-channel EDFA causes IndexError in Edfa.interpol_params

Observed:
In elements.py, class Edfa, method interpol_params assumes at least two channels and computes slot width as:

self.slot_width = self.channel_freq[1] - self.channel_freq[0]

With a single channel (len(self.channel_freq) == 1), accessing self.channel_freq[1] raises IndexError.

Expected:
GNPy should support single-channel operation (common in testing/provisioning) or at minimum raise a clear error with guidance.

4) (Optional) gnpy-path-request does not accept non-uniform --spectrum files

Observed:
gnpy-path-request evaluates performance under a full-load spectrum derived from transceiver type/mode/spacing but does not accept a non-uniform --spectrum file (i.e., custom per-channel frequency/width lists). It is possible to work around this by using the Python API, but the CLI does not accept non-uniform spectrum files directly.

Expected:
gnpy-path-request should accept a --spectrum file with arbitrary/non-uniform channel definitions, or provide a documented flag for custom spectra.

Suggested change:
Allow the CLI to import and honor non-uniform spectrum files (same format accepted by the Python API), or provide a clear CLI documented workaround.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions