You guessed it, beta 6

[Brian the Fist]

I probably shouldn't call these betas any more since they are stable, so let's call it 'test algorithm #3' or something like that instead. Anyhow, this will hopefully keep those helices and get us to lower RMSDs so please grab it when you get the chance and we'll see what happens. Files are in the same place again.

Please delete filelist.txt and optionally *.log.bz2 and <your handle>*.val

Note that the previous beta is now treated like an 'old protein' even though we're still using the same protein so that means you'll get credit for 24 hrs etc etc (not that its worth anything) and you'll be told in the error.log 'old protein' or what not.

There should be no noticeable changes to you, the user, except hopefully in the results, and it may go a bit faster/slower on some generations. There's also an extra string in filelist.txt you may notice - this may be for future use but is not used - only stored - for now.

Thanks again for all your assistance in making the client better and smarter.

[IronBits]

Thanks Howard. I just started working with your beta client.
Looks interesting indeed.
Thanks for all the hard work!

[m0ti]

Taking a look at the RMS values for the top folds, it's nice to see them dropping like that from generation to generation. Good job!

Are we going to have another go after this one using Crease-Energy or some other non-RMS driven method?

[Digital Parasite]

The latest beta can be downloaded from here:

Linux:
ftp://ftp.mshri.on.ca/pub/distribfol...ux-i386.tar.gz

Windows text client:
ftp://ftp.mshri.on.ca/pub/distribfol...beta-win9x.zip

Windows screensaver:
ftp://ftp.mshri.on.ca/pub/distribfol...beta-win9x.zip


If you want a dfGUI compatiable with the beta versin of the DF client, you can find that here:
http://gilchrist.ca/jeff/dfGUI/dfGUIv22beta.zip

[Digital Parasite]

I noticed you changed the filelist.txt format, what do all the bars mean at the end?

CurrentStruc 0 38 124 4 1 23 11.531 -837.679 177.255 -183.808 4461453.500 0.850 1.500 250.000 -------------------HHHHH------------------------------------------------------------------------


Jeff.

[Brian the Fist]

Originally posted by Digital Parasite
I noticed you changed the filelist.txt format, what do all the bars mean at the end?

CurrentStruc 0 38 124 4 1 23 11.531 -837.679 177.255 -183.808 4461453.500 0.850 1.500 250.000 -------------------HHHHH------------------------------------------------------------------------


Jeff.

As I said if you read my above message carefully.. the new stuff there is not used but is for future use. The keenest amongst you may have realized there are exactly 96 characters, the same as teh number of amino acids in the protein This gives the secondary structure, specifically of the 'seed' structure chosen from generation zero. H means helix, E means beta-sheet and '-' means neither. Thus this should not change after generation zero is done (let me know if it does!). And the H's should match up with the RED sections in gen. 0 of the secondary structure plot for your 'folding movies'. There is probably little point in displaying it in DFGUI if that's what you're thinking...

The main purpose of this may be to help keep the helices that occur in gen. 0 fixed throughout the simulation. This ensures that they will still be there at gen. 250 and won't unfold. Helices in gen. 0 are based on secondary structure prediction, which is typically 80-90% correct for helices so as long as we have a few hundred-thousand users going, most will get fairly accurate helices in gen. 0 and so this in no way diminishes our capacity to find the native state but in fact may increase our chance.

So anyhow that will be the NEXT test, after this one (its never good to change too many things at once after all). We'll let this one go for 10 days or so again first to see how it does, and we find that 'fixing' the helices is not needed.

P.S. you folks are great, I was amazed at how fast you grabbed the new beta. I couldn't get better testers if I was paying them (but don't get any ideas about that... )

[m0ti]

Just out of interest, what do the three laxness levels mean? Are there three different types of conditions that you're testing for this?

[IronBits]

Prolly need recent linkage to stats to.
http://beta.distributedfolding.org

[Brian the Roman]

On one of my clients (the one with the best results of course) it lost it's connection to the net and thus now has 66 gens buffered. When it connects now I get a message saying 'Previous generation missing' and it doesn't upload the results. I tried deleting the first four lines which appear to be from the previous protein, but it then says its been tampered with and won't upload...
Is there anything I can do other than delete filelist and all the data and start again?

