Currently we can specify vpl.in how frequently (in physical time) we get outputs (using dOutputTime). It would be great if there were also the option to get outputs every N timesteps, where N is specified in vpl.in.
There are a few different reasons users might want this. In general, the evolution of systems can have phases where evolution is very fast (e.g., during the pre-main-sequence phase) and then times when it is much slower (e.g., main sequence). So this option allows output frequency that is dictated by how quickly any system parameters are changing. This is more economical for the size of the output files, since they are then only written when things change significantly, rather than always on some linear timescale (even if very little has changed). This will ensure that plots are always "pretty," meaning there won't be parts of the evolution that appear "unresolved" by having too few time outputs (nor having too many points where they aren't needed). This can even lead to a performance improvement, in cases (and times) where the output time cadence is actually smaller than the optimal timestep in the evolution. Finally, having outputs every N timesteps also gives the user direct information about the numerics of the runs (e.g., showing where the hard work is happening in the code), which can be useful for all kinds of reasons.
Currently we can specify vpl.in how frequently (in physical time) we get outputs (using dOutputTime). It would be great if there were also the option to get outputs every N timesteps, where N is specified in vpl.in.
There are a few different reasons users might want this. In general, the evolution of systems can have phases where evolution is very fast (e.g., during the pre-main-sequence phase) and then times when it is much slower (e.g., main sequence). So this option allows output frequency that is dictated by how quickly any system parameters are changing. This is more economical for the size of the output files, since they are then only written when things change significantly, rather than always on some linear timescale (even if very little has changed). This will ensure that plots are always "pretty," meaning there won't be parts of the evolution that appear "unresolved" by having too few time outputs (nor having too many points where they aren't needed). This can even lead to a performance improvement, in cases (and times) where the output time cadence is actually smaller than the optimal timestep in the evolution. Finally, having outputs every N timesteps also gives the user direct information about the numerics of the runs (e.g., showing where the hard work is happening in the code), which can be useful for all kinds of reasons.