Raistmer, looks like a you are looking at a new version of SoG next week. Is that correct?

Should we wait for it's deployment to test or has it already been tested?

Edit.. Congrats to Dr. K (user of the day)

Raistmer, looks like a you are looking at a new version of SoG next week. Is that correct?

Should we wait for it's deployment to test or has it already been tested?

No, 8.19 is the one that going to main IMO.

---

News about SETI opt app releases: https://twitter.com/Raistmer

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8902774
NV SoG 8.19 vs x41p_zi3j, Cuda 8.00 special

All results are marked Valid. Why third was required - unclear.

---

News about SETI opt app releases: https://twitter.com/Raistmer

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8902774
NV SoG 8.19 vs x41p_zi3j, Cuda 8.00 special

All results are marked Valid. Why third was required - unclear.

Because the first two were "weakly similar". I doubt anyone will want to reproduce the Android run offline, but I do wish there was some way of displaying weak similarity (as seen by the official validator) after a WU like this is complete.

Edit - weak validation is logged at https://setisvn.ssl.berkeley.edu/trac/browser/seti_boinc/validate/sah_validate.cpp#L315, but is not visible outside the server environment.

All results are marked Valid. Why third was required - unclear.

Because the first two were "weakly similar".

OK, more precise: "why first two were marked weakly similar - unclear".

---

News about SETI opt app releases: https://twitter.com/Raistmer

I think I've found it. Lining up the signals for visual comparison, look at the final reported pulse:

[SoG result first, cuda special second]

Pulse: peak=9.601984, time=92.85, period=3.88 , d_freq=1420635757.34, score=1.073, chirp=-70.563, fft_len=1024 
Pulse: peak=9.24521 , time=92.85, period=3.932, d_freq=1420635757.34, score=1.033, chirp=-70.563, fft_len=1024 

Best pulse: peak=9.601984, time=92.85, period=3.88, d_freq=1420635757.34, score=1.073, chirp=-70.563, fft_len=1024 
Best pulse: peak=9.601981, time=92.85, period=3.88, d_freq=1420635757.34, score=1.073, chirp=-70.563, fft_len=1024

The test is

        case SIGNAL_TYPE_PULSE:
        case SIGNAL_TYPE_BEST_PULSE:
	            if (rel_diff(power, s.power)                > .01) return false;  // 1%
	            if (rel_diff(mean_power, s.mean_power)      > .01) return false;  // 1%
	            if (abs_diff(period, s.period)              > .01) return false;  // .01 sec
	            if (rel_diff(snr, s.snr)                    > .01) return false;  // 1%
	            if (rel_diff(thresh, s.thresh)              > .01) return false;  // 1%

I think the reported pulse fails on both peak and period, but we have another of those cases where 'best pulse' <> 'reported pulse'. We'd better ask Petri to check how close "x41p_zi3j, Cuda 8.00 special" is to his current debug version.

So, CUDA reported pulse peak differs too strong from the others.
Thanks for info.

EDIT: actually, it differs from "prev best!=reported". First one was genuine. This one obviously demonstrates some bug. Cause all other apps agreed that reported _is_ the best.

Note that same best (being reportable!) reported by CUDA special correctly. But this signal missed from list of reportable signals. It was replaced with smth else . So, perhaps, bug in reportable pulse selection part. It finally chose wrong place.

EDIT2: recently I looked into pulse signal selection algorithm. And it appeared more resemble AstroPulse one than I thought. It contains same PoT signal replacement too. That is, if another, more strong, signal will be found inside same PoT but on another fold level (another period) old one will be replaced by new one. Old was not reported. It's one of possible places where bug with such manifestation could hide.

---

News about SETI opt app releases: https://twitter.com/Raistmer

Don't know where to report this:
Attempt to Create Profile gives:
http://setiweb.ssl.berkeley.edu/beta/create_profile.php

Fatal error: Call to undefined function recaptcha_get_head_extra() in /disks/carolyn/b/home/boincadm/projects/beta/html/user/create_profile.php on line 319

---

- ALF - "Find out what you don't do well ..... then don't do it!" :)

Don't know where to report this:
Attempt to Create Profile gives:
http://setiweb.ssl.berkeley.edu/beta/create_profile.php

Fatal error: Call to undefined function recaptcha_get_head_extra() in /disks/carolyn/b/home/boincadm/projects/beta/html/user/create_profile.php on line 319

I think Stephen was getting this last week when trying to make a profile as well. At some point, the error went away as he kept trying ...

---

If I can help out by testing something, please let me know.
Available hardware and software is listed in my profile here.

Don't know where to report this:
Attempt to Create Profile gives:
http://setiweb.ssl.berkeley.edu/beta/create_profile.php

Fatal error: Call to undefined function recaptcha_get_head_extra() in /disks/carolyn/b/home/boincadm/projects/beta/html/user/create_profile.php on line 319

We're all Beta testers here and there isn't a central place to report bugs.
I have a handful of web interface bugs on the S@h main project to report since as far back as April and still nowhere to report.
How bizarre :-/

---

Don't know where to report this:
Attempt to Create Profile gives:
http://setiweb.ssl.berkeley.edu/beta/create_profile.php

