Hello everyone,
I am trying Green-Kubo method to calculate thermal conductivity, with compute heat/flux and
fix JJ all ave/correlate $s $p $d &
c_flux[1] c_flux[2] c_flux[3] type auto file J0Jt.dat ave running
I checked J0JT.data but I didn't get a converged heat flux autocorrelation. I decide to increase simulation time as well as correlation length,
it would be a long simulation so I divide it into several continuous simulations with the command of "write_restart" and "read_restart".
but the problem is the newly generated J0Jt.dat will replace the former one, and it's not calculating the long-time correlation.
My question is : with "write_restart" and "read_restart", can LAMMPS continue with auto-correlation calculation and write the information to the same J0Jt.dat file?
Any hints will be greatly appreciated!
Cheers,
Yuxiang
Hello everyone,
I am trying Green-Kubo method to calculate thermal conductivity, with compute heat/flux and
fix JJ all ave/correlate $s $p $d &
c_flux[1] c_flux[2] c_flux[3] type auto file J0Jt.dat ave running
I checked J0JT.data but I didn't get a converged heat flux autocorrelation. I decide to increase simulation time as well as correlation length,
it would be a long simulation so I divide it into several continuous simulations with the command of "write_restart" and "read_restart".
but the problem is the newly generated J0Jt.dat will replace the former one, and it's not calculating the long-time correlation.
My question is : with "write_restart" and "read_restart", can LAMMPS continue with auto-correlation calculation and write the information to the same J0Jt.dat file?
Any hints will be greatly appreciated!
what is written to a restart file and not
is listed in detail on the corresponding
manual pages of the individual commands.
please have a closer look and help yourself.
in general, it is probably advisable to break
the calculations in such pieces, that you
can write into separate output files and then
just need to write a little script or program
to combine them.
axel.
Thanks for your early reply, Axel.
In my case, since the long simulation was divided to several pieces, the number of time steps run in each piece are smaller than ps (NeveryNrepeat, dump interval).
thus LAMMPS could not finish a complete correlation calculation in that piece, and returns zero values to the dumped file J0Jt.dat.
How could I solve this problem?
Yuxiang
Thanks for your early reply, Axel.
In my case, since the long simulation was divided to several pieces, the
number of time steps run in each piece are smaller than p*s (Nevery*Nrepeat,
dump interval).
thus LAMMPS could not finish a complete correlation calculation in that
piece, and returns zero values to the dumped file J0Jt.dat.
How could I solve this problem?
i don't know. i don't do this kind of calculation.
please read the documentation as i suggested.
that is what it is for.
axel.
Have you tried the "rerun" command?
http://lammps.sandia.gov/doc/rerun.html
You can use rerun will carry out all of the fixes, computes & print
commands, using the entire trajectory from your simulations. It can
read from multiple dump files. (You don't have to combine all of your
dump files into one file.)
I think you mentioned that you save data to your dump files infrequently.
This is not a problem because:
1) To compute the correlation-function (correlation versus time
separation), for large time-separations, you don't need
high-resolution data (frequent dumps).
2) For short-times, (to compute the correlation-function at short time
separations), you can recompute the correlation-function vs. time from
each simulation fragment using "fix ave/correlate". Hopefully there
is a way to save each correlation function for each simulation
fragment to a separate file (so you don't overwrite the old file).
Then average the data in all of these files together. (In other
words, the average correlation-function {averaged over all of the
correlation functions obtained for each simulation fragment} should
equal the true correlation function for the entire simulation {at
small separation times, assuming you have enough sampling, and
assuming the system is not being driven externally}.) Of course,
correlation-functions obtained this way will only be accurate for
short time-separations (shorter than the duration of each simulation
fragment).
If you graph the correlation functions you get from 1) and 2), then
they should overlap (somewhere in the middle at moderate
time-separations near the dump time-interval). If you throw away the
data from 2) at long-time separations, you are left with a graph of
the correlation function (correlation-function vs. time-separation for
small and large time-separations).
I believe the thermal conductivity can be computed from the area under
this curve.
Of course, again the correlations data at -really- large
time-separations (approaching the length of your entire simulation)
are not trustworthy, and should also be ignored. I don't do this kind
of calculation either, so there may be easier ways to do this in
LAMMPS. (I may also be wrong.)
I hope this helps.
Andrew
My question is : with "write_restart" and "read_restart", can LAMMPS continue with auto-correlation calculation and write the information to the same > J0Jt.dat file?
No, none of the fix ave commands carry over their values thru a restart
by saving info in the restart file (the doc pages state this). This
could be added, but it is non-trivial
depending on when the restart file is written and how much info might
need to be saved.
Steve
My question is : with "write_restart" and "read_restart", can LAMMPS continue with auto-correlation calculation and write the information to the same > J0Jt.dat file?
No, none of the fix ave commands carry over their values thru a restart
by saving info in the restart file (the doc pages state this). This
could be added, but it is non-trivial
depending on when the restart file is written and how much info might
need to be saved.
Yeah,...I chose to start using LAMMPS because it's modular and easy to
add features and force-fields to it. I can confirm that being forced
to worry about restart details makes it a somewhat harder for novice
end-users to submit their own fixes to LAMMPS. (As someone currently
writing a fix command, I'd prefer that managing restart files should
not be mandatory for all submitted fixes. I suppose I would not mind
if some fixes handle restart files and others don't.)
(Feel free to ignore this email.)
Cheers!
Andrew
Yeah,...I chose to start using LAMMPS because it's modular and easy to
add features and force-fields to it. I can confirm that being forced
to worry about restart details makes it a somewhat harder for novice
end-users to submit their own fixes to LAMMPS. (As someone currently
writing a fix command, I'd prefer that managing restart files should
not be mandatory for all submitted fixes. I suppose I would not mind
where is it written and shown that fixes need to handle restarts?
for some fixes it simply is not necessary. i have myself written
some of them. if you make sure that restart_global and restart_peratom
are set to 0, then none of the restart related functions will be called.
also, storing global information is pretty simple to implement
(see fix smd)
if some fixes handle restart files and others don't.)
fix imd or fix colvars for example don't handle restarts.
axel.
Thank you for your kind and detailed answer.
Indeed “return” command could read multiple dump files and perform a psuedo simulation. However, the command
‘ave/correlate’ does not save any information that could be read by restart command, thus the dumped correlation file
J0Jt…data from each sub-simulation (the simulation fragment) only includes the information in that sub-simulation,
and they are not connected. Thus what I can do is to dump all the heat flux, and calculate the correlation function with
other tools.
Thanks again and Best wishes,
Yuxiang
All of the computes that compute heat/flux is using as
input (per-atom stress, energy, ke, etc) are per-atom
properties that can be dumped to a dump file. So if
you wish to post-process them yourself, you can
simply dump them, as you would atom coords.
Steve
Axel is correct. It's up to the fix (and its author)
if you want the fix to store and retrieve info in a restart
file. Either global quantities or per-atom quantities.
But there's no free lunch. If you don't implement the
needed methods,
then the fix will not "restart" auto-magically.
Steve