Report on new optimized Astropulse apps for Windows

[Haselgrove]

I'm slightly surprised by the blanking report at the start of the result file analysis: <percent_blanked> -18.750000 for the 'jewel', and <percent_blanked> -21.785156 for the other.

So, Joe's % estimate and Josh's differ... Interesting, how much % will be in our current totally-blanked run....

Probably not - since a negative percentage doesn't make much sense, I'm reading that as (100-18.750000) or 81.25%, which is perfectly in line with Joe's "roughly 81%".

But the equivalent calculation for the other WU suggests <percent_blanked> 78.214844 - which is odd, since there are far fewer blanking indices (787) in that file.

[Jason G]

probably a misplaced division of integer components with the typecasts in the wrong place.  That should definitely be in the range 0.0-->1.0 looking at the code (so proportion rather than percentage).  The value is likely a fluke that it bears any apparent relationship IMO.

[Leaps-from-Shadows]

First Astropulse work unit crunched with v5.00 optimized app completed on Main.  Task details.
Credits (759.31) divided by CPU seconds (92202.00) = 0.008235288 credits per CPU second.

Compare to other work units:
Shorty Multibeam - AK_v8_win_SSE3 app - Credits (16.84) divided by CPU seconds (2264.34) = 0.007037046 credits per CPU second.
Average Multibeam - AK_v8_win_SSE3 app - Credits (44.12) divided by CPU seconds (5268.02) = 0.008375063 credits per CPU second.

This version finally seems to bring Astropulse and Multibeam units into equality as far as credits per CPU second - at least on AMD processors.  Woohoo!

[Jason G]

Good for the AMD chips then.  Keep an eye on the wingman for that task though,  looks like a machine that might be having some issues. If not fixed, best hope might be that they error out quickly for reissue to a new wingman, otherwise could be waiting awhile for validation.

[Haselgrove]

Attaching result files for my two blanking cases, as a courtesy to Joe's dialup.

Edit - it would be even more of a courtesy if I attached the zipped files!

[Jason G]

Chose to examine another single pulse, and this one is not so near blanked sections it seems

<ap_signal>
  <fft_num>10190848</fft_num>
  <peak_bin>10199552</peak_bin>

closest index is at 11808768

immediately following one similar story, <fft_num>9093120</fft_num>
  <peak_bin>9105920</peak_bin>

 but notice that both these seem to lie between blanked regions around the middle, so wonder how much a part interactions with the higher dm figure on these around the middle of processing might play, and so how far to factor in adjacent data / proximity due to dedispersion.
 
[perhaps later on, a comparison run of this WU on a pre-blanking build might confirm whether these are legitimate pulses or not (assuming can get it to run w/o really early exit) ]

[Raistmer]

[perhaps later on, a comparison run of this WU on a pre-blanking build might confirm whether these are legitimate pulses or not (assuming can get it to run w/o really early exit) ]

Good idea!
To look if all new pulses could be found inside old app.
Think we should do this investigation.

[Jason G]

Yeah, still a while to go on my full-blank run... will see after that tomorrow. [We seem to have gravitated development discussion unintentionally out to discussion forum (probably my fault).  I suggest we migrate back to avoid confusing users]

[Raistmer]

Yeah, still a while to go on my full-blank run... will see after that tomorrow. [We seem to have gravitated development discussion unintentionally out to discussion forum (probably my fault).  I suggest we migrate back to avoid confusing users]

Sure You can move needed part as moderator if you think it's worth efforts...

[Jason G]

No it isn't worth mucking about, just reminding myself before I any more out of hand and start swearing in the wrong place 

[Haselgrove]

No it isn't worth mucking about, just reminding myself before I any more out of hand and start swearing in the wrong place 

No, please don't move anything - I posted at SETI Beta several hours ago, letting Josh know that much of this discussion would be visible to him even before he registered on this site (though of course he'll have access to much more once we have an account ID to upgrade).

[Jason G]

LoL, OK fair enough.  Next theories though lead to movie night at arecibo involving lots of microwaved popcorn.

[Haselgrove]

Get the popcorn ready - got another chunky indices.txt file to watch through - 1344 sample points..

ap_04no08ac_B4_P1_00145_20081123_17576 (1067934018)

[Jason G]

If I didn't know any better (which I don't) I'd swear that pickup has a loose ground wire.

[Josef W. Segur]

Get the popcorn ready - got another chunky indices.txt file to watch through - 1344 sample points..

ap_04no08ac_B4_P1_00145_20081123_17576 (1067934018)

You might find it interesting to watch the changes in percent_blanked in the result file (it is rewritten with each checkpoint). The count of blanked samples should be limited to one DM, but it keeps on adding AFAICT. Because the count is kept in a signed integer, it can overflow into negative territory. The limits may be +/- 6400%, but if so I'm surprised we haven't seen larger values already. My current offline test on a slow system progressed from -38.121094 to -31.998047 in the last 40 minutes or so.

Edit: Aha! It doesn't really convert to percent, it simply divides the blanked sample count by the total sample count, so if they were equal the field would show 1.00000 rather than 100.0000 With that, the max range becomes +/-64. The name is wrong as well as the method.
                                                                         Joe

It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.

- Franklin D. Roosevelt