Here is the original file:

.\fold_0_okuwe9s5_20_okuwe9s5_protein_237.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_237_0000023.val
.\fold_0_okuwe9s5_0_okuwe9s5_protein_238.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_238_0000003.val
fold_0_okuwe9s5_7560_protein.log.bz2
okuwe9s5_0_protein_0007563.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_1.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_1_0000011.val
fold_0_okuwe9s5_35_okuwe9s5_protein_2.log.bz2
okuwe9s5_0_okuwe9s5_protein_2_0000039.val
.\fold_0_okuwe9s5_0_okuwe9s5_protein_3.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_3_0000005.val
.\fold_0_okuwe9s5_30_okuwe9s5_protein_4.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_4_0000031.val
.\fold_0_okuwe9s5_5_okuwe9s5_protein_5.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_5_0000006.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_6.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_6_0000050.val
.\fold_0_okuwe9s5_5_okuwe9s5_protein_7.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_7_0000008.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_8.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_8_0000013.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_9.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_9_0000015.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_10.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_10_0000048.val
.\fold_0_okuwe9s5_40_okuwe9s5_protein_11.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_11_0000045.val
.\fold_0_okuwe9s5_30_okuwe9s5_protein_12.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_12_0000031.val
.\fold_0_okuwe9s5_30_okuwe9s5_protein_13.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_13_0000034.val
.\fold_0_okuwe9s5_20_okuwe9s5_protein_14.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_14_0000025.val
.\fold_0_okuwe9s5_15_okuwe9s5_protein_15.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_15_0000018.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_16.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_16_0000015.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_17.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_17_0000046.val
.\fold_0_okuwe9s5_5_okuwe9s5_protein_18.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_18_0000007.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_19.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_19_0000013.val
.\fold_0_okuwe9s5_15_okuwe9s5_protein_20.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_20_0000018.val
.\fold_0_okuwe9s5_20_okuwe9s5_protein_21.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_21_0000025.val
.\fold_0_okuwe9s5_40_okuwe9s5_protein_22.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_22_0000043.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_23.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_23_0000050.val
.\fold_0_okuwe9s5_35_okuwe9s5_protein_24.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_24_0000038.val
.\fold_0_okuwe9s5_35_okuwe9s5_protein_25.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_25_0000039.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_26.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_26_0000049.val
.\fold_0_okuwe9s5_5_okuwe9s5_protein_27.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_27_0000006.val
.\fold_0_okuwe9s5_0_okuwe9s5_protein_28.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_28_0000004.val
.\fold_0_okuwe9s5_0_okuwe9s5_protein_29.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_29_0000002.val
.\fold_0_okuwe9s5_40_okuwe9s5_protein_30.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_30_0000045.val
.\fold_0_okuwe9s5_0_okuwe9s5_protein_31.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_31_0000004.val
.\fold_0_okuwe9s5_25_okuwe9s5_protein_32.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_32_0000028.val
.\fold_0_okuwe9s5_35_okuwe9s5_protein_33.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_33_0000036.val
.\fold_0_okuwe9s5_15_okuwe9s5_protein_34.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_34_0000016.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_35.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_35_0000015.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_36.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_36_0000048.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_37.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_37_0000047.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_38.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_38_0000013.val
.\fold_0_okuwe9s5_0_okuwe9s5_protein_39.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_39_0000004.val
.\fold_0_okuwe9s5_25_okuwe9s5_protein_40.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_40_0000028.val
.\fold_0_okuwe9s5_5_okuwe9s5_protein_41.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_41_0000008.val
.\fold_0_okuwe9s5_40_okuwe9s5_protein_42.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_42_0000041.val
.\fold_0_okuwe9s5_5_okuwe9s5_protein_43.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_43_0000008.val
.\fold_0_okuwe9s5_30_okuwe9s5_protein_44.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_44_0000035.val
.\fold_0_okuwe9s5_30_okuwe9s5_protein_45.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_45_0000033.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_46.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_46_0000011.val
.\fold_0_okuwe9s5_20_okuwe9s5_protein_47.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_47_0000024.val
.\fold_0_okuwe9s5_30_okuwe9s5_protein_48.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_48_0000034.val
.\fold_0_okuwe9s5_20_okuwe9s5_protein_49.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_49_0000022.val
.\fold_0_okuwe9s5_30_okuwe9s5_protein_50.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_50_0000031.val
.\fold_0_okuwe9s5_35_okuwe9s5_protein_51.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_51_0000038.val
.\fold_0_okuwe9s5_35_okuwe9s5_protein_52.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_52_0000039.val
.\fold_0_okuwe9s5_10_okuwe9s5_protein_53.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_53_0000011.val
.\fold_0_okuwe9s5_5_okuwe9s5_protein_54.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_54_0000009.val
.\fold_0_okuwe9s5_15_okuwe9s5_protein_55.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_55_0000017.val
.\fold_0_okuwe9s5_0_okuwe9s5_protein_56.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_56_0000001.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_57.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_57_0000049.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_58.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_58_0000048.val
.\fold_0_okuwe9s5_5_okuwe9s5_protein_59.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_59_0000007.val
.\fold_0_okuwe9s5_0_okuwe9s5_protein_60.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_60_0000004.val
.\fold_0_okuwe9s5_40_okuwe9s5_protein_61.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_61_0000042.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_62.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_62_0000047.val
.\fold_0_okuwe9s5_45_okuwe9s5_protein_63.log.bz2
.\okuwe9s5_0_okuwe9s5_protein_63_0000049.val
CurrentStruc 0 51 124 63 0 49 5.967 -3329.308 -413.197 -1829.092 194678336.000 1.200 2.200 665.002 ----------------------HHHHHHHHH-----HHHHH-------------------------------------------------------
542b78f7a9045590bb81d5e861d8f3cd

