http://www.distributedfolding.com/pr...old_about.html

No comment.

iggiebee is surreptitiously waving his arms at Corso, and pointing to http://www.distributedfolding.com

Is it down forever?
He says he is going to move to another server...

Normal stats page sucks...

Joe! we need you! :)

..........

We just have to wait!

Makes things more interesting IMO. it isn;t as easy to see who your about ot pass or whi is about to pass you. :D Have to get the old pencil and notepad out again. :D

Sun Mar 21 21:47:40 2004 ERROR: [000.000] {foldtrajlite2.c, line 4845} Warning during upload: STATUS 910 MISSING PREVIOUS OR ILLEGAL GENERATION

Sun Mar 21 21:54:56 2004 ERROR: [000.000] {foldtrajlite2.c, line 4845} Warning during upload: STATUS 910 MISSING PREVIOUS OR ILLEGAL GENERATION





????? has my 3.8 hung up ? what do i do i have a ton of val (32) and bz2 (25) files in the directory also i assume that these are compoleted structures and what not any help i hope i dont have to use the filelist.txt file becase there files came from multiple corrupt folders something shit the bed and i coped eveyr thing to one folder opps whell tell me what to do

also can i just dump those files in a worken dir on a diff system so that they upload or it doesnt work that way ? ie.. computer runs off line i burn files to cd can i just drop them in a computer that is online ? and they will upload or what?

The "STATUS 910 MISSING PREVIOUS OR ILLEGAL GENERATION" error is a bad one.

First, a little background. The idea behind DF is not only to try to calculate the correct shape of a protein, but to also see all the steps required to go from a straight chain of amino acids to a fully folded protein. The 'how' of the folding is as important as the final result.

For each of the 251 generations in a complete set, foldtrajlite uploads what the protein looked like at that step. If a step is missing or repeated, the set has little scientific value, so the servers check for that.

If it is a missing generation, there is nothing you can do. That set of 251 is worthless, and filelist.txt should be deleted (unless you have hundred of buffered generations). If it is a repeated gen, careful use of the -purgeuploadlist switch can help, but only if you've saved the directory and haven't tampered with it.

32 and 25 isn't a ton of files. Just delete filelist.txt and start folding again. Buffered gens can't be simply moved to another computer, they have to be a correct sequential set and have their matching filelist.txt. Filelist.txt has some tamper detection lines; don't even try editing it.

A new backend scheme is in the beta stage, it should largely eliminate the 910 errors.

so should i just del the files ? there are no seq

Yeah, you can delete them. If the filename contains your 8-character handle it can be deleted at the same time as filelist.txt. A better plan is a fresh clean folding directory, just in case the illegal generation was caused by some corrupt file (overkill, I know, but I do fresh installs every update).

I've had to delete 4 times in the last few days do to errors, 2 said that the filelist had been tampered with "I know for a fact no one mess with it" and all 4 times I had over 200 buffered.

so i guess i take a loss to the credit ther eis no way to upload them even if only one of the files is bad out of the 70

Actually there is a way of only purging the bad data one at a time; Try to start the client with the argument "-purgeuploadlist 1", stop it, then start it without argument, repeat again and again, until you get rid of the bad data. You will notice the bad data is gone because it will start uploading remainder data with not problems.

Hope it helps!!

Edit: add "stop it" step on procedure

how does it generate the upload list if the filelist.txt is from one dir and eveyrthing else is from 20 other dirs

As far as I can tell there is one client one directory relationship where all data is saved.

Am afraid I do not understand what you mean by data in 20 other directories.??

from multiple systems i clean loaded the whold cluster and backed it all up to one dir

If on a cluster, then I suggest you run the procedure on each system. Moving the data out to other directories do not think it will work.

to late it is all in one folder

however i am running the pricess on the combined folder i have the command in the service.cfg file to hope it runns the stuff in the folder but i think it is dling stuff any way


service=1
useram=1
progress=5
connect=0

It won't accomplish anything to dump an assortment into one directory. Foldtrajlite won't search for, and doesn't care about, any files that aren't in filelist.txt.

The goal for this protein has been changed from 10 billion to 30. Get your points NOW, while the gettin' is easy!

From the offical project forum:Because Generation-0 is random, DF results are ruled by probability. The more sets of generations that are folded, the better the results. There's no final 'true' answer, just a series of better and better aproximations, with more and more detail as to how to get there.

But just like our cooling, there's a point of diminishing returns. With this short protein we have now, structures are 'cheap'. It's an ideal time to see just where that diminshing point is.

In the past, there have been times when a protein was ended short of goal, when results stopped improving like they should. If I was a betting man, I'd say that'll happen this time. 30 billion just gives us room to work.

Plus, running this one a few days longer gives 'em a bit more time to analyze the results of the last one, do more work on the backend-beta, make some improvements to the energy-function/scoring-algorithm, and pick out a protein to do next.

It's all good. :)

And give them time to fix there server? I still have some clients that have 500+ buffered.

Unfortuantly no. They changed the amount well after the protein started because it was getting done so fast otherwise they would have changed it when it was started. Your answer is not good enough anyway even if it was correct. Also I got well over 1000gens buffered that refuse to upload for 24hrs now. One hard drive is maxed out and cannot continue.

I am done for now.

Interesting...I haven't been doing that; I've just been unpacking to separate dirs, and invoking each copy manually (been too lazy to write a proper init script. :p ). I'll have to try that...

A shame to lose you, Jaydee. Why do you think the switch to 30 billion was made? Anything buggin' ya other than the sluggish uploads?