--observations option continues looking in traindir/observations even after another observations folder is separately specified.
For example, specifying --observations=traindir_old/observations/ folder results in Segway looking at traindir_old/observations/float32.list for the list of windows, but looking in traindir/observations for the corresponding windows (which is of course wrong).
This results in the following GMTK error for all jobs:
#!python
BinaryFile::openSegment: Can't open '/mnt/work1/users/hoffmangroup/rachelc/2016/segway_appnote/minibatch/results/DOHH2_0.0001_1.traindir/observations/chr1.1574.float32' (in binary file '/mnt/work1/users/hoffmangroup/rachelc/2016/segway_appnote/minibatch/results_old/DOHH2_0.0001_1.traindir/observations/float32.list') for input
ERROR: FileSource::openSegment: failed to open segment 1574.
for all segment numbers.
To work around this, I created my traindir/observations folder before running Segway and moved my base observations folder into it and that seemed to be fine. But looking at the documentation (which suggests the ability to use the same external observations folder with multiple runs) this doesn't seem to be intended behavior--and if it is, should be clarified.
Original report (BitBucket issue) by Rachel Chan (Bitbucket: rcwchan).
--observations option continues looking in traindir/observations even after another observations folder is separately specified.
For example, specifying --observations=traindir_old/observations/ folder results in Segway looking at traindir_old/observations/float32.list for the list of windows, but looking in traindir/observations for the corresponding windows (which is of course wrong).
This results in the following GMTK error for all jobs:
for all segment numbers.
To work around this, I created my traindir/observations folder before running Segway and moved my base observations folder into it and that seemed to be fine. But looking at the documentation (which suggests the ability to use the same external observations folder with multiple runs) this doesn't seem to be intended behavior--and if it is, should be clarified.