[AMD_is_logical]

Brian the Roman, it looks like you didn't delete the old work (including filelist.txt) before starting the beta6 client.

I don't know of any way to recover at this point. Maybe someone else does.

I've been somewhat concerned by the fragility of the beta client in this regard. Most of the time it runs great, but if something does go wrong, the client will happily keep going (if offline), even though all future work is unrecoverable.

I suspect that once this client is released as non-beta, there will be a number of cases where people will no-net for extended periods of time, only to have it all lost due to some minor glitch. You can't recover work by reconstructing filelist.txt like with the old client.

[Brian the Roman]

I know I deleted most of the stuff, I think I may have forgotten to delete filelist.txt itself (the most important of the bunch, of course).

ms

[Guff®]

Originally posted by AMD_is_logical
You can't recover work by reconstructing filelist.txt like with the old client.

I found this out last night while downloading the new beta client to all of my systems. Found one system with a boatload of work that had not been uploaded. It had a network snag of some sort, so I rebooted and tried again. Still nothing. Deleted the fileslist.txt and rebuilt it. Got an error message that the "fileslist.txt had been tampered with". Well, duh. I know that, I did the tampering. Error message said to delete the filelist.txt and restart. I did that and it still failed to upload anything. Just trashed all of the files, extracted the new beta version and started over. What a waste.

[bwkaz]

