You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the Bug
When the type_variety attribute of a ROADM is not specified in the topology file, executing gnpy-transmission-example results in the following warning: WARNING missing type_variety attribute in eqpt_config.json[Roadm]
To Reproduce
Steps to reproduce the behavior:
Define a ROADM in your network topology without including the type_variety attribute, as shown below:
Run gnpy-transmission-example with this topology configuration.
Note: When using this topology in the GNPY online app, this warning does not occur, likely because the default value for type_variety is set.
Expected behavior
The ROADM definition in eqpt_config.json should default to a type_variety value when none is specified, similar to other devices. Currently, a warning appears, indicating that no default value is applied. I’m unsure if type_variety should always be defined explicitly for this specific device, but other devices seem to handle defaults without issue. Manually adding the type_variety field resolves this problem.
Workaround
To resolve this warning, modify eqpt_config.json to include the type_variety: "default" field as follows:
With the release of v2.10, the library now supports multiple types of ROADMs, making the type_variety attribute mandatory for differentiating between them. This change addresses users accustomed to previous versions, where only one ROADM type was available and type_variety was not required.
The warning serves as a prompt for users to include the type_variety in their ROADM definitions, ensuring compatibility with the new feature.
Hello @EstherLerouzic, thanks for the reply!
Your explanation makes sense. However, when using the GNPY online app, this warning doesn't occur, likely because a default type_variety value is set. If that's the case, the provided example in eqpt_config.json should be modified to include the type_variety: "default" field, particularly in the first entry of the Roadm field, which currently looks like this:
It's important to address this because when using the web app, users don't know which ROADM is being used. This makes it difficult to replicate results locally. Even when exporting the network, the type_variety field is missing, so the specific ROADM used in the web app remains unknown.
It's a minor detail, but this discrepancy between the online app and local implementation kept me puzzled for a while.
Additionally, if I'm not mistaken, multiple Transceivers are supported and the type_variety field is optional for them. Why is there a different behavior for ROADMs?
Description of the Bug
When the
type_variety
attribute of a ROADM is not specified in the topology file, executinggnpy-transmission-example
results in the following warning:WARNING missing type_variety attribute in eqpt_config.json[Roadm]
To Reproduce
Steps to reproduce the behavior:
type_variety
attribute, as shown below:gnpy-transmission-example
with this topology configuration.type_variety
is set.Expected behavior
The ROADM definition in
eqpt_config.json
should default to atype_variety
value when none is specified, similar to other devices. Currently, a warning appears, indicating that no default value is applied. I’m unsure iftype_variety
should always be defined explicitly for this specific device, but other devices seem to handle defaults without issue. Manually adding thetype_variety
field resolves this problem.Workaround
To resolve this warning, modify
eqpt_config.json
to include thetype_variety: "default"
field as follows:From:
To:
The text was updated successfully, but these errors were encountered: