Message boards :
Number crunching :
vlar data and breakthrough listen
Message board moderation
Author | Message |
---|---|
DonS Send message Joined: 15 May 16 Posts: 7 Credit: 1,540,164 RAC: 2 |
I'm new again to setiathome and an curious about the .vlar extensions I'm getting and the Breakthrough Listen setiathome data and how I might know if I'm running it's jobs (as opposed to what the project is about which I've just started to read on). I'm googling left and googling right but not getting a clear picture of what these are or if they're related. Info or pointers to pages perhaps? Don |
tullio Send message Joined: 9 Apr 04 Posts: 8797 Credit: 2,930,782 RAC: 1 |
Go to Number Crunching. Tullio |
Angela Send message Joined: 16 Oct 07 Posts: 13131 Credit: 39,854,104 RAC: 31 |
I am moving this thread to Number Crunching as I believe that more interested parties will participate in discussion of this topic there. |
Zalster Send message Joined: 27 May 99 Posts: 5517 Credit: 528,817,460 RAC: 242 |
I'm new again to setiathome and an curious about the .vlar extensions I'm getting and the Breakthrough Listen setiathome data and how I might know if I'm running it's jobs (as opposed to what the project is about which I've just started to read on). Welcome back Don I'm going to link 2 places for you. The first is Eric announcement on the Breakthrough listen http://setiathome.berkeley.edu/forum_thread.php?id=79411 Next is his description of what the file name means http://setiathome.berkeley.edu/forum_thread.php?id=79411&postid=1778453
When this first came out, they were primarily sent to the CPU as the data was more complex than what the GPU applications at the time could handle. Since the initial announcement, they have been release to the graphic cards. I'm not going to define that VLAR stand for, someone else can do. ( I tend to confuse the terms) What is know is that the GreenBank data is more complex than the Arecibo data as it is a long time period observation of a specific point the sky (rather than a quick scan) As such, the data is bigger and more complex requiring the applications to do more work. This is just a quick and dirty version. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
When this first came out, they were primarily sent to the CPU as the data was more complex than what the GPU applications at the time could handle. And sadly, wrong. Can we have a go at stamping out this urban myth, please? The amount of work that needs to be done is pretty darn near identical. But it's work which is not well suited to the design of, specifically, NVidia GPUs. They tend to take longer to achieve the same outcome as other computational resources. |
Zalster Send message Joined: 27 May 99 Posts: 5517 Credit: 528,817,460 RAC: 242 |
. But it's work which is not well suited to the design of, specifically, NVidia GPUs. They tend to take longer to achieve the same outcome as other computational resources. On this point, I will say that statement isn't necessarily true. Depending on the class of Nvidia GPU and the application, they can and do better than some of their counter parts. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
. But it's work which is not well suited to the design of, specifically, NVidia GPUs. They tend to take longer to achieve the same outcome as other computational resources. On Breakthrough Listen VLAR tasks? Do elaborate, please - we'd all like to achieve that happy outcome. (Under Windows, for the majority) (Edit - I'm in the middle of putting together a new installer, to assist users to deploy optimised apps. If such an app exists, and has been tested for accuracy and reliability, I'd want to consider including it) |
Mike Send message Joined: 17 Feb 01 Posts: 34263 Credit: 79,922,639 RAC: 80 |
. But it's work which is not well suited to the design of, specifically, NVidia GPUs. They tend to take longer to achieve the same outcome as other computational resources. Its related to the pulse find kernels which can be tuned with OpenCL apps via -sbs and -period_iterations_num switch. Raistmer explained it in another thread. With each crime and every kindness we birth our future. |
Zalster Send message Joined: 27 May 99 Posts: 5517 Credit: 528,817,460 RAC: 242 |
Thanks Mike, You are quicker than I am, lol... |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
. But it's work which is not well suited to the design of, specifically, NVidia GPUs. They tend to take longer to achieve the same outcome as other computational resources. For the avoidance of doubt, are we talking about message 1793638? I'll try and work it out in the morning - I ended up in a pub at the end of my walk :-) |
Mike Send message Joined: 17 Feb 01 Posts: 34263 Credit: 79,922,639 RAC: 80 |
. But it's work which is not well suited to the design of, specifically, NVidia GPUs. They tend to take longer to achieve the same outcome as other computational resources. Yes, its one of them. With each crime and every kindness we birth our future. |
Al Send message Joined: 3 Apr 99 Posts: 1682 Credit: 477,343,364 RAC: 482 |
Good on ya! You certainly deserved it! |
William Send message Joined: 14 Feb 13 Posts: 2037 Credit: 17,689,662 RAC: 0 |
For the sake of DonS before his question gets buried in unrelated discussions: [and partially just rephrasing what Zalster posted] You can distinguish between Arecibo and breakthrough listen data [tasks] by the name of the tasks. If there's 'guppi' in the name, you are crunching breakthrough listen, if not you're looking at Arecibo data (what we've been doing for the past 17 years and still keep plodding through). Guppi stands for 'Greenbank Ultimate Pulsar Processing Instrument'. The Greenbank telescope does mainly close observations of suns that may have planets around them (therefore more likely to have aliens). Arecibo depends on what the researcher is looking at - we only piggyback. That data may be sweeping the sky. VLAR stands for 'very low angle range' Imagine a telescope pointing at a star for a night. as the star moves across the sky (or rather the earth moves...) the telescope needs to move with it. the difference between the position at the start and the end of the data makes the angle range (AR). Arecibo data can come in mid-AR (the bulk) with ARs in the region of 0.4 [if you look at a finished task e.g. this one you can see the AR printed near the top.] There are also VHAR - very high AR, 2 and above and VLAR with an AR below 0.12 [it's derived from the beam width these days so may differ for guppi]. As you can see in the task linked the AR for guppi is usually very very small - as I said they tend to point at a star, so you have minimal movement. I think that covered the questions. Now, to the discussion that ensued. When Greenbank data was first discussed by Eric, the assumption was, this would be very big tasks possibly lasting weeks if not months. When we finally got guppis it turned out they have been parceled into much the same size as we are used to from Arecibo. Now, VLAR on NV. Back in 2009 it was found that the signal search algorithms as NVidia ported them to CUDA aren't really suited for the data structure of VLARs. Basically it takes an disproportional amount of processing power. The GPUs we had back then didn't cope very well, for some people slowing down the display as to make the host totally unresponsive. As GPUs got bigger, the problem lessened. Still the complaints - and the ensuing workarounds [like automated task abort]- led to the project introducing checks on the AR, marking VLAR as such and not distributing them to NV GPUs. Now, the picture has shifted. Besides having much more powerful GPUs we also have OpenCL applications. And the SoG app is far better suited to VLARs then the current CUDA app. [AFAIK by processing some stuff on the CPU, but you'd have to ask the developer i.e. Raistmer] The downside of the OpenCL apps on NV is that they basically block a CPU core too. Whether or not you are prepared to sacrifice some CPU to better GPU is up to you. We are still waiting for better preferences on that issue, to better accommodate what and how people like to run. Since that is BOINC territory, it isn't exactly easy to achieve. So, guys and gals, if you have anything to add to enlighten DonS or more detail to provide, go ahead. If, however, you wish to discuss anything from the size of guppis to the suitability of apps please open a dedicated thread. This is a newbie question and he deserves a simple and precise answer not a technical discussion/argument he doesn't understand atm. A person who won't read has no advantage over one who can't read. (Mark Twain) |
Mr. Kevvy Send message Joined: 15 May 99 Posts: 3776 Credit: 1,114,826,392 RAC: 3,319 |
The Greenbank telescope does mainly close observations of suns that may have planets around them (therefore more likely to have aliens). That was the initial idea (to observe Kepler objects) but doesn't seem to have carried through to the Breakthrough Listen observation plan: 1. Green Bank Radio Telescope |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
by processing some stuff on the CPU To inhibit new urban myth from developing: SoG uses less CPU in processing than non-SoG. And both had no increases in share of CPU involvement from first development of ATi MultiBeam app. To make picture precise and uncover used approach: first PoT processed on CPU entirely (cause first PoT unavoidably will update best signals for obvious reason). Then CPU used to re-assure signal existance that both makes app more stable to false positives (if GPU thinks signal exists but CPU disagrees result will be corrected w/o going to inconclusives) and allows to simplify corresponding kernels. But improvement in Pulse processing, especially on low FFT sizes (that constitute VLAR) achieved not because of that approach mostly but because of additional parallelization and more even load of GPU compute resources. More additional parallelizations still possible. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Hard to make any conclusion w/o list of Kepler objects. If star reside in 5 parsecs from Sun it doesn't make it "non-Kepler" nor ensure it has planets. In short - both lists most probably intersect. |
Mr. Kevvy Send message Joined: 15 May 99 Posts: 3776 Credit: 1,114,826,392 RAC: 3,319 |
In short - both lists most probably intersect. Only slightly... there are (edit: were prior to the May announcement) 460 stars with Kepler object planets, the furthest being 8kLy away, but there are 600M stars within 5kLy from earth, so less than one millionth contain Kepler planets. Thus, if not looking at confirmed planetary systems we may as well stay with random searches as the search has been essentially randomized. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Still not clear how these candidates will be selected: 1000 stars of all spectral-types (OBAFGKM). Within 50 parsecs. 1-15 GHz. One Million Nearby Stars. In 2016, first 5,000 stars; 1 minute exposure (1-15 GHz) Obviously total number of stars at those distances much greater. Let's hope being listed as having planetary system will be lead reason for selection. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
... there are (edit: were prior to the May announcement) 460 stars with Kepler object planets ... ROFL: "The 2016 May 10 confirmation of 1,284 more Kepler exoplanets has exceeded the technical abilities for this webpage to display." I make that 1644 distinct host stars, at distances between 35.7 and 2700 parsecs - 116 to 8806 light years - from earth (but including many at unknown distances). Edit: sources http://kepler.nasa.gov/Mission/discoveries/ http://exoplanetarchive.ipac.caltech.edu/cgi-bin/TblView/nph-tblView?app=ExoTbls&config=planets |
DonS Send message Joined: 15 May 16 Posts: 7 Credit: 1,540,164 RAC: 2 |
> vlar So I know what vlar means now but what's the significance of it? > guppi Great I'll be watching for these types of files. This is great info: blc3_2bit_guppi_57451_19304_HIP62472_0003 blc3: Breakthrough Listen 2bit: bits per real sample (4 bit per complex sample) guppi: File format (Greenbank Ultimate Pulsar Processing Instrument) 57451: Modified Julian Date 19304: Seconds past midnight HIP62472: Object Name 0003: Observation sequence number |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.