Forum > Discussion Forum
Report on new optimized Astropulse apps for Windows
Josef W. Segur:
--- Quote from: Jason G on 25 Nov 2008, 08:09:35 am ---I'm seeing a similar thing in your result file posted before , to my 'full blanked' result... A bunch of repeating pulses collected at the end of the WU.
My 3 results... (attached) 4.35, 5r69 and 5r69FullBlank for a WU that had lots of signals, but didn't overflow with either 4.35 or v5,
Note full blank repeating pulses x 30 all around <peak_bin> 33538050 give or take. They also seem to be all around <scale> 4, so we probably can work out the average power there.
--- End quote ---
Repetitive pulses with <scale> 4 are from the the short FFA, and although <peak_bin> shows a high number they are actually working on data from the first 1M samples. Subtract 33538048 from the <peak_bin> value to correct it. Even then, it looks like the remaining value needs to be scaled up by 2^(scale + ffa_scale).
<scale> 4 says the power was x16 when copied to the FFA buffer, if there's any non-zero <ffa_scale> value those are also doublings. But the actual folding also increases power by a factor between 137 and 274, it should be possible to figure that out from the <period> but I haven't looked at that closely enough to know what units it's using.
--- Quote ---I think a step from the randomised to off-the edge or similar phenomemon might be occurring. Exactly where does last dm get its overlap data from during dechirp? and is full blank randomising that too? or have we a nice step to raw data, zero or some averaged value?
Jason
...
--- End quote ---
For "blanking", a 32K pseudo-random data sample chunk replaces 32K real samples before the forward FFT, there's no chance that any deeper parts of the single pulse processing will see a mix.
There IS a flaw in copying data to the FFA buffers, though. Because the data chunks are overlapped by half, only the first half of the coadded chunk is copied, then when the last chunk to be copied for a dm is reached there's half a chunk worth which needs special handling. Rather than putting the last half of the chunk there, the code puts a second copy of the first half. That's wrong and should be corrected, but I doubt it is contributing much to the weird results.
Joe
Leaps-from-Shadows:
Cruiser's compiled results so far:
Main:
368768645 (Validated) - 0.008021076 credits per CPU second
368768653 (Validated) - 0.008183099 credits per CPU second
368496971 (Pending) - 0.008235288 credits per CPU second
368768654 (Validated, canonical result) - 0.008136883 credits per CPU second
368768675 (Pending) - 0.008161555 credits per CPU second
368418713 (v4.37, Pending) - 0.006726898 credits per CPU second
Beta:
1563494 (Validated) - 0.009484371 credits per CPU second
1565756 (Validated) - 0.009705443 credits per CPU second
1564992 (Validated) - 0.009227865 credits per CPU second
1565745 (Pending) (Task details) - 0.009846161 credits per CPU second
For comparison:
Shorty Multibeam (16.84 credits): 0.007037046 credits per CPU second
Average Multibeam (44.12 credits): 0.008375063 credits per CPU second
Long Multibeam (63.86 credits): 0.010619245 credits per CPU second
I have decided to keep crunching Astropulse units on Main, but only one at a time.
Leaps-from-Shadows:
Cruiser's compiled results so far:
Main:
368768645 (Validated) - 0.008021076 credits per CPU second
368768653 (Validated) - 0.008183099 credits per CPU second
368496971 (Pending) - 0.008235288 credits per CPU second
368768654 (Validated, canonical result) - 0.008136883 credits per CPU second
368768675 (Pending) - 0.008161555 credits per CPU second
368768681 (Validated) - 0.008024405 credits per CPU second
368418713 (v4.37, Pending) - 0.006726898 credits per CPU second
Beta:
1563494 (Validated) - 0.009484371 credits per CPU second
1565756 (Validated) - 0.009705443 credits per CPU second
1564992 (Validated) - 0.009227865 credits per CPU second
1565745 (Pending) (Task details) - 0.009846161 credits per CPU second
1565021 (Pending) (Task details) - 0.009777995 credits per CPU second
For comparison:
Shorty Multibeam (16.84 credits): 0.007037046 credits per CPU second
Average Multibeam (44.12 credits): 0.008375063 credits per CPU second
Long Multibeam (63.86 credits): 0.010619245 credits per CPU second
Leaps-from-Shadows:
Cruiser's compiled results so far:
Main:
368768645 (Validated) - 0.008021076 credits per CPU second
368768653 (Validated) - 0.008183099 credits per CPU second
368496971 (Pending) - 0.008235288 credits per CPU second
368768654 (Validated, canonical result) - 0.008136883 credits per CPU second
368768675 (Pending) - 0.008161555 credits per CPU second
368768681 (Validated) - 0.008024405 credits per CPU second
369656439 (Pending) - 0.007830532 credits per CPU second
349739781 (Validated) - 0.008531656 credits per CPU second
368418713 (v4.37, Pending) - 0.006726898 credits per CPU second
Beta:
1563494 (Validated) - 0.009484371 credits per CPU second
1565756 (Validated) - 0.009705443 credits per CPU second
1564992 (Validated) - 0.009227865 credits per CPU second
1565745 (Pending) (Task details) - 0.009846161 credits per CPU second
1565021 (Pending) (Task details) - 0.009777995 credits per CPU second
1565898 (Pending) (Task details) - 0.009551190 credits per CPU second
For comparison:
Shorty Multibeam (16.84 credits): 0.007037046 credits per CPU second
Average Multibeam (44.12 credits): 0.008375063 credits per CPU second
Long Multibeam (63.86 credits): 0.010619245 credits per CPU second
For the first time, I had two v5.00 work units on Main (369656439 and 349739781) that did not end with pulse overflows, and one on Beta (Task details) that did end with a pulse overflow.
Raistmer:
this one near overflow too
single pulses: 8
repetitive pulses: 27
Pity that we haven's % of blanking in stderr too....
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version