SSD(Single Shot MultiBox Detector)的solver参数 test_initialization的说明塈解决训练时一直停在Iteration 0的问题

前阵子训练过一次SSD模型，训练后发现数据集有问题，修改了数据集后，今天准备再做一次SSD训练时，如下执行训练代码：

python ./examples/ssd/ssd_pascal.py 

到了开始迭代时，一直停在Iteration 0,进行不下去。。。

对于还不完全熟悉SSD代码结构的我来说，遇到这个问题当时脑子一下子就懵了，一时不知是哪里出了问题。因为我之前已经成功做过一次训练，此次训练只是训练数据集不一样，并没对训练参数和模型做任何修改，怎么就不对了呢？

最后想到我在第一次训练的时候，修改过solver参数中的test_initialization的值(定义在$ssd_root/examples/ssd/ssd_pascal.py line 388)，会不会是它的问题呢？
于是尝试将之修改为默认值False，再开始训练，则一切正常。

原因分析

我们知道，训练过程一般都比较漫长，所以caffe在设计的时候允许中断训练，当Ctrl-c中断训练时，Caffe会自动保存一份训练快照。
如下图，会在$ssd_root/models对应模型文件夹下生成代表当前完成的迭代次数的快照文件，后缀为_32和_47的文件分别代表32次和47次迭代时的快照

solver参数中的test_initialization表示是否可以用上次保存的snapshot来继续训练，如果为True,则下次开始训练的时候，caffe会自动从这个目录下加载最近一次迭代的模型，继续训练，以节省时间。
如果是False，则会从0开始重新迭代。所以这个参数的默认值是False。 我在第一次训练的时候，将这个参数改为了True。
这样听起来没啥问题，但如果你重新开始训练的时候，$ssd_root/models对应模型的文件夹下并没有任何快照，如test_initialization被设置为True，因为caffe找不到快照文件，就会导致迭代一直停留在Iteration 0。所以这种情况下应该把test_initialization置为False，训练就能正常进行下去了。
根据这个现象，我觉得这应该是训练代码的一个bug,代码的健壮性有问题，但因为对Caffe代码结构还不熟悉，所以我是没办法修改它，期待官方版本改进。

参考资料

《Caffe代码解读(四):solver_param》