CTC loss produced 'Nan' when using spatial features from AlexNet

thxkew: <p>I applied CTC loss for the continuous sign-language recognition task. I use the model architecture proposed in <a href="http://www.cihancamgoz.com/pub/camgoz2017iccv.pdf" rel="nofollow noopener"> SubUNets</a>.</p>
<p>I used ResNet18 for the CNN model to spatial feature extraction. There’s no problem here but ResNet18 consumes very high memory.</p>
<p>So, I changed The CNN model to be AlexNet for lighter weight.</p>
<p>but when I use AlexNet for the spatial feature extraction model, after few epochs the CTC loss function produced ‘Nan’ value.</p>
<p>I’m not sure where the problem is due to I used the same parameter in both models.<br>
only one part that two models are different is a model part.<br>
please check my code for both models.</p>
<p>this is code for AlexNet</p>
<pre><code class="lang-auto">class CnnEncode(nn.Module):
    def __init__(self, cnn_embed_dim=128, hidden = (128,128,128), drop_p=0.3):
        super(CnnEncode, self).__init__()

        self.cnn_embed_dim = cnn_embed_dim
        self.h1 , self.h2, self.h3 = hidden
        self.drop_p = drop_p
        
        alexnet = models.alexnet(pretrained=False)
        alexnet.features[0] = nn.Conv2d(1, 64, kernel_size=(11, 11), stride=(4, 4), padding=(2, 2))
        modules = [list(alexnet.children())[0]] + [list(alexnet.children())[1]]
        self.alexnet = nn.Sequential(*modules)
        
    def forward(self, x_3d):
        cnn_embed_seq = []
        print(x_3d.shape)
        for t in range(x_3d.size(1)):
            
            x = x_3d[:, t, :, :,:].to(device=device)
            x = F.relu(self.alexnet(x))
            x = x.view(x.size(0), -1)
            x = x.to(device=cpu)

            cnn_embed_seq.append(x)
            
        cnn_embed_seq = torch.stack(cnn_embed_seq, dim=2)
        x = cnn_embed_seq.permute(2,0,1)
        return x
</code></pre>
<p>this is code for ResNet18</p>
<pre><code class="lang-auto">class CnnEncode(nn.Module):
    def __init__(self, cnn_embed_dim=128, hidden = (128,128,128), drop_p=0.3):
        super(CnnEncode, self).__init__()

        self.cnn_embed_dim = cnn_embed_dim
        self.h1 , self.h2, self.h3 = hidden
        self.drop_p = drop_p
       
        resnet = models.resnet18(pretrained=False)
        resnet.conv1 = nn.Conv2d(1, 64, kernel_size=7, stride=2, padding=3, bias=False)
        modules = list(resnet.children())[:-1] #delete the last fc layer.
        self.resnet = nn.Sequential(*modules)
        
    def forward(self, x_3d):
        cnn_embed_seq = []
        print(x_3d.shape)
        for t in range(x_3d.size(1)):
            
            x = x_3d[:, t, :, :,:].to(device=device)
            x = F.relu(self.resnet(x))
            x = x.view(x.size(0), -1)
            x = x.to(device=cpu)
            cnn_embed_seq.append(x)
            
        cnn_embed_seq = torch.stack(cnn_embed_seq, dim=2)

        x = cnn_embed_seq.permute(2,0,1)
        return x
</code></pre>

ptrblck: <p><a href="https://discuss.pytorch.org/t/ctcloss-predicts-blanks-after-a-few-batches/40190/4">This post</a> suggests to use <code>zero_infinity</code>. Could you use it, if not already done, and check the targets for all blanks?</p>