Fatal error: Call to undefined function recaptcha_get_head_extra() in /disks/carolyn/b/home/boincadm/projects/beta/html/user/create_profile.php on line 319

We're all Beta testers here and there isn't a central place to report bugs.
I have a handful of web interface bugs on the S@h main project to report since as far back as April and still nowhere to report.
How bizarre :-/

Might try http://boinc.berkeley.edu/dev/forum_forum.php?id=3

---

This is not BOINC wide problem, try on other projects' sites:
(The link is the same for "Profile Create" and "Edit your profile" - if you have Profile - try to Edit it)

http://setiathome.berkeley.edu/create_profile.php
http://asteroidsathome.net/boinc/create_profile.php
https://milkyway.cs.rpi.edu/milkyway/create_profile.php

And here gives "Fatal error":
http://setiweb.ssl.berkeley.edu/beta/create_profile.php

Is it possible for us users to see the source of *this* create_profile.php
/disks/carolyn/b/home/boincadm/projects/beta/html/user/create_profile.php


Note: From here:
http://fossies.org/dox/boinc-client_release-7.6-7.6.32/create__profile_8php_source.html#l00315

  315 function show_profile_form($profile, $warning=null) {
  316     if ($profile) {
  317         page_head(tra("Edit your profile"), null, null, null, recaptcha_get_head_extra());
  318     } else {
  319         page_head(tra("Create a profile"), null, null, null, recaptcha_get_head_extra());
  320     }

recaptcha_get_head_extra ( )
Definition at line 992 of file util.inc
http://fossies.org/dox/boinc-client_release-7.6-7.6.32/util_8inc_source.html#l00992

---

- ALF - "Find out what you don't do well ..... then don't do it!" :)

recaptcha_get_head_extra() was replaced by boinc_recaptcha_get_head_extra() as part of

https://github.com/BOINC/boinc/commit/b4665845d02d675ec0362d72dc07ba4c86ac8949

Well - I never knew where to find the BOINC bug/issues reporting page, and now, thanks to Richard, I do - click on the "Issues" tab on the link he's provided and there it lurks (I'll have forgotten where it is by the time I remember what issue I was going to report the other day). I guess one has to set up an account to be able to use it....

I think we finished with massive testing of 8.19.
Hope Eric will have some time for release after returning from conference.
Next version not ready for beta for now, I'll make announcement when it will be ready.

---

News about SETI opt app releases: https://twitter.com/Raistmer

Finally got one to return 'pulse before autocorrs' on GTX 470, when I pushed the checkpoint interval out to 240 seconds. rescmpv5 (from bench v210, I think the latest) gave Q= 99.99%, the same as for the runs with signals in reference order.

Good! Perhaps it means validator should do the same.

Just to wrap this one up - I read through the validator code, and came to the conclusion that it *already* tests signals in all possible orders, so there's nothing that needs changing and my initial concern was a false alarm. Sorry about that.

Both Petri and Jason_Gee have been in touch requesting a copy of the data file (sent), and are going to investigate offline with their respective copies of the 'special' codebase.

One of my crunchers (61323) has just run three CUDA42 v.8.01 tasks. All three were VLARs, and took about 40-45 minutes to run (on a GTX980, one at a time). The run time is not too much of a surprise, but the massive lags in screen, keyboard and mouse response were.
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24688896
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24688990
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24689132

All three tasks have completed and validated, but thee is s great pile of similar tasks waiting to run on that computer.

One of my crunchers (61323) has just run three CUDA42 v.8.01 tasks. All three were VLARs, and took about 40-45 minutes to run (on a GTX980, one at a time). The run time is not too much of a surprise, but the massive lags in screen, keyboard and mouse response were.
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24688896
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24688990
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24689132

All three tasks have completed and validated, but thee is s great pile of similar tasks waiting to run on that computer.

To be honest, the v8.01 CUDA application (all flavours) is a fairly trivial refresh of the v7.00 applications released on 12 Mar 2013 - simply adding compatibility with the Breakthrough Listen data format. That development line is essentially dead, and doesn't need further testing: if you're feeling masochistic, you can let them run to provide (pretty reliable) validation partners to flag up problems with other, newer, applications still under development and test. Or you can abort them.

Thanks Richard, I'm not into that sort of masochism so I'll delete them when I get home.

So, CUDA reported pulse peak differs too strong from the others.
Thanks for info.

EDIT: actually, it differs from "prev best!=reported". First one was genuine. This one obviously demonstrates some bug. Cause all other apps agreed that reported _is_ the best.

Note that same best (being reportable!) reported by CUDA special correctly. But this signal missed from list of reportable signals. It was replaced with smth else . So, perhaps, bug in reportable pulse selection part. It finally chose wrong place.

EDIT2: recently I looked into pulse signal selection algorithm. And it appeared more resemble AstroPulse one than I thought. It contains same PoT signal replacement too. That is, if another, more strong, signal will be found inside same PoT but on another fold level (another period) old one will be replaced by new one. Old was not reported. It's one of possible places where bug with such manifestation could hide.

I'm aware of this signal overwrite during pulse finding. Would it be better to gather signals in an another way? The unrolled pulse finding runs much more parallel than the original version (up to the number of SMX units per card).