On Oct 29, 2013 1:26 AM, "Pavan Ghatty" wrote:
>
> Now /afterok/ might not work since technically the job is killed due to
> walltime limits - making it not ok.
Hence use -maxh!
Mark
> So I suppose /afterany/ is a better
> option. But I do appreciate your warning about spamming the queue and ye
Now /afterok/ might not work since technically the job is killed due to
walltime limits - making it not ok. So I suppose /afterany/ is a better
option. But I do appreciate your warning about spamming the queue and yes I
will re-read PBS docs.
On Mon, Oct 28, 2013 at 5:11 PM, Mark Abraham wrote:
On Mon, Oct 28, 2013 at 7:53 PM, Pavan Ghatty wrote:
> Mark,
>
> The problem with one .tpr file set for 100ns is that when job number (say)
> 4 hits the wall limit, it crashes and never gets a chance to submit the
> next job. So it's not really automated.
>
That's why I suggested -maxh, so you ca
You're welcome
On 28 Oct 2013, at 20:03, Pavan Ghatty wrote:
> Aah yes of course. Thanks James.
>
>
>
> On Mon, Oct 28, 2013 at 3:16 PM, wrote:
>
>> No this isn't a problem. You can use job names under the -hold_jid flag.
>> As long as you change the job name in the submit script between
>>
Aah yes of course. Thanks James.
On Mon, Oct 28, 2013 at 3:16 PM, wrote:
> No this isn't a problem. You can use job names under the -hold_jid flag.
> As long as you change the job name in the submit script between
> submissions this isn't a problem. You could have a submit script for job 4
> w
No this isn't a problem. You can use job names under the -hold_jid flag.
As long as you change the job name in the submit script between
submissions this isn't a problem. You could have a submit script for job 4
with -N md_job4 and -hold_jid md_job3 then change these to -N md_job5 and
-hold_jid md_
Mark,
The problem with one .tpr file set for 100ns is that when job number (say)
4 hits the wall limit, it crashes and never gets a chance to submit the
next job. So it's not really automated.
Now I could initiate job 5 before /mdrun/ in job 4's script and hold job 5
till job 4 ends. But the PBS
On Mon, Oct 28, 2013 at 4:27 PM, Pavan Ghatty wrote:
> I have need to collect 100ns but I can collect only ~1ns (1000steps) per
> run. Since I dont have .trr files, I rely on .cpt files for restarts. For
> example,
>
> grompp -f md.mdp -c md_14.gro -t md_14.cpt -p system.top -o md_15
>
> This run
I have need to collect 100ns but I can collect only ~1ns (1000steps) per
run. Since I dont have .trr files, I rely on .cpt files for restarts. For
example,
grompp -f md.mdp -c md_14.gro -t md_14.cpt -p system.top -o md_15
This runs into a problem when the run gets killed due to walltime limits.
On 10/27/13 9:37 AM, Pavan Ghatty wrote:
Hello All,
Is there a way to make mdrun put out .cpt file with the same frequency as a
.xtc or .trr file. From here
http://www.gromacs.org/Documentation/How-tos/Doing_Restarts I see that we
can choose how often (time in mins) the .cpt file is written. B
Hello All,
Is there a way to make mdrun put out .cpt file with the same frequency as a
.xtc or .trr file. From here
http://www.gromacs.org/Documentation/How-tos/Doing_Restarts I see that we
can choose how often (time in mins) the .cpt file is written. But clearly
if the frequency of output of .cpt
11 matches
Mail list logo
