Peter & Kevin - I just posted a 19Jun12 patch that as far as my tests
showed, solves all problems with granular restarts and continued runs.
Meaning that it insures the pairwise shear history values are
preserved correctly for touching pairs of atoms.
It does not address the more fundamental issue of not being
able to exactly continue/restart a velocity-dependent potential.
But assuming this patch is correct, I think this is as good as
we can do.
If you can both verify this version works on the test problems you
have (i.e. as well as your peronally modified versions of the code
did), that would be great.
Please let me know either way ...
Thanks,
Steve
Steve -
Catching up now. You convinced me - velocity dependent potentials like this will be highly problematic to fully preserve for restarts.
However - not all granular potentials are velocity dependent: we have been using gamman=gammat = 0 ; eg.
pair_style gran/hooke/history 200000.0 50000.0 0.0 0.0 0.5 0
which has are still history dependent (due to the non-zero shear term) but with no direct contribution from the velocity-dependent components of the force expression. I think it is reasonable to expect that a potential of this type should be able to correctly restart and continue.
I tried a few of my tests with the latest codebase with the "velocity-independent" potential above. The run-continuation tests seem to work, the restarts did not. Will look in a little more detail at your patch - it must be very close, because all the basic hooks are there - I suspect it just needs an appropriate toggle for the shearupdate flag to prevent the "double-updates" upon reading a restart file and running more dynamics.
Peter
Hi Steve,
Everything that you wrote in your previous e-mails make sense to me, and clarified for me the difficulties of maintaining perfect continuity across restart files.
As regards the latest patch (20th June), the shear history seemed fine to me when I ran some tests with a serial implementation, both for continuing runs and for restarting simulations. I suspect that there might still be something strange happening when writing restart files with the write_restart command (the restart command seems OK). Even if a restart file is written and the run is continued, it seems to me that the act of writing the file causes an issue (it's not necessary to read the restart file back in), so I'll look into this in more detail.
Thanks for all of your help on this,
Kevin
I don't see any issues with restart files in my tests. If either
of you can send a small data file and scripts that illustrate
the problem, I'll take a look.
Steve
Of course. A small restart file and a script is attached. The script is for two cases:
1) Run 1000 steps, write_restart and then run another 1000 steps
2) Run 1000 steps, write a restart file using restart and run another 1000 steps with a loop
Clear differences are seen in the thermo output after 1000 steps caused by writing the restart file (in case 1). Case 2 shows no issues.
Regards,
Kevin
in.sp_test (1.09 KB)
restart_file (177 KB)
ok - I think I found the issue - a one character change 
wilil be in the next patch later today ...
Thanks and let me know if you see any other issues.
Steve
Steve and Kevin - I pulled the latest patched version this AM and ran all the tests - they all work beautifully now.
Many, *many* thanks for diagnosing and efficiently implementing these improvements into the codebase...
Peter
good news ... thanks for your help on this as well
Steve