Thanks Shervin,

so as you can see from the head higheta branch in my repository,

https://github.com/hengne/ECALELF/blob/higheta/ALCARAW_RECO/scripts/prodAlcareco.sh

my temporary solution is to supply crab the proxy file through the
"additional_input_files" argument when creating the crab.cfg in
prodAlcareco.sh. But that requires the change in the initCmsEnv.sh that
removes the "-out $HOME/gpi.out"  in the "voms-proxy-init " command. So
that it will look for the defaut /tmp/x509xxxxx proxy file, (where the
"xxxxx" is the user's ID), and also transfer the proxy file to the
corresponding location (i.e. also /tmp/x509xxxxxx)  in a worker node. I am
doing this because the xrootd service also looks for the proxy file at
/tmp/x509xxxx as the default option. However, if one can make the xrootd
service to look for the proxy file at the user's home directory as
"$HOME/gpi.out" as indicated in the voms-proxy-init command, that could
also work. May be even better, just that this way it requires the AFS
service, because it needs to visit the user's home directory.  But that
doesn't seem to be an issue at all at CERN CAF.


Cheers, Hengne






On Sun, May 25, 2014 at 10:02 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
>
> thank, now I understand better. I need to think better about it. if the
> problem is only with the caf/lsf schedulers we can forward the certificate
> location as she'll variable (the certificate is in the home and it is
> accessible) Da: Hengne Li Inviato: domenica 25 maggio 2014 21:11 A:
> ECALELFS/ECALELF Rispondi a: ECALELFS/ECALELF Cc: Shervin Nourbakhsh
> Oggetto: Re: [ECALELF] Higheta (#21<https://github.com/ECALELFS/ECALELF/pull/21>)
> 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
> 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> . — Reply to
> this email directly or view it on GitHub<
> https://github.com/ECALELFS/ECALELF/pull/21/files#r13032157>.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/ECALELFS/ECALELF/pull/21/files#r13032552>
> .
>