[Ncep.list.emc.glopara-support] Parallel cycle on vapor
Diane.Stokes at noaa.gov
Wed Oct 20 11:29:55 EDT 2010
Clarification to all...
When I said the pmkr script is fine, I meant the script Sim used:
That version was written to specify the satang file as output from the
"angu" job instead of the "anal" job.
For more info on the rlist, along with use of the $append_rlist variable
to define an appended rlist for ARC files and the $ALIST variable to
point a file containing entries for development files not covered by
(that address should be all one line if it does not appear that way in
your email viewer).
On 10/20/2010 11:09 AM, Diane Stokes wrote:
> I believe the pmkr script is fine. Your file:
> that is getting appended to the automated list includes old entries.
> Note the lines including and after:
> # rlist for /nfsuser/g01/mgd0sa/para/prx.config created by
> /nfsuser/g01/mgd0sa/para/pmkr on 2005-07-15 22:22:03 UTC
> (that's all one line).
> You should only include ARCA, ARCO, ARCR entries in the appended list.
> On 10/20/2010 10:58 AM, Diane Stokes wrote:
>> Specfically, comment out this line in your rlist:
>> */gdas/anal/ROTO = satang.$CDUMP.$CDATE
>> That should get you going again. Your analysis job worked, so you can
>> submit the next job in the sequence:
>> 2010082906 gdas angu
>> In the meantime, we'll sort out why your rlist was not generated
>> correctly. (This did come up before and I thought the issue had been
>> On 10/20/2010 10:35 AM, Daryl Kleist wrote:
>>> Su just recently ran into a similar problem with a run on
>>> Without looking, I suspect the issue is actually a conflict between the
>>> rlist being used (if it was generated automatically using the defaults)
>>> and the new scripts that have broken up the angle update and GSI parts
>>> of the analysis script (putting the angle update into its own scripts).
>>> The rlist probably still has "satang.$dump.$adate" as an expected output
>>> from the analysis script, where it is actually now output from the
>>> "angu" job. This is a pretty easy fix (a few lines need to be modified
>>> in the rlist).
>>> Also, this is a good chance to point out that the default rlist that is
>>> generated (if the one assumed isn't found) should be modified to be
>>> consistent with the new scripting.
>>> sim.aberson wrote:
>>>> I am continuing to run a parallel cycle on vapor and have encountered
>>>> another problem that is past my knowledge. My 2010082906 gdas anal
>>>> step is bombing. Output is in
>>>> /ptmp/mgd0sa/rotdatprx/nodrop2010082906gdasanal.dayfile. It looks like
>>>> the global_gsi is running fine (exit value is 0, exited: rc=0 for all
>>>> tasks, and ERR=0). After that, it gets murky. All I can find in that
>>>> dayfile is that some files it is trying to copy to get ready for the
>>>> fcst step aren't there:
>>>> + /u/wx20mi/bin/ncpx -p
>>>> 010082906 /ptmp/mgd0sa/rotdatprx
>>>> cp -p
>>>> cp: /stmp/mgd0sa/para/nodrop2010082906gdasanal/satcnt.gdas.2010082906:
>>>> A file or
>>>> directory in the path name does not exist.
>>>> + [[ 1 = 0 ]]
>>>> + echo pcop: satcnt.gdas.2010082906 not found in
>>>> + 1>& 2
>>>> pcop: satcnt.gdas.2010082906 not found in
>>>> + (( rc+=ra ))
>>>> + exit 12
>>>> + exit 12
>>>> + [[ 1 -ne 0 ]]
>>>> + /mtb/save/wx23sm/para_scripts/cver_1.1/bin/perr
>>>> + GROUP=mtb
>>>> + NCP=/u/wx20mi/bin/ncpx
>>>> + SUB=/u/wx23sm/bin/sub_vapor
>>>> + PLOG=/mtb/save/wx23sm/para_scripts/cver_1.1/bin/plog
>>>> + PSUB=/mtb/save/wx23sm/para_scripts/cver_1.1/bin/psub_angu
>>>> + [[ -n ]]
>>>> + export COMDAY=/ptmp/mgd0sa/rotdatprx
>>>> + export RESUBMIT=YES
>>>> + jn=nodrop2010082906gdasanal
>>>> + grep nodrop2010082906gdasanal failed
>>>> + /mtb/save/wx23sm/para_scripts/cver_1.1/bin/plog
>>>> .runlog ERROR nodrop2010082906gdasanal failed
>>>> Something else may be going on, but I have spent quite a bit of time
>>>> looking. Any ideas on how to fix this?
>>> Ncep.list.emc.glopara-support mailing list
>>> Ncep.list.emc.glopara-support at noaa.gov
More information about the Ncep.list.emc.glopara-support