Gens

[anandhanju]

The FAHWiki link for the definitions of Runs, Clones and Gens is dead and my memory may be a bit rusty but as I recall it, a run is a simulation with a set of variable, a clone indicates this config but at a different point (in time or a folding state?) while gens represent the next step in time in the current simulation.

Assuming this is accurate to some extent, I'd assume that given a Run r, and Clone c, Gen g + 1 wouldn't be ready for computation unless the result for Run r, Clone c and Gen g was evaluated and sent back to FAH (I always imagined this result kicking off the creation of the next gen g+1 and adding it to the To be Folded queue). I found something strange today that contradicts this --

WU 13815, 0, 138, 154 was received for Folding at 10/10/2018 6:42 AM and completed at 10/10/2018 8:23 AM. However, WU 13815, 0, 138, 155 was received by another client at 10/10/2018 8:19 AM.



The logs have cycled and I do not have access to these systems at this time to verify if the system times are in sync. Can anyone shed some light into the possibility of gen g+1 being ready for folding before gen g is complete?

Edit: Corrected Gen number and added image of HFM.NET

[Joe_H]

Basically your understanding of Run, Clone and Gen is good enough. The exact meaning of Runs and Clones may be different for various projects, it depends on what is being simulated. But each Gen does represent aa step in time from the previous Gen.

However the numbers you posted for WU's are the same, so not sure what you saw. What I can see from the database is that particular WU was assigned only once. The previous and following WU's also are separated in time, being completed before and started afterwards respectively.

If you want to check your log files, the client retains both the current one and by default the 16 previous logs in the same directory. The older ones have a time stamp added to their name and are moved to a folder named 'logs'. The time stamp used in the log files is in UTC, not local time.

[bruce]

Consider two possibilities.
> You completed (0, 138,154), returned it. After a minute or two,(0, 138,155) was created and prepared for distribution. Your client happened to request a new WU just then so you happened to process two successive Gens of the same R,C.
> You completed (0, 138,154), returned it. After a minute or two,(0, 138,155) was created and prepared for distribution. It may have been assigned to someone else and it was somehow "lost" and the server figured out that it wasn't going to be returned, so a duplicate was prepared which your client happened to download.

NOTE: It's important that every WU is completed if possible. It's impossible to assign (0, 138,156) unless (0, 138,155) has been returned so in rare cases, the server might duplicate a WU which expires (that's why deadlines are important). The client also attempts to inform the server if it knows a WU is not going to be completed, though that data sometimes gets lost, too, in which case the deadline becomes critical. FAH does not assign duplicate WUs if it can be avoided. Nevertheless, sometimes a duplicated WU is completed twice.

at 6:42 AM (13815,0,138,154) was received.
at 8:19 AM (13815,0,138,155) was received.
at 8:23 AM (13815,0,138,154) was completed.

> You may have a 4 second clock skew between the two clients or the program recording the times might have been busy doing something else.

> Another person processing (13815,0,138,154) might have caused it to be duplicated. The other copy could have been returned before 8:19 so (13815,0,138,155) could have been ready to assign before you completed (...154).