It would be nice to know what kind of signing is done on the filelist.txt (I assume it's some sort of digital signature), for that very problem.

Obviously, if the signing requires a private key of some sort, then it can't be imitated in these cases, but if it's just something simple like MD5, then that'd be easy to re-sign. Just create a filelist.txt without the signature, run md5sum on it, and append the output to the file.

Blast, it's not just MD5 (I just tried running md5sum on all but the last line of the file, and the signature is the same length, but not the same characters).

[m0ti]

I did some prelim testing for dfQ for the beta (well, for when it stops being a beta) and in order to support orphan recovery you pretty much need the ability to create a vlalid filelist.txt.

Yup, tried md5 too, then got out util which does like 10 different types of hashes, set it to 128 bit length and none of them checked out...

My guess is that they're using a private key as well.

[Aegion]

Originally posted by m0ti
I did some prelim testing for dfQ for the beta (well, for when it stops being a beta) and in order to support orphan recovery you pretty much need the ability to create a vlalid filelist.txt.

Yup, tried md5 too, then got out util which does like 10 different types of hashes, set it to 128 bit length and none of them checked out...

My guess is that they're using a private key as well.

This pretty much involves project security and preventing cheating. These factors probably outweigh third party software being able to support orphan recovery. Its good that the digital signature is secure and you are unable to break it when looking at the big picture for the project.

[tpdooley]

If it does manage to get corrupted - then perhaps we'll start to see automated backup software setup.. backing up filelist.txt, .val.bz2, .log.bz2, etc every 5, 10 generations. So at worst you've gone from say.. generation 209 back to 200, instead of back to generation 0.

[m0ti]

Originally posted by Aegion
This pretty much involves project security and preventing cheating. These factors probably outweigh third party software being able to support orphan recovery. Its good that the digital signature is secure and you are unable to break it when looking at the big picture for the project.

I agree with that statement though I think it would have been simpler to do the archiving themselves, instead of using filelist.txt to do the pairs.

Look inside a log file (log.bz2) you can see that it lists the numbers of structures made, and that the file is also protected by a hash of some sort. Considering that each log file has a val file (containing the actual fold) to go along with it, I would have expected these to be archived together and protected as a unit.

It appears to me that filelist.txt is being used for three purposes:

1) Pairing the files to be uploaded (log with val).

2) Listing the files to be uploaded.

3) A location for saving additional information on the current state of the current fold.

I think that these 3 functions have been arbitrarily put together in a single location. It would (IMO) be preferable to do the pairing ahead of time (ie archive the val and log files together with suitable protection), do the listing of these files for upload in filelist.txt (which probably wouldn't require protection then), and a second file (state.txt?) for storing state info.

Just my 0.02.

[pointwood]

I'll start running this new beta monday on a P4 2Ghz.

[IronBits]

[IronBits]

I'm not having any problems Howard, except it sure is taking a long time to get 250 generations.
At the current rate, with an xp2100, it's gonna take me 6 days to complete. Using all w2k.
When I tried to run it on the two Mandrake clients, it complained about not having some ncurses libraries or something and wouldn't run

[AMD_is_logical]

Originally posted by IronBits
When I tried to run it on the two Mandrake clients, it complained about not having some ncurses libraries or something and wouldn't run

Is it complaining about not having libncurses.so.4 ? If so, check your /lib directory to see if you have a libncurses.so.5 file. If so, try making a link (or just copy the file if you prefer) to create the libncurses.so.4 file.

[IronBits]

Thank you, that worked!

[m0ti]

Just wondering, but from my own folding it seems that I got my best fold somewhere in the first 50 gens (I think around gen 30), and since then it hasn't improved at all. This makes me somewhat feel that the later generations are somewhat a "waste of time" (in this case) and I could be producing more worthwhile results if I restarted from gen 0. I guess this goes back to what we said before about convergence, it may be a good idea to stop a current line if no better fold has been found in the last X gens. I guess you'd have to look at the statistics of it to determine if it really would be better.

[Digital Parasite]

moti, I have found that some of my clients keep getting better and better until the end (ie: best value was in gen 250) but some of my other clients have been like yours were they get to about gen 50-60 and after that it never seems to improve. Not only that but the results are not very good (RMSD of 8.x). It really wants to make me stop the client and start that one over.

Jeff.

[Brian the Fist]

Most of what you say is correct here. The filelist.txt is now prevented from tampering, for many reasons but mostly to discouraging cheating (which won't work anyways) and to give me less potential problems of people trying to mess around with it who don't understand its format.

When you switch to a new protein (which we haven't really officially done with the beta, its still the same one over and over) I will have to fix that, that is a bug. Instead of saying unable to find previous generation when you upload the previous protein it should just accept the data like it normally does and give you the credit or half credit as appropriate. Ill add it to my list of changes.

I'm glad no one was able to 'crack' the signature yet either, that give me a little reassurance at least. Generally there should be no need to edit filelist.txt unless you start going around deleting files or something, no one has reported any problems with filelist.txt for several beta versions now so I assume it is all working (aside from the above problem) fine and consistent for online and offline users, modem users and high speed ones.

In response to the # gens., the 250 may still change or become variable but remember, RMSD is just a single global number summarizing a whole protein conformation. So do not be fooled by the fact that your RMSD is not changing much/going up. The protein could still be moving a lot (check the movie file). Suppose for example it fold into an incorrect but compact fold (a quite likely scenario). It must then un-fold a certain degree before it can repack in a different configuration that may be the correct one. Thus the RMSD must go up again before it can come back down. For this reason it is unwise to terminate a simulation early just because it looks like nothing constructive is happening. No single quantity can tell us this sort of information, we just have to let it keep running and see what happens.

[m0ti]

Originally posted by Brian the Fist
In response to the # gens., the 250 may still change or become variable but remember, RMSD is just a single global number summarizing a whole protein conformation. So do not be fooled by the fact that your RMSD is not changing much/going up. The protein could still be moving a lot (check the movie file). Suppose for example it fold into an incorrect but compact fold (a quite likely scenario). It must then un-fold a certain degree before it can repack in a different configuration that may be the correct one. Thus the RMSD must go up again before it can come back down. For this reason it is unwise to terminate a simulation early just because it looks like nothing constructive is happening. No single quantity can tell us this sort of information, we just have to let it keep running and see what happens.

While I do realize that this is the case it's again a similar question to the time trick used by amd-is-logical. I was just wondering if it might be more worthwhile to give up on the current 250 gen progression than to continue it, probabilistically speaking? For example: if we find that in 80% of the top 100 folds that the longest number of generations without improvement was 50 we might want to set the variable to 75 so that we can be sure that we are getting the vast majority of the top folds and not wasting time.

[IronBits]

Thermometer is not working on the beta stats

[arjanscholl]

Originally posted by IronBits
Thermometer is not working on the beta stats

It's working just fine, we just havn't created enough structures yet to make it move up

[m0ti]

how long is "normal" for a fold to be stuck? I've had one that's been stuck for about 11 hours now.

[IronBits]

2 days, 18 hours, 56 minutes and I'm at 45%
xp2100 w2k

[CSMan]

Originally posted by IronBits
2 days, 18 hours, 56 minutes and I'm at 45%
xp2100 w2k

2 days, 18 hours, 31 minutes and I'm at 32% Be glad you're not stuck with my XP1800

[mighty]

On the current beta-protein (96aa) the current beta is using various amounts of memory. I'm running with the -rt switch, and I have seen memory usage as high as 136MB and as low as 36MB.
Are these huge fluctuations to be expected?

I am currently on gen. 101 and the average generation time is 43 minutes, running on an Athlon 2100+.

[m0ti]

Originally posted by m0ti
how long is "normal" for a fold to be stuck? I've had one that's been stuck for about 11 hours now.

ok it went through!

[IronBits]

It seems to hang for a very long time just after 95ish until just past 100 or there abouts...
ahhhhh... progress
I haven't payed any attention to how much memory is required.
I have 512mb of DDR in all my 'work/game' boxen and 256mb DDR in my crunchers.

[m0ti]

for the regular stats, could we also have a column for what generation the best fold was found at?

I finally beat my previous best!

[Scoofy12]

dont we already on http://beta.distributedfolding.org/ ?

[m0ti]

Originally posted by Scoofy12
dont we already on http://beta.distributedfolding.org/ ?

only the top 10... I was thinking in the team stats.

[IronBits]

On the computer that generated the 5.24, working on the same work unit, it now shows 5.301

[Welnic]

Originally posted by m0ti
only the top 10... I was thinking in the team stats.

The generation number posted on the top ten is not the generation that the best RMS came from. It is how far the series that the best number came from has gotten to. You will first see a number come up and then the generation keeps increasing while the number stays the same. If you download the whole movie there is a plot in there that has the RMS vs generation, and it does not steadily go down.

The movie is at the view details link next to the best structures. You can see that IronBits' best RMS came about generation 84 and it hasn't done any better by generation 131. At least when I just looked at it.

[m0ti]

Oops, yeah you're right.

Ok then, brand new feature: column for what gen the top fold was found (in top 10 and also in regular stats).

Thanks!