stephenbrooks.orgForumMuon1Bug Reports4.44 error? possibly
Username: Password:
Search site:
Subscribe to thread via RSS
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.
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io RSS feed

Site has had 25099958 accesses.