[MITgcm-devel] complaint about testreport (o:

[Jean-Michel Campin]

Hi Martin,

OK, if the 'echo "NORMAL END"' hack works, I think it's better
than solution (1) where none of the test checks for a normal end
(which was what was threre before my modif). 
Ideally, I would prefer to stay with NORMAL END, because it's
the last instruction to be executed (i.e., STOP).
But we can see later if this needs to be changed.

I have an other request: Would you be ready to check-in 
somewhere in the CVS repository (either in tool/example_scripts
or in the MITgcm_contrib/test_scripts, as you prefer) the scripts 
that you are using for all the testing you are running ?
It might help (others) to build automatic test on 
other platforms, and this way I may know in advance 
the next time I will break your testing :-)

Cheers,
Jean-Michel

On Tue, Sep 05, 2006 at 05:59:10PM +0200, Martin Losch wrote:
> Hi Jean-Michel,
> 
> can't you check for something else? Something that is always written  
> to STDOUT, such as things from the last lines of output:
> >(PID.TID 0000.0001) //      Max. barrier spins =              1
> >(PID.TID 0000.0001) //      Min. barrier spins =              1
> >(PID.TID 0000.0001) //     Total barrier spins =      196590768
> >(PID.TID 0000.0001) //      Avg. barrier spins =       1.00E+00
> ??
> 
> Other than that, your suggested hack works (echo "NORMAL END" >> {the  
> right path/}run.log), although I am not happy with that, because even  
> if the model does not end properly, run.log contains a NORMAL END,  
> although it shouldn't ...
> 
> On Sep 5, 2006, at 4:59 PM, Jean-Michel Campin wrote:
> 
> >Hi Martin,
> >
> >This need to be fixed.
> >The MPI tests that are done here are not using qsub in the
> >$COMMAND so I did not think of this option.
> >
> >I see 3 possible solutions:
> >
> >1) go back to not checking "NORMAL END" :
> >(in testreport, uncomment line 570, comment line 571)
> >the little Pb here is that sometime the model stops
> >(e.g. in writing the final pickup) with some error msg
> >(from MITgcm) or from the system (if MPI testing),
> >but the RETVAL value is still 0 and
> >testreport does not catch the Pb (run="Y" and "pass").
> >
> >2) add an argument to testreport, to check (or not)
> >for "NORMAL END".
> >
> >3) do it in a clever way (but would need to be robust)
> >without an additional argument to testreport.
> > I don't have a good solution here (e.g.: check if COMMAND
> >  contain qsub ? would this work for your testing ? ).
> >
> >An other thing: since run.log is not over-written by:
> >  ( eval $COMMAND ) >> run.log 2>&1
> >do you know what would happen if inside the script
> > "runit_pgf77" you manage (if this is possible) to
> >redirect the output command to run.log ?
> >A simple way to test this would be to add in
> >runit_pgf77 something like:
> >echo "NORMAL END" >> {the right path/}run.log
> >and see what happen.
> >
> >Jean-Michel
> >
> >On Mon, Sep 04, 2006 at 09:28:56AM +0200, Martin Losch wrote:
> >>Hi Jean-Michel,
> >>
> >>your latest changes to testreport break my tests on our XD1, because
> >>in that case run.log never contains the model output, because my
> >>$COMMAND -variable is something like: "/usr/pbs/bin/qsub -W
> >>block=true /home/xd1/mlosch/runit_pgf77". I cannot run mpi-jobs
> >>interactively on that machine and have to use the batch-queue, so
> >>that run.log only contains messages from the queue, such as
> >>>2828.xd1-420-6
> >>which causes testreport to fail, when it looks for NORMAL END. What
> >>should we do about it?
> >>
> >>Martin
> >>
> >>_______________________________________________
> >>MITgcm-devel mailing list
> >>MITgcm-devel at mitgcm.org
> >>http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >_______________________________________________
> >MITgcm-devel mailing list
> >MITgcm-devel at mitgcm.org
> >http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel