Help - DPAD stalled!

[Assimilator1]

Just a few minutes ago I noticed my CPU temp drop ,I checked the DPAD clients & they are showing this:-

Client 1
t = 43.92ns (7989/63001 particles) 47.1 Mpts
Auto-saving...
t = 1000.00ns (1/65889 particles) 70.2 Mpts
New simulation
Loading 'samplefiles\PhaseRotEb6.txt'... OK (100 results)
Making new genome, TrialType=Crossover... Done
Interpreting lattice file 'PhaseRotEb6'... Done
Beamline consists of 58 units, genome of 103 parameters
Using seed 0
Adding components to simulation space
Tantalum rod source data loaded.
Building proximity grid 7x7x50 (2450 cells)... Done
Tracking central particle to synchronise RF phases... Done
Done adding components
Determining nearby components...
Normalising beam...
- Starting -
t = 39.61ns (9540/62351 particles) 48.0 Mpts
Auto-saving...
t = 375.46ns (0/67042 particles) 85.4 Mpts
Attempting to send results...
servers.csv older than 24 hours, attempting download...
Reparsing results...
[WARNING] Record rejected due to bad checksum: was {D1A0301E186AEDFE4034D957}
Continue (Y/N/These/All)?

Client 2
t = 43.92ns (7989/63001 particles) 47.1 Mpts
Auto-saving...
t = 1000.00ns (1/65889 particles) 70.2 Mpts
New simulation
Loading 'samplefiles\PhaseRotEb6.txt'... OK (100 results)
Making new genome, TrialType=Crossover... Done
Interpreting lattice file 'PhaseRotEb6'... Done
Beamline consists of 58 units, genome of 103 parameters
Using seed 0
Adding components to simulation space
Tantalum rod source data loaded.
Building proximity grid 7x7x50 (2450 cells)... Done
Tracking central particle to synchronise RF phases... Done
Done adding components
Determining nearby components...
Normalising beam...
- Starting -
t = 39.61ns (9540/62351 particles) 48.0 Mpts
Auto-saving...
t = 375.46ns (0/67042 particles) 85.4 Mpts
Attempting to send results...
servers.csv older than 24 hours, attempting download...
Reparsing results...
[WARNING] Record rejected due to bad checksum: was {D1A0301E186AEDFE4034D957}
Continue (Y/N/These/All)?

What the heck is that about & which answer do I choose? ( & why?)

 

[petrusbroder]

Why, I do not know ... but if you want the clients to run again, in my experience, the only answers that work are "These" (you'll get the Q for quite some time) or "All". The latter rejects all those records that have bad checksums ... What that means in terms of credits I do not know, but as far as I know, I have not lost any Mpts.

 

[Assimilator1]

What does 'These' do then? & what's 'Q'?

Thanks for your help

 

[petrusbroder]

Q = the same question again.
If I understand it correctly (I may be wrong) "These" deletes the records with the bad checksum one by one, "All" deletes them all.

 

[Assimilator1]

Ok thx Petrus ,I'm gonna go for 'All'

I'd still like to know why this happened though......

 

[petrusbroder]

Yeah, it has happened to me 2 - 3 times too. It started after the new phaseRotE-file come up ... probably the parameters are marginal and the application just times out ...

 

[Assimilator1]

Running ok again btw

I've had the checksum error once before, but I had never had it ask me what to do next before.

 

[stephenbrooks]

It's an annoying prompt that I've decided really shouldn't be there. Basically it's trying to verify the checksum for an old lattice that you have results for but I've removed from the network. In v4.43d this won't actually prompt you if you're in background mode, but in cmdline and graphical it will assume the user is there to give input! In 4.44 hopefully I'll manage to get it to not prompt at all, that's one of the remaining few things on my list for that version.

Also there's an even worse issue, sometimes clients can stop completely if they had a lattice in their queue.txt file when it was retired! I've fixed this in the code for 4.44 already, but it means you might do well to check your crunchers to make sure none of them died with the recent introduction of PhaseRotE lattices.

I'm not going to retire any more lattices until after I've released the new version and plenty of people are using it, for these reasons! I've actually seen a drop in overall output because of this.

 

[stephenbrooks]

Oh yeah, just type "All" for now. It won't harm anything.

 

[petrusbroder]

Thanks Stephen for the info!

I just love DPAD - great feed back when needed!

 

[Assimilator1]

Thanks Stephen ,& got ya ,I did type 'all' & it was fine after that.

Err have to confess that I've temporarily stopped running DPAD atm as I'm in a race for the F@H team ,but I'll be back beginning of the year when the race is over.

 

[stephenbrooks]

As I mentioned a new version... I just released 4.44 (after a very, very long wait!) You can find the version history and download on the muon site.

 

[Assimilator1]

Cool ,thanks Stephen
And some cool additions you've made to DPAD:thumbsup:

Inccidently only 1 of my 2 clients were set to B (background) ,yet both had the prompt.
Guess it doesn't matter anymore anyway

It includes a more accurate collision detection algorithm so simulations may take longer to complete but will also register more Mpts.
lol ,you realise we'll have to do the benchmark graph all over again?! ,I'm going to make a note in the thread of the new release to avoid confusion over benchmarking figures ,like when the client was previously updated.

 

[stephenbrooks]

Originally posted by: Assimilator1
It includes a more accurate collision detection algorithm so simulations may take longer to complete but will also register more Mpts.
lol ,you realise we'll have to do the benchmark graph all over again?! ,I'm going to make a note in the thread of the new release to avoid confusion over benchmarking figures ,like when the client was previously updated.

I kept the Mpts/sec for a given PC roughly the same! It's just each simulation will take a bit longer, but will also register for proportionately more score.

 

[Assimilator1]

Ah ok ,so we don't have to do the graph over again then?