 |
| waffleironhead 2007-12-13 03:32:14 | I was looking over my results.txt for 4.44 and noticed these two results. I'm not sure what could have caused 2 0.0 mpts results. If I set them up as a test queue they run fine, but for some reason they didn't at that time...I'll try to keep an eye on it and see if I notice it happening again. I am running a fresh install using the commandline version. Any ideas on what may have caused them? tantalumrodr=191;tantalumrodz=345;d1l=745;d2l=809;d3l=748;d4l=600;d5l=577;d6l=953;d7l=970;d8l=535;d9l=320;db1l=585;decaycells=604;pd1=000;phaserotcells=397;prf1p=263;prf1v=434;ps1f=979;ps1l=636;s1f=815;s1l=889;s2f=742;s2l=690;s2r=721;s3f=812;s3l=170;s3r=577;s4f=579;s4l=282;s4r=579;s5f=227;s5l=356;s5r=588;s6f=262;s6l=599;s6r=741;s7f=742;s7l=689;s7r=502;s8f=999;s8l=565;s8r=254;s9f=921;s9l=403;s9r=138;sb1f=999;sb1l=551;sb1r=448;#gen=7; -2.000000 (0.0 Mpts) [v4.44] <PhaseRotEb1> {F1F8FD1EB5675ADA3CB4EE52} tantalumrodr=051;tantalumrodz=450;d1l=004;d2l=000;d3l=004;d4l=000;d5l=000;d6l=000;d7l=000;d8l=000;d9l=050;db1l=000;decaycells=496;pd1=000;phaserotcells=646;prf1p=174;prf1v=910;ps1f=999;ps1l=576;s1f=909;s1l=897;s2f=893;s2l=735;s2r=715;s3f=827;s3l=384;s3r=616;s4f=608;s4l=330;s4r=490;s5f=153;s5l=416;s5r=559;s6f=183;s6l=671;s6r=744;s7f=795;s7l=757;s7r=526;s8f=994;s8l=448;s8r=523;s9f=994;s9l=398;s9r=203;sb1f=994;sb1l=570;sb1r=361;#gen=8; -2.000000 (0.0 Mpts) [v4.44] <PhaseRotEb1> {81ECBD135A723EAAA249DFAD |
| waffleironhead 2007-12-13 03:35:21 | update. My other client caused one as well. This was an upgraded client. 4.43d to 4.44 |
| tomaz 2007-12-13 08:04:52 | Yes, I was just to post the same. It happened to me after manualsend. Before results were OK, after send client begun to produce -2.0000 results. I also noticed that while doing it, my cpu usage was 50 % (instead of 100) (on athlon x2). While sendind, program is doing reparsing much longer than previous version. After stoping it and rerun, everything is back to normal again. |
| Stephen Brooks 2007-12-13 09:42:15 | I found this started happening on my laptop. It was producing results OK for the first 5 or so, and then started with -2%/0Mpts results. I'll try and see what's causing this, but it's kind of hard to replicate, I may try forcing a send early on to see if that changes anything. Run it with commandline (or graphics) version to see if it shows anything unusual there. |
| Zerberus 2007-12-13 10:14:01 | Could this be related to the 'leaking' bug? A lot of particles leave the valid simulation very early. |
| Stephen Brooks 2007-12-13 12:35:06 | I think it might be different. If even some get down the channel it won't be -2.000 |
| tomaz 2007-12-13 14:16:13 | Stephen, that -2.000 results are bug. Version 4.44 doesn't like config file to be changed during the run. If it is changed (manualy or after results send) it begins to produce -2.000 results (not only with #gen=0 but with all others too). It must be that config file isn't read well (muon1 also switch to one thread instead of two) |
| Stephen Brooks 2007-12-13 14:30:12 | Is the config.txt file rewritten by Muon1 when that happens? |
| Stephen Brooks 2007-12-13 15:57:33 | Ah, I just saw this myself in the commandline mode. It was the first recheck of a result that had just gone into the queue. Advanced the timer but no particles were created or lost, and no Mpts registered. I wonder if it's a queue thing? Will test that... |
| Stephen Brooks 2007-12-13 17:05:16 | I just found something involved with the loading of results from queue files... looks hopeful, maybe  |
| Stephen Brooks 2007-12-13 17:53:36 | Well, there certainly was a bug related to loading queued results (ironically resulting from my last-minute fix to another queue-reading bug concerning the removal of "#runs" parameters already in the genome) and I've fixed it and version v4.44a is the result. Other bugs known at the time have also been dealt with. |
| Xanathorn 2007-12-13 19:09:31 | Reparsing results when sending in with v4.44a is still very slow (clean installed). 21 Results took like 15-20 seconds to reparse, used to take an instant of a second with v4.43. Besides datacenter not wanting to download results off my server I didn't find any other anomalies yet. |
| Stephen Brooks 2007-12-14 23:49:40 | OK, slowness is interesting. It's most likely that I just changed the order in which things initialise and the -s send results switch is loading the whole results.dat before sending, when it doesn't need to. I've made a note to check this next week. |
| RGtx 2007-12-16 00:41:10 | I've just got my first -2.000% results, after a manual send. The trial running during the send completed successfully, the next two, before I aborted, were erroneous. |
| Stephen Brooks 2007-12-18 16:12:17 | --[Reparsing results when sending in with v4.44a is still very slow (clean installed).]-- I just fixed this. It's when I do a supposedly-quick initial check of the lattice checksums before sending, but I "simplified" the code and switched the caching of datafile checksums off! So it checksums the big pion CSV file repeatedly, when it really just needs to do it once when sending. |
