Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing default type_variety Attribute in eqpt_config.json for ROADM #519

Open
MirkoZETA opened this issue Oct 26, 2024 · 2 comments
Open

Comments

@MirkoZETA
Copy link

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:

  1. Define a ROADM in your network topology without including the type_variety attribute, as shown below:
          ...other devices...

  {
      "uid": "roadm_source_1",
      "type": "Roadm",
      "params": {
        "target_pch_out_db": -20,
        "restrictions": {
          "preamp_variety_list": [],
          "booster_variety_list": []
        },
        "per_degree_pch_out_db": {}
      },
      "metadata": {
        "location": {
          "latitude": 0,
          "longitude": 0,
          "city": "source site",
          "region": null
      }
    }
  },

          ...other devices...
  1. Run gnpy-transmission-example with this topology configuration.
  2. 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:

From:

  "Roadm": [
    {
      "target_pch_out_db": -20,
      "add_drop_osnr": 38,
      "pmd": 0,
      "pdl": 0,
      "restrictions": {
        "preamp_variety_list": [],
        "booster_variety_list": []
      }
    },
              ...other ROADMs (that specify type_variety)...
  ]

To:

  "Roadm": [
    {
      "type_variety": "default",
      "target_pch_out_db": -20,
      "add_drop_osnr": 38,
      "pmd": 0,
      "pdl": 0,
      "restrictions": {
        "preamp_variety_list": [],
        "booster_variety_list": []
      }
    },

              ...other ROADMs (that specify type_variety)...
  ]
@EstherLerouzic
Copy link
Collaborator

Dear @MirkoZETA,

Thank you for your comments!

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.

Does this make sense to you?

@MirkoZETA
Copy link
Author

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:

  "Roadm": [
    {
      "target_pch_out_db": -20,
      "add_drop_osnr": 38,
      "pmd": 0,
      "pdl": 0,
      "restrictions": {
        "preamp_variety_list": [],
        "booster_variety_list": []
      }
    },

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?

Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants