Another identical symptom, probably the same bug:

On Pangu with the Pyrized version of SPECFEM3D Globe,

    --lsf.wait

works, but

    --scheduler.wait

doesn't.  In both cases (CitcomS and SPECFEM3D), <componentName>.<property>
works, but <facilityName>.<property> doesn't.  (Note that SPECFEM3D is using a
more evolved version of my batch system code, hence "scheduler" instead of
"launcher".)

Vlad,

Whoops... I guess that should be

 --lsf.queue=debug

I'm not sure why "--launcher.queue" doesn't work... intuitively, it 
seems like it should. But it seems like the value set in the PML file 
under ~/.pyre overrides it. This might be a bug in Pyre. I'll CC Roundup 
to remind myself to investigate later.

By the way, use --launcher.dry to preview/debug the LSF script.

--Leif

Vlad Constantin Manea wrote:

> Leif,
>
> When I sent the job with debug, I got this (seems that the job was 
> sent <normal> instead of <debug>):
>
> [vlad@login-2-3 Low_Visc_Fault]$ ./low_visc2.sh
> LSF has been directed to provide only nodes with working Myrinet gm.
> LSF has been directed to provide only nodes with working /ibrixfs1.
> Apr 19 18:19:16 2006 20754 4 6.0 Conflict parameter LSB_SUB_RES_REQ - 
> Ignored.
> Job <38275> is submitted to queue <normal>.
>
> Vlad
> ___________
>
> Leif Strand wrote:
>
>> If you mean you want to run on one of the two debugging queues, that 
>> would be:
>>
>>
>>   --launcher.queue=debug
>>
>> or
>>
>>   --launcher.queue=debug-long
>>
>> --Leif
>>
>>
>> Vlad Constantin Manea wrote:
>>
>>> Hi Leif,
>>>
>>> Just a question: if I want to run a debugging CitComS run on Pangu,
>>> how can I do it? (sometimes a normal run is "pending" for loooong 
>>> time ...
>>> although I have a 5 min debugging run.)
>>>
>>>
>>> Thanks,
>>> Vlad
>>>
>>
>