Folding Forum

I have new information: All you have to do is count the iterations (steps) per day. Each step represents 2fs.

1fs = 10^-15 seconds
1ns = 10**-9 seconds

500,000 steps = 1 ns.

Is that true with all projects regardless of size? It does seem to me a bit simplistic but if universally true, that makes for an easy calculation. It also should make ns/day a linear correlation to PPD/day with just constant multiplier that is specific to a particular HW configuration and project.

FACT: PG doesn't think it's worth the effort to make a change.
FACT: In the discussion, I was told that a step is always 2fs and my response was the same as yours: Really? No matter what the protein is?

The longer I think about it, the more I'm convinced that it makes sense. I've done a lot of simulation of (larger) mechanical systems. From my experience with them, the step size needs to be small enough to manage the lightest object (probably a H atom) with the stiffest force (probably an interatomic bond). When I look at a protein in the viewer, I see individual H atoms waving around at a high frequency like a balloon in the wind and the frequency of that motion probably defines the step size. Larger blocks of atoms (often along the backbone) move back and forth at lower frequencies and a small step size can simulate that part without introducing other problems.

[Newton's law: F=MA applies to all kinds of systems. Numerical integration also follows the same rules once you know the magnitude of M and you look at the force gradient in terms of stiffness.]

Relative easy solution if that really is (as it sounds) correct for all cores/projects. In that case I would have all information at hand and can utilize it.

ChristianVirtual wrote:In that case I would have all information at hand and can utilize it.

Not quite all I think- you'd need to know the number of steps/WU, it doesn't seem to be constant between projects.

Easily obtainable from the logs of course for currently processing (or recently processed) WUs, but is that information available elsewhere for WUs that have scrolled out of the old log files?

billford wrote:

ChristianVirtual wrote:In that case I would have all information at hand and can utilize it.

Not quite all I think- you'd need to know the number of steps/WU, it doesn't seem to be constant between projects.

Easily obtainable from the logs of course for currently processing (or recently processed) WUs, but is that information available elsewhere for WUs that have scrolled out of the old log files?

You are right: the log-file seems the only available source for the step-info; the remote API has some different measure called frames. But scanning the log-files something HFM (I guess) or my iPad app are doing anyway (painful as it is). This way it will not find its way into broader public visibility via FAHControl but that seems not desired by PG anyway.

Enthusiasts on the other way using 3rd party tool would get access to that figure. And let see: if nothing bad comes out of it PG might change its opinion ?

On a side note: when reading the posting about "Anton" viewtopic.php?f=16&t=26664: in the attached PDF file the 2fs are also mentioned; on page 3. Seems a plausible value.

The benchmark report for the previous generation Anton did mention 2.5 fS and the Anton 2 report specifically says ~2 (i.e. approximately). Nevertheless, if Dr. Pande says FAH uses 2.0, I trust him. Using 2.5 would have the ability to speed up the calculations to 125% but would also increase the percentage of unstable WUs so a centralized decision make sense.

Edit: More information:
There's a page on http://wiki.simtk.org/ regarding benchmarking of OpenMM. Two cases were reported for Explicit Solvent calculations: My interpretation of those statements is that with a 2 fs step size, the hydrogen atoms can be simulated normally. With 5 fs, the simulation doesn't work unless you increase the mass. Of course I'm not an expert and I could easily be wrong, but it does support the idea that 2fs works for everything.

Bruce is correct. We want to use as large a timestep as possible, but it is limited by the fastest motion (hydrogens, because they are very light). We (and most of the MD community) generally stick with 2.0 fs timesteps.

There are some tricks we can use to increase the timestep (better sampling) at the cost of some accuracy.

As pointed out, system size has a huge impact on ns / day (n*log n complexity)