[gmx-users] timestep fraction complete
Mark Abraham
Mark.Abraham at anu.edu.au
Fri Sep 25 00:58:55 CEST 2009
Jack Shultz wrote:
> I am hoping for an update every 10 minutes just to satisfy the anxieties
> of volunteers crunching on my project, but every hour may be
> satisfactory. And if I can do this without requiring any shell scripts
> it would be better in my environment. So I started making some code
> modifications which apparently did not work
>
> src/mdlib/sim_util.c:93:void print_time(FILE *out,time_t start,int
> step,t_inputrec *ir)
> src/mdlib/sim_util.c-94-{
> src/mdlib/sim_util.c-95- static real time_per_step;
> src/mdlib/sim_util.c-96- static time_t end;
> src/mdlib/sim_util.c-97- time_t finish;
> src/mdlib/sim_util.c-98- double dt, fc;
> src/mdlib/sim_util.c-99- char buf[48];
> src/mdlib/sim_util.c-100- FILE *progress="progress.txt";
> src/mdlib/sim_util.c-101-
> src/mdlib/sim_util.c-102- if (!gmx_parallel_env)
> src/mdlib/sim_util.c-103- fprintf(out,"\r");
> src/mdlib/sim_util.c-104- fprintf(out,"step %d",step);
> src/mdlib/sim_util.c-105- if ((step >= ir->nstlist)) {
> src/mdlib/sim_util.c-106- if ((ir->nstlist == 0) || ((step %
> ir->nstlist) == 0)) {
> src/mdlib/sim_util.c-107- /* We have done a full cycle let's update
> time_per_step */
> src/mdlib/sim_util.c-108- end=time(NULL);
> src/mdlib/sim_util.c-109- dt=difftime(end,start);
> src/mdlib/sim_util.c-110- time_per_step=dt/(step - ir->init_step + 1);
> src/mdlib/sim_util.c-111- }
> src/mdlib/sim_util.c-112- dt=(ir->nsteps + ir->init_step -
> step)*time_per_step;
> src/mdlib/sim_util.c-113-
> src/mdlib/sim_util.c-114- if (dt >= 300) {
> src/mdlib/sim_util.c-115- finish = end+(time_t)dt;
> src/mdlib/sim_util.c-116- sprintf(buf,"%s",ctime(&finish));
> src/mdlib/sim_util.c-117- buf[strlen(buf)-1]='\0';
> src/mdlib/sim_util.c-118- fprintf(out,", will finish %s",buf);
> src/mdlib/sim_util.c-119- }
> src/mdlib/sim_util.c-120- else
> src/mdlib/sim_util.c-121- fprintf(out,", remaining runtime: %5d
> s ",(int)dt);
> src/mdlib/sim_util.c-122- fc = (int)dt / ir->nstlist;
> src/mdlib/sim_util.c-123- fprintf(stderr, "Fraction complete: %d
> \n", fc);
You're doing integer division and writing an integer. That won't get you
fraction complete, even if the ratio of dt (the remaining runtime in
seconds) and ir->nstlist (the number of steps between neighboursearches)
meant anything! Use
fprintf(stderr, "Fraction complete: %g\n", (step - ir->init_step) /
(float) ir->nsteps);
Mark
> src/mdlib/sim_util.c-124- }
> src/mdlib/sim_util.c-125- if (gmx_parallel_env)
> src/mdlib/sim_util.c-126- fprintf(out,"\n");
> src/mdlib/sim_util.c-127-
> src/mdlib/sim_util.c-128- fflush(out);
> src/mdlib/sim_util.c-129-}
>
> Back Off! I just backed up md.edr to ./#md.edr.4#
> starting mdrun 'Protein in water'
> 500 steps, 1.0 ps.
> step 100, remaining runtime: 122 s Fraction complete: 0
> step 200, remaining runtime: 92 s Fraction complete: 0
>
>
> On Thu, Sep 24, 2009 at 6:34 PM, Mark Abraham <Mark.Abraham at anu.edu.au
> <mailto:Mark.Abraham at anu.edu.au>> wrote:
>
> Jack Shultz wrote:
>
> I figured out another way to update the progress of my
> simulation, but I need to report the fraction of completion at
> the certain intervals of mdrun. Possibly at every time step or
> if that does not make sense every 100 timesteps. I don't think
> this is a feature currently supported, so I will have to make
> some source code chages. I am looking for the variables related
> to total number of time steps and where it controls the the
> current time step so I can calculate the fraction of complete
> where current-timestep / total-timestep
>
>
> Under at least some circumstances GROMACS writes the expected
> runtime remaining to stderr, but I don't recall what/when. Piping
> that to some useful script has to be a good start. You certainly
> don't need this data every time step, and don't want to be
> perturbing mdrun to get it.
>
> Even if the above was unsuitable, surely progress would only need to
> be moderately accurate and for simulations that last many hours. If
> so, you'll get good enough data by grepping a gmxdump of the .tpr to
> get the expected frequencies of output and length of run, and then
> watching the growth of whichever of .log/.trr/.edr is written most
> frequently. I/O buffering will affect the numbers somewhat.
>
> Mark
>
> _______________________________________________
> gmx-users mailing list gmx-users at gromacs.org
> <mailto:gmx-users at gromacs.org>
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at http://www.gromacs.org/search before
> posting!
> Please don't post (un)subscribe requests to the list. Use the www
> interface or send it to gmx-users-request at gromacs.org
> <mailto:gmx-users-request at gromacs.org>.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
>
>
>
>
> --
> Jack
>
> http://drugdiscoveryathome.com
> http://hydrogenathome.org
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> gmx-users mailing list gmx-users at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at http://www.gromacs.org/search before posting!
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
More information about the gromacs.org_gmx-users
mailing list