 |
| [AMD Users] Michal Hajicek 2003-06-19 10:56:48 | Hi Stephen (and others), some time ago in another thread 1 2 you told us that manual seeding is not possible for v4.3+ (due to results checksum) and is planned much later, if ever. But it works! But the way it works is very strange. I was working on it a few days (better cPU needed), here's the report. And everything was tried also with fresh client installation. tested versions: mainly 4.31c, (also 4.3 and 4.31b a bit) client type: commandline modified files: both results.dat and queue.txt, most testing and all results obtained through queue.txt loop ----------------- 1. Results can be manually modified (even the checksum itself). 2. The 'result rejected - bad checksum' error appears only in a few cases (randomly) - every modified result can cause this error, but when the client is restarted e.g. 30 times with same modified results.dat, the error occurs e.g. 3 times (or if you let the client be, the error appears after e.g. fifth run(.dat loading)). So to completely avoid client crash, correct checksum is needed, see 4. 3. Some parameter changes (especially DxxL series value decreasing) can cause the client to report bad number of beamline units after queue.txt loading (parameter count increases, missing values are random generated). If this increase occurs, after one rechecking run the missing parameters are appended to the end of the queue.txt line, so it looks like this: ...S26F=xxx;#runs=xxx;S26d=... and afer another run the runs increases correctly (order independent parsing?) Changing number of params manually doesn't work (units count won't change) in most cases (except param increase with help of dxxl value decrease). 4. Safe way to manualseeding: (I think it's better to let the client to recheck it, also correct checksum is generated at the end of the run) a) edit queue.txt - change params, set runs variable to 1 b) start the client - if no error appears and number of units is correct, go to c) c) let the client run the edited parameter set once d) delete first percentage (guessed), decrease Mpts by initial Mpts, set runs to 1 again, this will cause better precision, but lowest/highest yield is cut off when final result is generated, so i think you can let it be (but don't set initial Mpts too high then- it would be cheating) e) let the client recheck normally f) I'm sure results generated this way are correct, and also correct autogenerated (evolved) consequent genomes follow (tested) 5. These results (queued) passes through the client, and also through manualsend (one results.txt-checksum overwritten with cccccccc), which is correct only for queue.txt-modified ones. (see statistics and database - manualseeded ones has this comment: 'MHmanualseed'). So the checksum stuff is strange and useless, although cheating was not tested. ----------------- Hope this helps. (Maybe it's the third message I'm describing functionality of the program to its author, who knows it of course (another thread), but I hope this is not the case, 'cause nobody wants to be awkward, of course.) Michal Edited many times so not much consistent. |
| Stephen Brooks 2003-06-20 08:21:58 | Found what's causing this error. Basically at some stage I decided that doing the full checksum calculation for every record, especially in a long .dat file, was too time consuming. So at that stage since all I was thinking about was cheaters, I decided I'd do "spot checks" of 1 in 20 of records, and if one was ever found that had a bad checksum, I'd then check it on all subsequent ones. Thus it would be fast reading correct files - a _few_ bad checksums might slip through - but people who cheat regularly would be picked up on. But since I then continued to write the code on the assumption that the routine really _did_ check the sum on every result, some odd behaviours resulted. What I might do is make it check every result, and then provide another facility for a user to insert just a _design_ into the program, with no score or checksum. For instance, I could make it so that if the 2nd line of the result in queue.txt just read "TEST", the computer would simply take it as an input command (as if it had #runs=000 I suppose). Today's weather in %region is Sunny/(null), max. temperature #NAN°C |
| [AMD Users] Michal Hajicek 2003-06-22 05:18:16 | OK. And the 'd--l and s--l and unit count' thing: everything is OK, because this part of apparatus has some minimal and maximal length, so some combinations of these params are not allowed. Is that right? |
| [DPC]Stephan202 2003-06-22 09:35:46 | Well, what if the configuration Michal described elsewhere (57 units, tz=500 tr=000, s-lrf=999,d-l=000) is a legal combination of params? Then I start to wonder why this 'easy' configuration hasn't been tested right away, instead of using the client to let the configurations mutate and evolve. The configuration mentioned above has a yield of over 14%. Which is higher than archieved so far useing the evolution of results. Isn't there some very simple way to reason this configuratiopn, just by looking at the part of the machine we are simulation now? --- Dutch Power Cow. MOOH! |
| [AMD Users] Michal Hajicek 2003-06-22 10:19:55 | I agree with your questions. This simple design is something like Stephens boost-result added in previous Muon1 sim (v4.2x - 2.5%). As mentioned by Stephen (if i can remember - see mailing list for v5 thread), this stage is mainly for testing new code/features (also a short general solenoidonly sim), etc. and has not so big importance (don't beat me if it's not true, Stephen). And let everything run from scratch ensures many paths are tried (and maybe found something nontrivial). Also publishing design like this at the beginning would decrease people's interest a bit i think, because this would reduce everything to finding if there's something better in the param space, with nearly no progress (but it could be also a 'competition' against it) - edit - the above mentioned thread - v4.22 results could be a kickstart for this 4.3x sim - didn't happen. ??? Michal [This message was edited by [AMD Users] Michal Hajicek on 2003-Jun-22 at 19:35.] |
| Stephen Brooks 2003-06-22 12:24:19 | The v4.21 -> v4.3 seeding might not have happened because of checksums being different between the two, although actually if the current client allows seeding anyway you could still try it. Yes, that "trivial" design could be our best one for this particlar run. I tried the trivial one in an earlier version of Muon (with the bending chicane added I think), and it turned out to be non-optimal. The reason it could be optimal here is that there is no restriction on the end of the solenoid channel - I was asked to find out what the channel _on its own_ could do, so I just put that in and ran it. Later this summer I think I'll start another optimisation with the last component being forced to be a 10cm radius solenoid (i.e. it is forced to narrow down to a certain size). Hopefully that will have some more useful results and be less of an anticlimax. But as you say, the primary purpose of the current phase (pre-v5) is to get the code working really smoothly so I'm then at a point to pose the serious challenges with muon-cooling etc. included in them. The interesting point this raises is whether there could be a quicker way to get Muon1's optimisation engine to push all parameters simultaneously to those kinds of extreme values. It might be worth adding a special sort of mutation that simply makes values "more extreme" to see if that helps, because in a typical run you'll get some parameters having to be at their extreme values for the optimum, whereas some others will have a value in between. Today's weather in %region is Sunny/(null), max. temperature #NAN°C |
| Pollock[Romulus2] 2003-06-26 11:24:37 | quote: That gave me an idea, dangerous as that may be.  One of my machines had been 'stuck' at 9.90 for a week and showed no sign of improvement. I copied a random result from the .dat file and changed all of the parameters to 999 or 000 alternately. Then changed the score to a number that would be higher than anything in the file and gave it a wierd checksum. The creation: tantalumrodz=999;tantalumrodr=000;s1l=999;s1f=000;d1l=999;s2l=000;s2r=999; s2f=000;d2l=999;s3l=000;s3r=999;s3f=000;d3l=999;s4l=000;s4r=999;s4f=000; d4l=999;s5l=000;s5r=990;s5f=000;d5l=999;s6l=000;s6r=999;s6f=000;d6l=999; s7l=000;s7r=999;s7f=000;d7l=999;s8l=000;s8r=999;s8f=000;d8l=999;s9l=000; s9r=999;s9f=000;d9l=999;s10l=000;s10r=999;s10f=000;d10l=999;s11l=000; s11r=000;s11f=999;d11l=000;s12l=999;s12r=000;s12f=999;d12l=000;s13l=999; s13r=000;s13f=999;d13l=000;s14l=999;s14r=000;s14f=999;d14l=000;s15l=999; s15r=000;s15f=999;d15l=000;s16l=999;s16r=000;s16f=999;d16l=000;s17l=999; s17r=000;s17f=999;d17l=000;s18l=999;s18r=000;s18f=999;d18l=000;s19l=999; s19r=000;s19f=999;d19l=000;s20l=999;s20r=000;s20f=999;d20l=000;s21l=999; s21r=000;s21f=999;d21l=000;s22l=999;s22r=000;s22f=999;d22l=000;s23l=999; s23r=000;s23f=999;d23l=000;s24l=999;s24r=000;s24f=999;d24l=000;s25l=999; s25r=000;s25f=999;d25l=000;s26l=999;s26r=000;s26f=999;d26l=000;s27l=999; s27r=000;s27f=999;#runs=005; 18.000000 (1037.4 Mpts) [v4.31c] {ABCD1234} So far, it has generated all zeros but every run has changed a different parameter to 000 or 999, leaving the rest mostly the same. this is not what you were referring to, but it is making it try some more extreme values. No idea whether it will find anything worthwhile, it may be just maxxed out, but it seems worth a try. Ok, bad idea. It eventually triggered a checksum error and crashed while reading the .dat file. I should have read the posts above more carefully. I am not sure why a bad checksum in the .dat file should be a problem, though. Unless it is in the results.txt or in a queue.txt file it would never be submitted. [This message was edited by Pollock[Romulus2] on 2003-Jun-26 at 21:29.] |
| Mike Malis 2003-06-26 14:22:40 | I noticed that when I look at the 3- dimentional plots of tantalum rod "Z", tantalum rod "R", and muon percentage that there is an extremely hyperbolic or exponential curve for muon percentage associated with tantalum rod "Z" while tantalum rod "R" remains "000". All of the best muon transer percentages across the board happen when tantalum rod "R" is 000. This may indicate that this is the best configuration (at least for tantalum rod "Z"). Does anyone else have a pattern that follows a tantalum rod Z is "xxx" pattern for their most optimal muon transfers? Mike Malis |
| Mike Malis 2003-06-26 14:26:45 | Mistype (I am drunk right now) On the second to last sentence (at least for tantalum rod "R") is what I meant to say. Mike Malis |
| Mike Malis 2003-06-26 14:29:50 | Also, the the last sentence whre "R" should be "Z". Sorry about the confusion. Mike Malis |
| Mike Malis 2003-06-26 14:33:07 | Or ratrher, "Z" should be "R". See, this is why drinking too much is bad! Mike Malis |
| Pollock[Romulus2] 2003-06-26 17:18:13 | Hmmmm, JD for dinner, never thought of that.  Every result I've seen over 5.00% has a 'z' value at or near 500 and an 'r' value at or near 000. Good Point. |
| Mike Malis 2003-06-28 04:00:38 | I am currently at about 3.3% and Z=450 and R=000. It was JD.....good guess. Stephen, Can you create a plot for all of the results that you have received with x-y-z axis of tantalum rod r & z and muon percentage like the ones you did with muon percentage and Mpoints? Mike Malis |
| Goner 2003-07-07 00:52:02 | is it possibly to put this checksum in a script or something, so we can check downloaded result.dat and remove bad entries ?? this weekend 4 of my pc's at work crashed on this ... -- Goner - [DPC]TeamNWW |
| Stephen Brooks 2003-07-07 12:56:37 | Posting this as guest... Opera 6 keeps saying "Connection closed by remote server" when I try to post as registered. Bad entries shouldn't really cause a crash - they should be ignored by the program. There's a separate issue with some genomes making the program produce "117 units" in a beamline (some sort of error) and that causes a crash, but as far as I know that is not related to the checksum issue. |
