JRGit4UE

A possible workaround *seems* to be **partial tracing** of the BatchNorm2d layer: ` self.bn = torch.jit.trace(nn.BatchNorm2d(100, affine=False), example_inputs=torch.rand(2, 100, 2, 2))` where example_inputs are of shape `(2, num_features, 2, 2)`...

Although the simple workaround example above seems to work, it leads to incomplete results.. : / May someone deeper inside batch normalization figure out a proper solution..

@TobyRoseman Thanx for your suggestion, I have traced the model and got the warning `TracerWarning: Converting a tensor to a Python integer might cause the trace to be incorrect. We...

In version 5.2.0 the issue still exists. May I suggest to adjust the coremltools documentation to be make clear - it is not production ready code - as the documentation...

The issue seems to be a **bias** set as **Optional** which asserts in CoreMLTools **converter.py**. ` node.output.type== Optional[Tensor] 19 defined in (%19 : Tensor? = prim::GetAttr[name="bias"](%17) ` Here is the...

The workaround seems to be to define loop_count as `loop_count:int=0 ` before it is used ..

Any comments? Have I got something completely wrong? Is it a possible bug? Why does the context of the **forward(x)** node not contain the **self.attribute1** value?? Is there a way...

Thank you for your hint, I will check how far I can get with it. > Is there are reason you need to use a PyTorch script rather than a...

@glenntu 👍 simple change, great result - thanksalot

@belkahorry actually I refused to create a docker image on my own and preferred to wait for an update from nvidia