Hi Xiaojun, I'm not actually sure that the training itself has crashed. I think that is what the end of the .STDERR file is supposed to look like. Do you have a .STDERR.digest file?
Are you running the EMS across a cluster? I've found that when running across our cluster, there's sometimes a delay in the .STDERR file being created by the queuing software at the completion of the step. When the EMS looks for the .STDERR file and doesn't find it, it assumes that the step crashed. I work around this problem by putting a sleeping loop at the beginning of check_if_crashed in experiment.perl: this loop is part of the Moses subversion repository as of revision 3420. Best, Suzy On 4/01/11 10:24 AM, Xiaojun Zhang wrote: > Dear all, > I am trying examples on Experiment Management System. Now I have some > problem during training: > * > step TRAINING:run-giza-inverse crashed > number of steps doable or running: 1* > > the last two lines of "*TRAINING_run-giza-inverse.4.STDERR*" are: > *Executing: rm -f > /Users/xiaojunzhang/Desktop/Moses/work2/training/giza-inverse.4/fr-en.A3.final.gz > Executing: gzip > /Users/xiaojunzhang/Desktop/Moses/work2/training/giza-inverse.4/fr-en.A3.final > * > I think the reason it crash is that, during the training, only > *fr-en.A3.final.gz* is generated, and there is actually no > *fr-en.A3.fina*l. So the ems crash when execute gzip. > I am using Mac OS with updated GIZA++ and Moses. It successes to run on > regular Moses step by step, while crashed in ems. > Could you please tell me why it happens? And what is the walk around? > > Best Regards > Xiaojun Zhang > > > > _______________________________________________ > Moses-support mailing list > [email protected] > http://mailman.mit.edu/mailman/listinfo/moses-support -- Suzy Howlett http://www.showlett.id.au/ _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
