Writing a restart file at the same time dumping with logfreq3

Hello,

I am dumping in an equally log spaced steps and its working, but I want to write restart file at the same time i am dumping. Its writing every 1 step a restart file, which is because the run command is called once and the variable inside it is using the initial value which is 1.

Is there a way to update the variable inside the run command?

variable        totalsteps equal 1000
variable stepstart equal $(step)+1
variable stepend equal ${totalsteps}+1

variable        logsteps equal logfreq3(${stepstart},110,${stepend})
dump            1 all atom 1 tmp.dump
dump_modify     1 every v_logsteps 

run ${totalsteps} every $(v_logsteps) &
"print 'Step: $(step) at: $(v_logsteps)'"

Thank you

No. You would have to update the source code and that is not as simple as you might think.

But there is an alternative. The every option to the run command is essentially a shortcut for having an explicit loop with “run <everysteps> pre no post no”. So all you would have to do, is to rewrite your run command as a loop where “<everysteps>” can be different in each iteration.

Thank you for the prompt reply. I am posting a solution, so anyone can find it.

variable        totalsteps equal 100000000
variable        stepstart equal $(step)+1
variable        stepend equal ${totalsteps}+1
variable        stepsnum equal 110
variable        logsteps equal logfreq3(${stepstart},${stepsnum},${stepend})
dump            1 all atom 1 tmp.dump
dump_modify     1 every v_logsteps 

label loop
variable a loop ${stepsnum}
variable temp equal $(v_logsteps)-$(step)
run ${temp} post no pre no
write_restart restart.in2d_$(step)
next a
jump SELF loop

These two lines could be combined into:

run ${logsteps} upto post no pre no

For a more generic solution, you may also want to add the “start” and “stop” keywords to the run command, e.g. if you have fixes that change their behavior over time like fix deform.

1 Like

I tried that with a minimal code for testing, but I am getting two different errors.

  • Using this part to equilibrate the system and then resetting ()
if "${var_restart} == 0" then  &
"run 20000000" &
"reset_timestep 0" &
"write_restart restart.in2d_equil"

On ver 3 Nov 22:
I got this error ERROR: Dump every variable returned a bad timestep, which means that the current timestep is larger than the variable, which is weird. Because when I print the timestep and the variable logsteps, it gives 0 and 1 which should work!
On ver 15 Jun 23
I got this error. Energy was not tallied on needed timestep

on both versions

  • If I run with totalsteps=1000 (it will generate a restart file)and then run again with totalsteps=100000, it will use the restart file from the last run, but I get this error.
    ERROR: Temperature compute degrees of freedom < 0

Can you please guide me to where to look, or is there a bug?

Full code:

variable        rng string gaussian
variable        seed equal 26105660
variable        temp equal 1.0
variable        pe equal 54.20641803989592
variable        var_restart equal is_file(restart.in2d)
variable        N_par equal 1
variable        x_max equal 5.0
variable        x_min equal -5.0
variable        y_max equal 5.0
variable        y_min equal -5.0
variable        totalsteps equal 10000000
variable        stepsnum equal 110

if "${var_restart} == 1" then  &
"variable   fp equal ${pe}" &
else  &
"variable   fp equal 10"

if "${var_restart} == 1" then  &
"read_restart restart.in2d" &
else  &
"units           lj" &
"atom_style      hybrid dipole sphere" &
"dimension       2" &
"boundary        p p p" &
"newton off" &
"#angle_style dipole" &
"#lattice         sq ${rho_den}" &
"lattice none 1.0" &
"atom_modify     map array sort 5000 0.0" &
"region          box block ${x_min} ${x_max} ${y_min} ${y_max} -0.2 0.2" &
"create_box      1 box" &
"create_atoms    1 random ${N_par} ${seed} box" &
"mass            * 1.0" &
"neighbor        0.4 bin" &
"neigh_modify    every 1 delay 1 check yes"

timestep        1e-6

#Run to reach steady state
if "${var_restart} == 0" then  &
"run 20000000" &
"reset_timestep 0" &
"write_restart restart.in2d_equil"

if "$(step) >= ${totalsteps}" then &
"print 'step : $(step) of ${totalsteps} ' " &
"quit 1"

variable        stepstart equal $(step)+1
variable        stepend equal ${totalsteps}+1
variable        logsteps equal logfreq3(${stepstart},${stepsnum},${stepend})

dump            1 all custom 1 data.restart_small.xyz id x y vx vy
dump_modify     1 every v_logsteps append yes


label loop
variable a loop ${stepsnum}
print "step : $(step) of ${totalsteps} : ${a} : ${logsteps}: ${stepstart}:${stepsnum}:${stepend} "
run ${logsteps} upto post no pre no
write_restart restart.in2d
next a
jump SELF loop

These are not likely errors related to the loop construct we discussed. So it would have been better to post this as a separate question. Furthermore, to identify possible errors, you should simplify the script and isolate the actual location of the error. The code section that you have pointed out, cannot be it.

You are not following common best practices for writing complex input files, specifically

  • build your input in stages and - ideally - first construct input files where you can test the correct operation of each stage separately
  • set up your test input with a system that can be computed very fast and adjust settings so that it will run to completion quickly. You can then always replace the numbers later, once you have figured out the flow of control in general.
  • for testing, don’t start an input with a barrage of constant variable definitions at the beginning, but use actual numbers as much as possible. It makes for much easier reading and debugging since one never has to go back to the various parts of the inputs and try to figure out what value a variable should have.
1 Like

I will post a separate question after I simplified the script.

The solution for this was to set dimension before read_restart

The solution for this is to run 0, before the variables definition.

removing ‘pre no’ from run command fixed this issue.

Thank you, following your guidelines fixed all three issues.