Description
Using the Python wrapper (on a fairly recent dev branch), I noticed that even though I called Net.set_phase_test() on my Net object after creating it, it was still returning training results. To get the test ones, I needed to recreate the network another time.
After some investigation, it looks like that in the C++ API, phase is not a property of the Net object but one of a singleton object Caffe. In retrospect, it's not surprising: in order to create the Net, we need to know beforehand whether we'd like to see the test or the training version.
The main problem seems to be that we can only call set_phase()_ after having created a Net (unlike the C++ API, where we have access to the singleton even before any Nets get created).
Steps to reproduce:
- create a caffe.Net object, loading a model that is different for the train & test phases (e.g. different inputs, as in the example LeNet model)
- call set_phase_test() on the net
- forward()
- look at blobs in the net
(Somewhat naively) expected behavior:
- blobs contain test data / results
- the network architecture corresponds to the test phase ("we just made it so using set_phase_test()?")
Actual behavior:
- blobs contain training data / results
- the network architecture corresponds to the training phase
Workaround (I haven't found a simpler one yet; is there any?):
- create a Net object with any model
- call set_phase_test() on it
- delete this Net object and create the one we wanted to create in the first place
As a proposed solution, the set_phase_* methods could be moved to somewhere else, just like in C++, both to make the expected order of calls (first set phase, then create net) more obvious and to make it possible to set phase before creating Nets. Or... what do you think?