Folding Forum

3906 utilizing Double Gromacs Core B is an interesting project, at least to me. First of all, it's pacing to yield more than twice the PPD I normally get on that machine (I think because it was benchmarked not using SSE2), plus it started out with frames that each took progessively longer to complete on a dedicated machine before reaching a stabilized timeframe about 10% in. Can anyone explain the latter? btw, this one also progresses by single frames whereas previous ones using double gromacs and/or sse2 advanced in pairs IIRC.

The usual definition of a "frame" is some fraction of an entire WU. There's no requirement that the results contain data for each 1% of the WU.

In this case, if there are only 50 frames in a WU, then each frame is 2% of the WU. That's not what I'd call advancing in pairs of frames, it's just that the Pande Group only needed data for 50 frames.

According to the Stanford site, p3906 is supposed to be 50 frames but it runs as 100 frames.

Fahmon also thinks p3906 is 50 frames.

That '50 frame' thing is probably part of the problem.

It didn't make it into "the database" (whatever that means) and you won't get any credit when you finish one.

but I digress..... Just here to mention that it definitely does process 100 steps.... not the 50 as advertised.

-Sid

I only mentioned the 50 frame thing as a btw, lol. I was more curious about the lengthening opening frame times over the first few frames on a machine with nothing else running. Anyone else experience that aspect of it?

ArVee wrote:3906 utilizing Double Gromacs Core B is an interesting project, at least to me. First of all, it's pacing to yield more than twice the PPD I normally get on that machine (I think because it was benchmarked not using SSE2)

My C2Ds have gotten 3906 WUs and they run closer to 4 times as fast as normal WUs. Wondered if something was up but it's doing and returning them.

The only real issue I have with p3906 is they are not showing up in my (and others) Stats.

Check to see if you are getting credit for them.

cheers!

There seems to be a problem with the server handling these. I don't think anyone has gotten credit for them.

As long as your cpu has SSE2, these things will scream. Of course, fahmon doesn't like them because the reported frames are "wrong".

ArVee wrote:I only mentioned the 50 frame thing as a btw, lol. I was more curious about the lengthening opening frame times over the first few frames on a machine with nothing else running. Anyone else experience that aspect of it?

I had it too. The first frames were 6m50s but then they settled at 8m40s on my 3GHz P4.
These are generation 0, meaning that it is the very beginning of the simulation. Since the initial position of water molecules is random, it means that they are slightly out of place at the beginning and it takes a few frames before they reach a reasonable equilibrium. Therefore the actual protein is not simulated as folding in the first few steps. The real work begins once the water is firmly in place.

An old explanation on the subject: fahwiki.

This project has troubles on fahinfo.org as well. It took me over 14 hours to complete a WU on my P4, so the PPD should be around 500 points but when I entered a 1% frame time on fahinfo, it reported that I'm getting over 1000 PPD. I fixed my frame times by doubling them but there are other reports in already with astronomical PPD.

BTW, is it alright to enter Gen 0 frame times at fahinfo?

uncle fuzzy wrote:There seems to be a problem with the server handling these. I don't think anyone has gotten credit for them.

Yes, there was a delay with credits from server .88 getting added to the total stats. That seems to have been resolved.

Thank you for explaining why the initial frames ran faster than subsequent ones. The logic with Gen 0 molecules not being totally in place initially worked for me.

I got credit for one. Doing another one too.

If you want FaHMon to notice it correctly, open the project data file located in Fahmon config file
with a hex editor. Look for the Hexdecimal 982132. Change the 32 to 64. Save and close.
Reopen FaHMon and the WU is now seen correctly