fix a little bug about resume

[kangkang59812]

When resuming, we need to start from the last epoch not 0.

[fmassa]

Thanks for the catch!

I have a question, let me know your thoughts.

Alternatively, one could also do something similar to the classification scripts, where we do

vision/references/classification/train.py

Line 209 in 5b1716a

for epoch in range(args.start_epoch, args.epochs):

and

vision/references/classification/train.py

Line 201 in 5b1716a

args.start_epoch = checkpoint['epoch'] + 1

, what are your thoughts on this?

[fmassa]

Just double-checking: should this be lr_scheduler.last_epoch or lr_scheduler.last_epoch + 1?

[kangkang59812]

I have the same idea with you at first, but I think this style is more simple and make less parameter to set. Most importantly, others won't make a mistake about which epoch to resume because the last epoch is kept by lr_scheduler(And we don't need to consider if we set a wrong start epoch that will overwrite the checkpoint). Maybe you have to save epoch in checkpoint and need to check the value before resuming. This simple way make you only need to set the checkpoint model. For your convenience in merge, I will submit the second one for chosing.
As for lr_scheduler.last_epoch or lr_scheduler.last_epoch + 1, I have checked and it's the lr_scheduler.last_epoch. The first time that scheduler.step() runs, last_epoch is set to 1. For example, if the program breaks at epoch 3 [200/2000], we should start from last_epoch=3(0,1,2 epoch have been run).
Thanks!

[fmassa]

Thanks!