[MITgcm-devel] complaint about testreport (o:

[Martin Losch]

added my scripts (most of them),
M.

On Sep 6, 2006, at 2:59 AM, Jean-Michel Campin wrote:

> 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel