Ah of course! fc = (int)dt / ir->nstlist; I should cast these as data types that support decimals right?
On Thu, Sep 24, 2009 at 6:44 PM, Jack Shultz <[email protected]>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); > 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 > <[email protected]>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 [email protected] >> 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 [email protected]. >> Can't post? Read http://www.gromacs.org/mailing_lists/users.php >> > > > > -- > Jack > > http://drugdiscoveryathome.com > http://hydrogenathome.org > -- Jack http://drugdiscoveryathome.com http://hydrogenathome.org
_______________________________________________ gmx-users mailing list [email protected] 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 [email protected]. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
