FiberParams._init_ does not support 'loss_coef_value' key in loss_coef dictionary

[tttlz]

Describe the bug
FiberParams.init does not support the YANG model-defined 'loss_coef_value' key in loss_coef dictionary. When using a YANG-compliant loss_coef_per_frequency (frequency-dependent loss coefficient vector), it raises ParametersError claiming the 'value' field is missing.
According to the YANG model definition, fiber parameters should support two formats:
loss_coef (scalar, decimal64) - single scalar value
loss_coef_per_frequency (vector, list) - frequency-dependent vector, each element contains frequency and loss_coef_value
Currently, FiberParams.init only handles the loss_coef field (single value or a dictionary with 'value' and 'frequency' keys), and does not implement support for loss_coef_value.

To Reproduce
Steps to reproduce the behavior:

1. Create a YANG-compliant network topology JSON file with fiber elements using loss_coef_per_frequency format
2. Load the network topology using GNPy
3. The error occurs when FiberParams is initialized

Error Message
Simulation parameters error: Config error in fiber (...): Fiber configurations json must include 'value'. Configuration: {..., 'loss_coef': {'frequency': [196200000000000.0, 193400000000000.0, 191400000000000.0, 190900000000000.0, 187900000000000.0, 186150000000000.0], 'loss_coef_value': [0.25, 0.249, 0.248, 0.248, 0.249, 0.25]}, ...}

Environment:

• OS: Windows
• Python Version 3.12
• GNPyVersion 2.13

[EstherLerouzic]

Thanks for reporting this ... I am preparing the patch

[EstherLerouzic]

The internal model does not follow the yang: loss_coef can be a scalar or a dict. GNPy scripts do the conversion: if you enter data with a loss_coef_per_frequency, this will be converted into the loss_coeff dict with proper list of values. Now indeed if you try to init the FiberParam directly from the json, this does not work, because this conversion has not occurred.

Here is a schema to explain this:

[tttlz]

Thanks for the reply. I just tested with the legacy format, and it works.

Would GNPy consider changing the input format to match the YANG format?
I find the YANG model to be a very good reference for understanding the expected input structure and format. The mismatch may cause confusion.