tom: <p><a class="mention" href="/u/ptrblck">@ptrblck</a> 's suggestion probably is the first important thing to look out for. If that is the cause, it means that for some of your data, the output length of your AlexNet is insufficient to be able to produce the target sequence.</p>
<p>If that doesn’t help in itself:</p>
<ul>
<li>Be sure to use the latest PyTorch version.</li>
<li>If you want to find out what is going on,  you can do the following:
<ul>
<li>at the end of each training step (after optimizer.step()) can you check if any weight has a NaN,</li>
<li>look at the last inputs into CTC loss when a weight turned NaN (which means that the gradient was NaN).</li>
<li>does it happen for CPU as well?</li>
</ul>
</li>
</ul>
<p>Note that you need to check the weights for NaN, not the loss. Very likely the gradients  go NaN first and you’ll see the loss turn NaN in the next iter.</p>
<p>Things to look out for:</p>
<ul>
<li>targets must not contain blank.</li>
<li>input length should be larger than target length + number of repeat positions (+1? I can’t remember).</li>
</ul>
<p>Best regards</p>
<p>Thomas</p>

thxkew: <aside class="quote no-group" data-username="tom" data-post="3" data-topic="85248" data-full="true">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/tom/48/3162_2.png" class="avatar"> tom:</div>
<blockquote>
<p><a class="mention" href="/u/ptrblck">@ptrblck</a> 's suggestion probably is the first important thing to look out for. If that is the cause, it means that for some of your data, the output length of your AlexNet is insufficient to be able to produce the target sequence.</p>
<p>If that doesn’t help in itself:</p>
<ul>
<li>Be sure to use the latest PyTorch version.</li>
<li>If you want to find out what is going on,  you can do the following:
<ul>
<li>at the end of each training step (after optimizer.step()) can you check if any weight has a NaN,</li>
<li>look at the last inputs into CTC loss when a weight turned NaN (which means that the gradient was NaN).</li>
<li>does it happen for CPU as well?</li>
</ul>
</li>
</ul>
<p>Note that you need to check the weights for NaN, not the loss. Very likely the gradients  go NaN first and you’ll see the loss turn NaN in the next iter.</p>
<p>Things to look out for:</p>
<ul>
<li>targets must not contain blank.</li>
<li>input length should be larger than target length + number of repeat positions (+1? I can’t remember).</li>
</ul>
<p>Best regards</p>
<p>Thomas</p>
</blockquote>
</aside>
<p>sorry for the late reply, I have used zero_infinity = True but it didn’t solve the problem.</p>
<p>I found that when I use batch size is 1 there’s no problem, but when I use batch size more than 1 it always produces ‘NaN’ in weight and loss output when training passed few iterations.</p>
<p>so I think it possible that the problem occurs due to padding.</p>
<p>I padded the sequence of video input to have the length as the maximum input length in mini-batch with the last frame.</p>
<p>and I padded target to have the length as the maximum target length in mini-batch with ‘blank’.</p>
<p>I would like to ask you about my padding method is it the correct way ?.</p>
<p>the input length look like</p>
<blockquote>
<p>[150 246 220 120]<br>
(each element is the length of each input in batch, in this case, use batch size is 4)</p>
</blockquote>
<p>the target look like</p>
<blockquote>
<p>[[1 30 4 3 14 1 0 0 0 0]<br>
[1 2 5 29 3 14 30 2 4 1]<br>
[1 5 3 7 1 0 0 0 0 0]<br>
[1 29 3 1 0 0 0 0 0 0 0]]<br>
(padded 'blank ’ to have the length as the maximum target length in mini-batch)</p>
</blockquote>
<p>and target length look like</p>
<blockquote>
<p>[6 10 5 4]</p>
</blockquote>

raraz15: <aside class="quote no-group" data-username="thxkew" data-post="5" data-topic="85248">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/thxkew/48/51780_2.png" class="avatar"> thxkew:</div>
<blockquote>
<p>and I padded target to have the length as the maximum target length in mini-batch with ‘blank’.</p>
</blockquote>
</aside>
<p>I do not know if padding the targets create a problem for sure, but you can surely provide the targets as a 1D sequence to CTCLoss</p>

Peppa-Peddler: <p><a class="mention" href="/u/thxkew">@thxkew</a> Having the same problem. Were you able to solve it?</p>