Thanks for reporting, it looks like the discrepancy was due to a fix for Sequential module being skipped by torch in scope recording, will need to investigate.

# Run this without patching numerical atom `_unqualified_variable_name`
class MainModule(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.module_list = torch.nn.ModuleList(
            [torch.nn.Linear(10, 10) for _ in range(2)]
        )

    def forward(self, x):
        y = self.module_list[0](x)
        z = self.module_list[1](y)
        return z

module = MainModule()
print(module)
f = io.BytesIO()
torch.onnx.export(module, torch.randn(1, 10), f, verbose=True)
f.seek(0, 0)
onnx_model = onnx.load(f)
for node in onnx_model.graph.node:
    print(node.name)

/0/Gemm
/1/Gemm

where it should be

/module_list/0/Gemm
/module_list/1/Gemm

@BowenBao thanks for looking into this. I am getting the following output with this model you suggested:

/module_list.0/Gemm
/module_list.1/Gemm

I tested intel-isl/MiDaS model from torch.hub where I can also see onnx node names incorrect.

module = torch.hub.load("intel-isl/MiDaS:f28885af", "MiDaS_small")
input = torch.randn(1, 3, 320, 640)

All onnx node names are missing /pretrained prefixes where it should be there. For example, I am seeing /layer3/layer3.1/layer3.1.0/conv_pw/Conv instead of /pretrained/layer3/layer3.1/layer3.1.0/conv_pw/Conv. Here model.pretrained.layer3 is a Sequential module.

@kevalmorabia97 thanks for providing another great example. I took another look and it turns out pytorch populates scope name at _slow_forward method, which is invoked by forward method, in nn.Module class. Hence that's why my simple example above doesn't capture the Sequential module name, as its forward was not invoked.

This is also the reason why pretrained is not appearing for intel-isl/MiDaS, if I'm looking at the correct code
https://github.com/isl-org/MiDaS/blob/master/midas/midas_net.py#L59-L62.

A more precise solution is probably to store the full qualified name of modules as scope name, instead of relying on the pytorch scope tree structure. However, it may have implications on other components.

Thanks @BowenBao for the explanation.

Do you have any rough estimate on how much effort is required in the fix and whether it could make it in the next release? I find pytorch scope name to be super useful as it helps in mapping the onnx nodes with the pytorch modules providing insights at the pytorch module level.

I will bring this to the attention of our team. We need to figure if there is enough bandwidth.
Optimistically the improvement itself shouldn't require too much amount of work; we just need to make sure it doesn't break other stuff.

@BowenBao any updates on this?

@BowenBao any updates on this?

Could you retest this, please?

Still seeing same issue with torch 2.3.0 on the intel-isl/MiDaS model