I forgot Dongshan (sorry): when PBS create a new rungms script
obviously the permissions have to be adapted... regards, F.
Quoting FyD <fyd.q4md-forcefieldtools.org>:
> Dear Dongshan,
>
> The problem is that the scratch directory is defined in the rungms
> script; and the scratch directory on a cluster has to be potentially
> unique for each job (to avoid to cross temporary files among different
> jobs); so we decided to generate a unique rungms by PBS job...
>
> - First we created a generic 'rungms.RED-Server' script that contains
> a generic ZZZZZZ scratch directory:
> The PBS script will replace ZZZZZZ by a specific name using its
> internal variable ($PBS_JOBID):
>
> # set SCR=/scr/$USER
> # set USERSCR=~$USER/scr
> # set GMSPATH=/u1/mike/gamess
> set SCR=/tmp/ZZZZZZ
> set USERSCR=/tmp/ZZZZZZ
> set GMSPATH=/usr/local/gamess
>
> - Then R.E.D. III.52 can automatically search for a 'rungms.info' file
> (see below); 'rungms.info' contains the name of the rungms$X file to
> be called by R.E.D...:
>
> # To use R.E.D./GAMESS on a UNIX cluster using a PBS script to handle
> multiple copies of the rungms$X script
> if (-e "$pathgamessus/rungms.info"){
> open(INFO,"< $pathgamessus/rungms.info");
> foreach(<INFO>){ $temprungms=$_; }
> close(INFO);
> chomp($temprungms);
> chomp($rungms=`which $temprungms`);
> }
> else { chomp($rungms=`which rungms`); }
>
> - Finally attached a part of our PBS script (csh shell) used on R.E.D.
> Server...
>
> if you find a more easy way - I am very much interested in ;-)
>
> regards, Francois
>
>
>> I used the following PBS script to submit a job on the cluster to do the
>> geometry optimization and create the .log file:
>>
>> ==================================================
>> #!/bin/bash
>> #PBS -q tiny16core
>> #PBS -l walltime=2:00:00
>> #PBS -l nodes=1:ppn=16
>> #PBS -N gms-16
>>
>> echo $PBS_O_WORKDIR
>> #module load intel/12.1.5
>> #module load mkl/12.1.5
>> #module load mvapich2/1.8
>> #module load gamess/5.1.2012
>>
>> cd $PBS_O_WORKDIR
>> #cat $PBS_NODEFILE
>> #NP=$(wc -l < $PBS_NODEFILE)
>>
>> /share/apps/gamess/rungms mel-gam 01 1 16 > mel-gam.log
>>
>> ===============================================
>>
>> I can finish this step and get the .log file normally.
>>
>> While for the RED charge fitting, I did through a PBS job in a queuing
>> system or through an interactive job on the login node. but both of these
>> ways failed. For the interactive running on the login node, I used "perl
>> RED-vIII.52.pl" and for the pbs script, the last line in the above file
>> changed to "perl RED-vIII.52.pl".
>>
>> Best!
>>
>> Dongshan
>>
>>
>> On Wed, Oct 9, 2013 at 3:03 PM, FyD <fyd.q4md-forcefieldtools.org> wrote:
>>
>>> Dear Dongshan,
>>>
>>>> I gave up to use the cluster to execute RED charge fitting and changed to
>>>> use the RED server on your website. Now I can finish the charge fitting
>>>> task and get the .mol2 file for Amber using. I notice that the RED server
>>>> use RED-III.4 instead of RED-III.52 to execute the charge fitting
>>>> procedure. Is there really bugs in RED-III.52 tools?
>>>
>>> R.E.D. Server interfaces R.E.D. IV, while the R.E.D. III.x tools are
>>> distributed under the GPL license.
>>>
>>> I can help you to configure your cluster and send you our scripts...
>>>
>>> You did not answer to the following question:
>>> Do you use a queuing system on your cluster? if Yes do you use PBS?
>>>
>>> regards,
>>> Francois
>>>
>>>
>>>> On Tue, Oct 8, 2013 at 11:37 PM, Dongshan Wei <dswei0523.gmail.com>
>>> wrote:
>>>>
>>>>> Dear Francois,
>>>>>
>>>>> I'm still having questions about the execution of RED-III.52. When I
>>>>> execute the command "perl RED-vIII.5.pl", I got the same question with
>>>>> the following link:
>>>>> http://q4md-forcefieldtools.org/RED/popup/bugs-III.4.txt
>>>>>
>>>>> "Problem: The scratch path defined in the "rungms" script of the
>>> GAMESS-US
>>>>> program is not found by R.E.D.-III.4 if an environment variable such as
>>>>> $USER is used in the path. For instance the /tmp/$USER path is not found
>>>>> even if the corresponding directory does exist (environment $USER
>>> variable
>>>>> points to "bill"), while /tmp/bill is found. This leads to the following
>>>>> error message: "
>>>>>
>>>>> So RED-III.52 doesn't update the bug? I want to go back to use
>>> RED-III.4,
>>>>> but it seems the RESP web doesn't offer the download for RESP-III.4
>>> tools.
>>>>> Is it true?
>>>>>
>>>>> Best!
>>>>>
>>>>> Dongshan
>>>>>
>>>>>
>>>>> On Tue, Oct 1, 2013 at 1:35 PM, FyD <fyd.q4md-forcefieldtools.org>
>>> wrote:
>>>>>
>>>>>> Dear Dongshan,
>>>>>>
>>>>>> Do you use the PBS queuing system?
>>>>>>
>>>>>> At R.E.D. Server we do use PBS (Torque/Maui):
>>>>>> See http://q4md-forcefieldtools.org/REDS/faq.php#8
>>>>>> We also use the same gamess version...
>>>>>>
>>>>>> # set SCR=/scr/$USER
>>>>>> # set USERSCR=~$USER/scr
>>>>>> # set GMSPATH=/u1/mike/gamess
>>>>>> set SCR=/tmp/ZZZZZZ
>>>>>> set USERSCR=/tmp/ZZZZZZ
>>>>>> set GMSPATH=/usr/local/gamess
>>>>>>
>>>>>> We use the same direction for SCR and GMSPATH; R.E.D. will move the
>>>>>> punch file from the scratch directory to the working directory to
>>>>>> extract the MEP...
>>>>>>
>>>>>> and the PBS script modify rungms to create a unique & temporary
>>>>>> scratch directory by job:
>>>>>> see and example:
>>>>>> set SCR=/tmp/R.E.D.IV-4379.master0.q4md-forcefieldtools.org
>>>>>> set USERSCR=/tmp/R.E.D.IV-4379.master0.q4md-forcefieldtools.org
>>>>>> set GMSPATH=/usr/local/gamess
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> the definition of the punch file is done in the script gms-files.csh
>>>>>> setenv INPUT $SCR/$JOB.F05
>>>>>> setenv PUNCH $USERSCR/$JOB.dat
>>>>>> setenv AOINTS $SCR/$JOB.F08
>>>>>> setenv MOINTS $SCR/$JOB.F09
>>>>>> setenv DICTNRY $SCR/$JOB.F10
>>>>>>
>>>>>> regards, Francois
>>>>>>
>>>>>>
>>>>>> > Thanks for your detailed reply. The gamess I used on the cluster is
>>>>>> gamess
>>>>>> > 5.1.2012 version. The rungms script is original from the gamess
>>> software
>>>>>> > and is attached here. Please help me have a look.
>>>>>> >
>>>>>> > Especially, the scratch directory /local_scratch/dswei disappeares
>>> after
>>>>>> > the job running finishes. I tried to change the scratch directory to
>>> my
>>>>>> > user directory in the rungms script and submitted a job to the
>>> cluster,
>>>>>> but
>>>>>> > the job quit quickly since there is no comminucation between the node
>>>>>> and
>>>>>> > my user directory. So how can I create a scratch directory both for
>>> job
>>>>>> > running and output saving?
>>>>>>
>>>>>> > On Tue, Oct 1, 2013 at 4:07 AM, FyD <fyd.q4md-forcefieldtools.org>
>>>>>> wrote:
>>>>>> >
>>>>>> >> Dear Dongshan,
>>>>>> >>
>>>>>> >> > Did you meet one problem "ERROR: Problem with the QM Scratch
>>>>>> directory"
>>>>>> >> > when using R.E.D. VIII.52 to derive the charge of atoms? In my
>>> case,
>>>>>> I
>>>>>> >> had
>>>>>> >> > used gamess to optimized the molecular structure and when I
>>> executed
>>>>>> >> R.E.D.
>>>>>> >> > VIII.52 with "perl RED-vIII.5.pl" command, the error is always
>>>>>> showing
>>>>>> >> as
>>>>>> >> > follows:
>>>>>> >>
>>>>>> >> which GAMESS do you interface?
>>>>>> >>
>>>>>> >> > The Scratch directory defined for GAMESS is /local_scratch/$USER
>>>>>> >> >
>>>>>> >> > Scratch directory for GAMESS [ NOT
>>>>>> FOUND ]
>>>>>> >>
>>>>>> >> So you need to create the corresponding scratch directory before to
>>>>>> >> execute R.E.D.
>>>>>> >>
>>>>>> >> > The USER Scratch directory defined for GAMESS is
>>>>>> >> /scratch/$USER
>>>>>> >> > Bad permissions for the GAMESS Scratch directory
>>>>>> >>
>>>>>> >> 'chmod 777' for this scratch directory...
>>>>>> >>
>>>>>> >> > The punch file directory defined for GAMESS is
>>>>>> >> $USERSCR/$JOB.dat
>>>>>> >> >
>>>>>> >> > ERROR: Problem with the QM Scratch directory.
>>>>>> >> > See the R.E.D.-II manual, page 7.
>>>>>> >>
>>>>>> >> See http://q4md-forcefieldtools.org/RED/RED-II.pdf
>>>>>> >>
>>>>>> >> > About the above error, I have some questions to ask:
>>>>>> >> > (1) To execute R.E.D.VIII.52, how many input files need to be
>>> read? I
>>>>>> >> think
>>>>>> >> > the necessary files are only three: Mol-red1.p2n, Mol-red1.log and
>>>>>> >> > Mol-red1.dat. Is this correct?
>>>>>> >>
>>>>>> >> See http://q4md-forcefieldtools.org/Tutorial/Tutorial-1.php#7
>>>>>> >> - if $OPT_Calc = "On" & $MEPCHR_Calc = "On" only the P2N file(s)
>>>>>> >> is(are) required; i.e. in your case Mol_red1.p2n
>>>>>> >> - if $OPT_Calc = "Off" & $MEPCHR_Calc = "On" the P2N file(s) and QM
>>>>>> >> output log file(s) are required; i.e. in your case Mol_red1.p2n &
>>>>>> >> Mol_red1.log
>>>>>> >> I do not know what is this Mol_red1.dat file; I think you mix up the
>>>>>> >> punch file and that Mol_red1.dat file.
>>>>>> >> See http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2918240/
>>>>>> >> & http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2918240/figure/F1/
>>>>>> >> the punch file is the JOB2-gam_m$n-$i-$j.dat file
>>>>>> >> $n molecule // $i conformation // $j orientation
>>>>>> >>
>>>>>> >> > (2) To my understanding, the scratch directory
>>> /local_scratch/$USER
>>>>>> is
>>>>>> >> > generated temporarily for intermediate outputs during the
>>>>>> optimization
>>>>>> >> > calculation before executing R.E.D. fitting, and after the job is
>>>>>> >> finished,
>>>>>> >> > the temporal scratch directory will be deleted automaticly. So to
>>> do
>>>>>> >> R.E.D.
>>>>>> >> > fitting, the scratch directory is not necessary. Is this correct?
>>>>>> >>
>>>>>> >> on a cluster - & using the PBS queuing system, Yes, a temporary
>>>>>> >> scratch directory can be created just before executing R.E.D. and
>>>>>> >> removed just after the job has finished.
>>>>>> >>
>>>>>> >> on a workstation you could create this scratch directory only once
>>> and
>>>>>> >> keep it for all the R.E.D. jobs... If this scratch directory is only
>>>>>> >> for your login you could use a specific directory in your login (if
>>>>>> >> you have a enough space in your login also)
>>>>>> >> If the scratch directory is to be shared with other users you could
>>>>>> >> use the /tmp partition and then create a directory in /tmp related
>>> to
>>>>>> >> your login. /tmp could be a particular partition with a looot of
>>> room.
>>>>>> >>
>>>>>> >> > (3) From the above information, it seems the R.E.D. VIII.52 cannot
>>>>>> >> > recognize variables such as $USER, $USERSCR, $JOB, because the
>>>>>> directory
>>>>>> >> > /scratch/dswei and the file /scratch/dswei/Mol-red1.dat do exist.
>>>>>> Here
>>>>>> >> > dswei is my username on the cluster. How to solve the problem?
>>>>>> >>
>>>>>> >> please tell me which GAMESS version you use? and send me your
>>> 'rungms'
>>>>>> >> script: I could prepare it for you if you agree...
>>>>>> >>
>>>>>> >> > I'm learning the R.E.D., so your reply to my above question will
>>> be
>>>>>> great
>>>>>> >> > help to me.
>>>>>> >>
>>>>>> >> do not hesitate to ask as many questions as you wish ;-)
>>>>>> >>
>>>>>> >> regards, Francois
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Oct 10 2013 - 02:30:03 PDT
