Hi
In ngs the check of sweeps and the elapsed time/termination signals are separated. The simulation classes provieds a fraction_complete function which checks the progress in sweeps and the callback, passed to the run function (normaly apls::check_callback) checks the time and the termination signals. If the application runs too long than either the check callback does not check the time properly or the check schedule does not often enough check the progress.
The check_schedule can be initialized with the mpi adapter:
mcmpiadapter(parameters, mpi_communicator, check_schedule(tmin, tmax));
Best Lukas
2014/1/4 Emanuel Gull emanuel.gull@gmail.com
Hi Steffen,
I don’t know what’s going on but I’ll look into it. The underlying framework may have changed how often it checks if time’s up.
our ‘fraction_completed’ command uses only sweeps, not time, to see how far along we are in the simulation:
hyb.hpp:61: double fraction_completed() const {return is_thermalized()?(sweeps-thermalization_sweeps)/(double)total_sweeps:0.; }
if the simulation stops because time’s up then we can change that (or add another criterion) to exit based on time.
does anybody know what changed in ngs?
Emanuel
On Jan 3, 2014, at 7:25 PM, backes@th.physik.uni-frankfurt.de wrote:
Dear developers,
I recently checked out the newest version of the Alps code rev. 7291 and compiled the Hybridization expansion Impurity solver with the Intel compiler composer_xe_2013.3.163 on Ubuntu 12.04 LTS.
My problem is that the code takes longer to exit than specified in MAX_TIME in the parameter file (SWEEPS much higher than possible in this time). I.e.
MAX_TIME = 30 --> runs for 60sec MAX_TIME = 60 --> runs for 180sec MAX_TIME = 120 --> runs for 180sec MAX_TIME = 180 --> runs for 420sec MAX_TIME = 240 --> runs for 420sec
Also for longer time and mpi-parallelization the behaviour is similar. With an older version checked out about 2 months ago this problem did not occur. Could you check if this problem is caused by some change in the code?
Thanks, Steffen