-
Notifications
You must be signed in to change notification settings - Fork 96
Description
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.