On Sun, May 25, 2014 at 8:50 PM, shervin86 <notifications@github.com> wrote:

> In ALCARAW_RECO/scripts/prodAlcareco.sh:
>
> > @@ -189,6 +202,16 @@ if [ "$RUNRANGE" == "allRange" -o "`echo $RUNRANGE |grep -c -P '[0-9]+-[0-9]+'`"
> >      unset RUNRANGE
> >  fi
> >
> > +# make argument.xml file if do MC
> > +if [ "$TYPE" == "ALCARECOSIM" ] && [ -n "${CREATE}" ];then
>
> Why don't just add this line as option?
> data_location_override = se_white_list
>
> According to
> https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookXrootdService
> you don't need to add any script. If the dataset is published (as supposed
> by you using DAS), then you can ask to CRAB to figure out where the data
> are.
> I've never used that option but I can try tomorrow.
>
Hello Shervin,

Thanks for your agreement on this direction. I tested this option twiki
page suggested, that doesn't work for using the caf  schedular locally at
CERN, because the caf scheduler does not ship the user's proxy file
/tmp/x509xxx to the caf worker nodes so that the jobs will fail due to grid
CA issue. But if you use the remoteGlidein scheduler to submit jobs to CAF,
that would work, because that scheduler do ships the proxy files to CAF's
workernodes. However, the remoteGlidein scheduler has a limit on the size
of the input sandbox up to 100MB. But our ECAL ELF input sandbox by default
is >300MB, which always fail to get the jobs be submitted, while CAF
scheduler locally at CERN does not have that limit.  So, my additional
scripts does only it is just to ship the user's proxy file to the worker
node for the CAF scheduler.

But nevertheless, although I think this is an advanced option that worth to
be kept in the ECALELF package, but I also agree that this mechanism might
be better reserved as an expert level option for some urgent tasks.

Cheers, Hengne






> —
> Reply to this email directly or view it on GitHub<https://github.com/ECALELFS/ECALELF/pull/21/files#r13032060>
> .
>