Report on new optimized Astropulse apps for Windows

[Jason G]

Yep, noticed the nice integer division followed by typecast to double.  Always did find 32 bit long & normal signed ints funny (or the contexts I've seen them used in anyway), changing the values to unsigned would probably be enough to fix it.  (but obviously still wouldn't be percent)

[Richard 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)

Finished at full runtime - 7 single pulses and 30 repetitive pulses. Result file attached - full WU datapak available if you want it uploading.

[attachment deleted by admin]

[Jason G]

Might as well wack it up,  Speed's back up now 

[Richard Haselgrove]

What's the next description beyond 'jewel'?

 ap_04no08ae_B5_P0_00273_20081124_23735 (1068934402)

has 3548 blanking indices, 448 of them with signal strength over 100. Highest signal strength is 213.925781

Would anyone like to estimate the likely scientific value of the next 15 hours work?

[attachment deleted by admin]

[Richard Haselgrove]

Might as well wack it up,  Speed's back up now 

Will do, give us a mo.

Wow, that's better. >283Kbps sustained. Zip contains v5 result, indices, std_err.

What's the best way to get a v4 result offline to compare?

[Raistmer]

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

ap_04no08ac_B4_P1_00145_20081123_17576 (1067934018)

Finished at full runtime - 7 single pulses and 30 repetitive pulses. Result file attached - full WU datapak available if you want it uploading.

Try to do the same WU with 4.x version, then send both result files along with indices.txt, stderr.txt and WU itself to FTP, please.

[Raistmer]

What's the best way to get a v4 result offline to compare?

Think opt app will be fine. No need to use 4.x stock one.

[Leaps-from-Shadows]

Got some more completed work units on Cruiser:

Main:368768645 (Pending), 368768653 (Validated)
Beta:  1563494 (Validated)

Cruiser's compiled results so far:

Main:
368768645 (Pending) - 0.008021076 credits per CPU second
368768653 (Validated) - 0.008183099 credits per CPU second
368496971 (Pending) - 0.008235288 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

Fairly consistent on both Main and Beta...

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

[Raistmer]

Again, rep pulses overflow....
single pulses: 8
repetitive pulses: 30

single pulses: 12
repetitive pulses: 30

    single pulses: 7
repetitive pulses: 30

All main ended with rep overflow but no such effect on beta. It seems tape w/o radar used on beta .

[Josef W. Segur]

...main ended with rep overflow but no such effect on beta. It seems tape w/o radar used on beta .

About a week ago I went through Richard's Beta reports from opt 5.00. There were 26 of them, 1 was a 30+30 overflow, 3 more had 30 repetitive pulses, 4 had no reportable pulses of either type. In total, there were 108 single pulses reported and 179 repetitive pulses. That's a very small sample, but at least indicates the "tape" covers a wide range of conditions.

The "radar removal" is looking for a DC level from the length 1024 FFTs it uses, which I think is an effect of getting a strong enough input to saturate the receiver channel, or at least cause compression. Assuming those incidents are caused by radar signals bouncing back from an airplane, the strongest ones are going to be when the bounce arrives on one of the side-lobe peaks and/or when the aircraft is oriented to produce the strongest reflection. It's a hugely complicated set of interactions.
                                                                      Joe

[Leaps-from-Shadows]

Got some more completed work units on Cruiser:

Main:  368768645 (Pending), 368768653 (Validated)
Beta:  1563494 (Validated)

Cruiser's compiled results so far:

Main:
368768645 (Pending) - 0.008021076 credits per CPU second
368768653 (Validated) - 0.008183099 credits per CPU second
368496971 (Pending) - 0.008235288 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

Fairly consistent on both Main and Beta...

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

Add another one to the Main list:
368768654 (Validated, canonical result) - 0.008136883 credits per CPU second

Still, it has this:
    single pulses: 4
repetitive pulses: 30

[Josef W. Segur]

What's the next description beyond 'jewel'?

 ap_04no08ae_B5_P0_00273_20081124_23735 (1068934402)

has 3548 blanking indices, 448 of them with signal strength over 100. Highest signal strength is 213.925781

Would anyone like to estimate the likely scientific value of the next 15 hours work?

That's a 90% blanker. There's one place with slightly over 2.7 M unblanked samples, another with over 400 K, and two more very short ones.

With considerable refinement, the app could just process the unblanked portions using only the appropriate tests. The short FFA would be appropriate if shifted to work within that 2.7 M section, the long FFA makes no sense, single pulse searches work on only 32 K samples and could be tried on all the unblanked data. Processing time that way should be less than 10% of the full run, and scientific value would be maximized. That assumes it's possible to have actual clean data in short sections surrounded by noise, we're not on a path to discover that yet.

As it stands, scientific value is going to lie in the realm of illustrating flaws in the implementation; sometimes that's the most important part of the scientific method.
                                                                          Joe

[Richard Haselgrove]

That's a 90% blanker. There's one place with slightly over 2.7 M unblanked samples, another with over 400 K, and two more very short ones.

With considerable refinement, the app could just process the unblanked portions using only the appropriate tests. The short FFA would be appropriate if shifted to work within that 2.7 M section, the long FFA makes no sense, single pulse searches work on only 32 K samples and could be tried on all the unblanked data. Processing time that way should be less than 10% of the full run, and scientific value would be maximized. That assumes it's possible to have actual clean data in short sections surrounded by noise, we're not on a path to discover that yet.

As it stands, scientific value is going to lie in the realm of illustrating flaws in the implementation; sometimes that's the most important part of the scientific method.
                                                                          Joe

Turned out to be over 16 hours - slightly slower than normal for r69 on this box. Don't know if that's significant.

Found 6 single pulses and 27 repetitive pulses - I suppose there are fewer edges to have edge artefacts on, when the whole thing is blanked . Result attached.

Oh, and please contribute to to my 'dilemma' thread at SETI

[ooops, wrong file]

[attachment deleted by admin]

[Jason G]

..
Oh, and please contribute to to my 'dilemma' thread at SETI
..

Done.  Feel free to disagree.

[Richard Haselgrove]

Done.  Feel free to disagree.

Yours is probably the nearest thing to a 'right' answer, but I just wanted to get the debate out into the open.....

I'll probably end up doing it with v5, just so we get another indices.txt file to play with.