Beta 7 (or algorithm # 3.5)

[Mikus]

When I look at file progress.txt, its contents sometimes "lag" behind what is being shown on the DF screen. For instance, just now progress.txt says "structure 31" whereas the DF screen has said for minutes "Beginning struc. #35". The only flags I'm using in foldit are '-df -rt'.

mikus (using Linux)

[Digital Parasite]

Originally posted by Mikus
When I look at file progress.txt, its contents sometimes "lag" behind what is being shown on the DF screen. For instance, just now progress.txt says "structure 31" whereas the DF screen has said for minutes "Beginning struc. #35". The only flags I'm using in foldit are '-df -rt'.

I believe the default is for the DF client to update the progress.txt file every 5 structures so after your client hit #36 it would have written that to the progress.txt file. If you want it to update after it completes every structure add '-g 1' to your flags. Where 1 is the number of structures before and update.

JEff.

[IronBits]

Distributed Folding Project Statistics
as of: Mon Apr 28 11:01:29 2003 EST

[Grumpy]

A user with OCworkbench has had a problem upload after Folding with net access disabled.. Message follows

"Over the weekend Distrbfold servers were down so I disabled internet access... I just tied to upload and got this error again...

========================[ Apr 28, 2003 10:14 PM ]========================
ERROR: [000.000] {foldtrajlite2.c, line 3861} Cannot find structure from previous generation t31ti7ma_0_t31ti7ma_protein_185_0000043_min.val.bz2; find it manually or delete filelist.txt to continue
ERROR: [000.000] {foldtrajlite2.c, line 4019} Error during upload: Previous generation missing"

A couple of people have had this now trying to just upload with DFGUI

[Slo]

Hello...

I have a problem and it is the second time... The first time I deleted my beta directory and started fresh... I do not really wish to do it again...

During the time the server was down I disabled internet access and folded the last 66 generations of the 250... I started at generation 0 again then reconfigured to to enable internet access... I then opened the GUI and instead of uploading I got this error...

========================[ Apr 28, 2003 10:31 PM ]========================
ERROR: [000.000] {foldtrajlite2.c, line 3861} Cannot find structure from previous generation t31ti7ma_0_t31ti7ma_protein_185_0000043_min.val.bz2; find it manually or delete filelist.txt to continue
ERROR: [000.000] {foldtrajlite2.c, line 4019} Error during upload: Previous generation missing

The first .val.bz2 file in the folder is protein_199 and apperently upload is looking for protein_185...

I have a 40MB zip of the beta folder but do not have enough host space to upload it to and your board limit on attachments is 10MB...

As I said this problem occured twice so I need to solve it and not just delete it again...

Thanks for your help,
Slo...

[Brian the Fist]

I will look into possible causes of this problem. In the mean time, do as it says and look for the file - do you see any files with SIMILAR but not exactly the same filename to the one stated?

[Slo]

Thank you for looking into it... I made a jpeg of the folder the url is===

http://www.transload.net/~slotype/TESTS/Beta-folder.jpg


Slo...

[Paratima]

Originally posted by Grumpy
Ok Howard, I have a good one for you. My RMS scores are getting bigger now that I have passed Gen 150. And bigger and bigger. At this rate they will be back at the Gen 0 figures . Is this meant to happen on 2 separate computers..I hate coincidence

Just hit my lowest so far, which just happens to be THE lowest so far, at ~Gen 220.

[Digital Parasite]

Originally posted by Paratima
Just hit my lowest so far, which just happens to be THE lowest so far, at ~Gen 220.

The 5.35 seems to be the magic barrier so far.

Howard: So what is the latest news on the beta algorithm, do you have other tweaks to try?

Jeff.

[Brian the Fist]

Originally posted by Digital Parasite
The 5.35 seems to be the magic barrier so far.

Howard: So what is the latest news on the beta algorithm, do you have other tweaks to try?

Jeff.

Actually 4.5 was the best in best 5 I believe. The helices are still unravelling towards the end, though they are staying longer. I think this is due to yet another very subtle bug which causes slight drift over time, which I now fixed. The next beta is ready with what will likely be the final tweaks but Im still fixing some of the bugs reported above with last generation missing etc. before I release it.

[Brian the Fist]

Originally posted by Slo
Thank you for looking into it... I made a jpeg of the folder the url is===

http://www.transload.net/~slotype/TESTS/Beta-folder.jpg


Slo...

It would also be useful for me to see the contents of your filelist.txt

[Digital Parasite]

Originally posted by Brian the Fist
Actually 4.5 was the best in best 5 I believe.

Sorry, I meant 5.35 was the best RMSD that we could do for this round of beta testing.

Jeff.

[Slo]

Here you go Howard...

I should mention that I did start a 0 generation... I then downloaded a new set of files into a new folder and let this one be...


http://www.transload.net/~slotype/TESTS/filelist.txt


Thanks,
Slo...

[Mikus]

I use dial-up to connect to the internet, and I do not leave the connection up when there is nothing to browse/download/upload. Also, I do not use an auto-dialer -- I've seen them endlessly looping when a persistent circuit_failure situation occurs.

With the old client, I can roughly predict when the current fileset will be completed. When I want to upload my work, I start watching the DF screen as the structures total gets close to a fileset boundary value -- and I can do the manual dial-up "just in time".

----

With the beta 7 client, I can __not__ predict when the current generation will be completed. The client happened upon a situation where on every structure it got "stuck" with the screen saying "Calculating residue 96 of 96" (the first 96 was 'vibrating'), and the "alternate conformation" kept advancing to 280,000+ over and over and over and over and OVER again.
[The utter futility of this client behavior was shown by it not being able to improve the energy value (structure after structure) below 6.4 ]

All I could do was to keep glancing at the DF screen to try to catch the completion of the generation. After 20 minutes or so I simply could not keep up this degree of watchfulness any more. The result was that all of a sudden the client was building structure 1 of the (equally tiresome) next generation. Only the next day was I (by luck) able to synchronize doing a dial-up in time to let the beta 7 client upload its completed generations.

I suppose I might dial up, then stop the beta client, then issue 'foldit -u t' to have the client upload what it has completed, then issue a "normal" 'foldit' so the client starts folding again. But that is a lot of bother, merely to allow me to do the upload when _I_ am ready (instead of me having to dance attendance on the client).

mikus (running on Linux)

[Brian the Fist]

Originally posted by Mikus

I suppose I might dial up, then stop the beta client, then issue 'foldit -u t' to have the client upload what it has completed, then issue a "normal" 'foldit' so the client starts folding again. But that is a lot of bother, merely to allow me to do the upload when _I_ am ready (instead of me having to dance attendance on the client).

mikus (running on Linux)

That IS the intended method. However, since you are fortunate enough to be running Linux, if you (or a friend) know a little PERL/shell scripting, you should be able to write a simple cron job (for example) to once a day quit foldit (by removing the lock file and waiting 10 seconds or so), dial up, start foldit with the -ut, wait until its done, then hangup and restart with -if again. I believe others have already created such scripts so perhaps someone on the forum here can comment further.

[Brian the Fist]

The next (and possibly final) beta will be available shortly. I have adjusted the algorithm one more time and have fixed some bugs with file uploading/tracking.

I would request that while beta testing you do NOT use dfGUI please. Beta testing two pieces of related software simultaneously is just asking for trouble. I'd request that you refrain from testing dfGUI until we are sure all the major bugs from the client are worked out. As it is now, I am unable to distringuish true bugs from bugs caused (inadvenrtantly of course) by dfGUI. It will be to everyone's benefit if we ensure the client is fully stable and robust to abuse before dfGUI can be made the same. Please do not report any bugs in the beta if you are using dfGUI. Please DO report bugs otherwise.

Also, please remember when reporting a suspected bug, please post your full filelist.txt (x out your handle though if you wish), your full error.log (at least the relevant part up until the end of the file) and as clear a description of the problem as possible. Also important, please note all flags in the foldit script you have used, if any as these often play an important role in the bugs (since I cant possibly test all combinations of flags).

Thanks for your continued co-operation and I suspect this may well be the last change to the algorithm before we try it on a much larger scale (i.e. release it).

[AMD_is_logical]

Originally posted by Brian the Fist
That IS the intended method. However, since you are fortunate enough to be running Linux, if you (or a friend) know a little PERL/shell scripting, you should be able to write a simple cron job (for example) to once a day quit foldit (by removing the lock file and waiting 10 seconds or so), dial up, start foldit with the -ut, wait until its done, then hangup and restart with -if again. I believe others have already created such scripts so perhaps someone on the forum here can comment further.

Shell scripts work fine for uploading. I don't consider it safe to wait a fixed amount of time for the exit, however. So what I do is to have the crunching script create a file that I arbitrarily call "df.lock" just before running the client, then remove this file just after the client exits. The upload script can then remove foldtrajlite.lock and wait for df.lock to disappear:

while test -e df.lock
do sleep 1
done

The script can then do the upload (using -ut) and when that finishes it can restart the offline crunching script.

In my case, uploading and crunching are on two seperate machines using a common NFS, so the upload script on the server creates a lockfile I call "up.lock" when it starts and removes it when it's done, and the crunching script on the node waits for up.lock to disappear, then restarts the cruncher.

[Paratima]

Also, don't forget to remove all your locking-type files, including foldtrajlite.lock, in the event of REBOOT.
It does happen, ya know.