Unsure how to figure out where backprop fails

George3d6: <p>So, maybe a silly question, but I’ve stumbled upon a problem where backprop seems to “fail” for part of my forward. i.e. part of my nn.Module <code>.parameters()</code> never get changes when I call <code>.step()</code></p>
<p>The exact loop I have here is something like:</p>
<pre><code class="lang-auto">    def forward(self, input_arr):
        # self.encoders is an nn.ModuleList
        
        stacked_inputs = []
        for k in range(len(input_arr[0])):
            stacked_inputs.append([])
            for i in range(len(input_arr)):
                stacked_inputs[k].append(input_arr[i][k])

        for i in range(len(stacked_inputs)):
            stacked_inputs[i] = torch.stack(stacked_inputs[i])
        
        # I assume the actual issue starts here
        k = 0
        X = torch.zeros(len(input_arr),self.input_size)
        for i in range(len(stacked_inputs)):
            input = stacked_inputs[i]
            if i in self.encoder_indexes:
                input = self.encoders[k](input)
                k += 1
            X[:,self.input_indexes[i][0]:self.input_indexes[i][1]] = input

        X = X.to(self.device)

        output = self._foward_net(X)
        return output
</code></pre>
<p>And I’m curios where the problem could be arrising here, however, I’m curios, in the more general scenario, what would be the way to go about debugging something like this to begin with ?</p>

ayalaa2: <p>So in general, if we perform a loss function on the output of a model, we would expect that any module (parameters) that the input came across would receive a gradient. If we’re finding that some of your parameters are not being given a gradient (thus not changing after a step), then they must not be affecting the output.</p>
<p>It’s possible that some parameters <em>are</em> being used, but are perfect such that their gradient is 0. But I’m going to assume that this isn’t the case.</p>
<p>Is the <code>len(input)</code> suppose to be at least <code>k</code>? I notice that if <code>input</code> isn’t long enough, some encoders in your module list might not be accessed. I would print out <code>k</code> here and assure that all your encoders are being touched. Otherwise it appears to me that the data is flowing correctly.</p>
<p>Something else you can do is iterate over the encoders and make sure that their gradients are not None and have non-zero values in them. It could be that some gradients are so small that they’re appearing to not be changing (but they are).</p>

George3d6: <p>I altered the function in order to be more readable and support batching, so I made some edits, but the issue/problem stays the same.</p>
<p>The input is always long enough and I did check, the forward method of the <code>encoder</code> Modules is being ran.</p>
<blockquote>
<p>Something else you can do is iterate over the encoders and make sure that their gradients are not None and have non-zero values in them. It could be that some gradients are so small that they’re appearing to not be changing (but they are).</p>
</blockquote>
<p>This is what I might try next, good point, I will come back with updates either way.</p>
<p>Thanks a lot for the help <img src="https://discuss.pytorch.org/images/emoji/apple/slight_smile.png?v=12" title=":slight_smile:" class="emoji" alt=":slight_smile:" loading="lazy" width="20" height="20"></p>
<p>Edit: I am pretty sure I found the issue and it’s related to me using a <code>register_forward_hook</code> in order to extract the outputs from the <code>encoder</code> nn.Module instead of just taking a slice of the model and running backprop as usual. Will change and see if that works. Preemtive sorry in case this was a red hering.</p>

George3d6: <p>Alright, so the issue was indeed that the <code>forward</code> method of one of the underlying <code>nn.Module</code> objects was not working, my bad.</p>
<p>Thanks for the advice <a href="https://discuss.pytorch.org/u/ayalaa2">ayalaa2</a></p>
<p>If anyone has inputs on the other part of the question (is there an easy way to debug this kind of thing, or at least a hard way, but a hard way that can systematically point me to the exact line where the flow stops), I’d still love to hear it, as I’ll be facing these kinds of issues a lot in the future.</p>