Perhaps this should have been stated at the beginning of this thread:

The Seti@home client is looking for spikes, gaussians, pulses and triplets during the processing of its tasks.

These four kinds of numbers or possibly data sets constitute the numbers which a possible signal of intelligent extraterrestrial origin might have.

I found this

Notice that the angle range of this wu is 0.65xxx so it would be considered a "high" angle range when compared to a "normal" AR of 0.41/0.42 Also note that this wu would take about 1/3 less time to crunch than a "normal" AR unit.

http://www.boinc-wiki.info/SETI@Home_Enhanced_FAQ#How_do_I_find_what_the_Angle_Range_of_a_work_unit_is.3F

So a normal is 0.41-0.42
So a vhar is above 0.42
So a vlar is below 0.41

But this wu is <true_angle_range>0.17057585438786</true_angle_range> would be a vlar but it is not marked as vlar so I guess that is not a true and fast rule observed so if had got sent to an nv card it would have problems.

IIRC the servers use 0.13 at the threshold the flag tasks as VLAR. The range for normal is much broader than .41 or .42. I think 0.42 was the desired AR for the classic S@H and kind of the center road. If you have seen the charts that have been made by various people where they plot time and AR you can get a good sense of where the VHAR and VLAR ranges are. Often the graph looks like a sideways S that is flattened out in the middle.

Edit: Here is one of the graphs Raistmer did. Not quite a flattened S like I was thinking, but shows where many AR tasks fall.
http://img196.imageshack.us/img196/4914/mbtasks.png

According to the graph intermediate AR WU are in this range .368 – 1.000
So according to this graph

VHAR range is > 1.000
IAR range is ~ .368 – 1.000
VLAR range is < .368

---

According to the graph intermediate AR WU are in this range .368 – 1.000
So according to this graph

VHAR range is > 1.000
IAR range is ~ .368 – 1.000
VLAR range is < .368

An MB WU has some values which effectively define the basic zones:

<pot_min_slew>0.00209999993</pot_min_slew>
<pot_max_slew>0.0104999999</pot_max_slew>

Those control the range within which Gaussian processing can be done. They are in units of degrees per second so need to be multiplied by the 107.374 second duration of a WU to convert to AR, giving 0.225486 as the lower limit and 1.127429 as the upper limit. In the original Classic S@H only Gaussian and Spike searches were done, so anything outside that range was very quick to crunch.

A year or two later Pulse and Triplet searches were added. They both analyze arrays which include the data from one beam width of motion, and when the telescope is moving quickly the arrays are smaller (and even too small to analyze at the narrower bandwidths. http://seticlassic.ssl.berkeley.edu/faq.html#q125 has a table showing what's done at various ARs. At the low AR end there's considerable data to analyze at many bandwidths.

The VHAR and VLAR terminology which has developed here over the last few years is not precisely defined. But because the estimates for all WUs with AR greater than 1.127429 are the same and much shorter than lower ARs that's what is generally meant by VHAR. At the low end, VLAR may refer either to WUs with AR less than the beam width of 0.05 degrees which are all processed identically, or to those with AR less than 0.12 degrees which get the .vlar extension since they proved particularly difficult to process with CUDA GPU code. I'd call anything between 0.12 and the 0.225486 lower limit on Gaussians LAR.
Joe

So if I understand you correctly the ranges are for MB WU

VHAR range is > 1.127429 (Gaussians, Pulse, Triplet)
IAR range = 0.225486 - 1.127429 (classic wu of old and Gaussians, Pulse, Triplet of late)
VLAR range is = 0.12 - 0.22586 (for Gaussians)
VLAR range is = 0.12 – 0.05 (get vlar extensions not for cuda)
VLAR range is < 0.05 (Gaussians, Pulse, Triplet)

So why use cuda if some wu do not run good see below

At the low end, VLAR may refer either to WUs with AR less than the beam width of 0.05 degrees which are all processed identically, or to those with AR less than 0.12 degrees which get the .vlar extension since they proved particularly difficult to process with CUDA GPU code.

---

So if I understand you correctly the ranges are for MB WU

VHAR range is > 1.127429 (Gaussians, Pulse, Triplet)
IAR range = 0.225486 - 1.127429 (classic wu of old and Gaussians, Pulse, Triplet of late)
VLAR range is = 0.12 - 0.22586 (for Gaussians)
VLAR range is = 0.12 – 0.05 (get vlar extensions not for cuda)
VLAR range is < 0.05 (Gaussians, Pulse, Triplet)

I'd put it this way:

VHAR range is > 1.127429 (Spike, Pulse, Triplet)
IAR range = 0.225486 – 1.127429 (Gaussian, Spike, Pulse, Triplet)
LAR range is = 0.00 – 0.225485 (Spike, Pulse, Triplet)

VLAR subrange is = 0.00 – 0.12 (get vlar extensions not for cuda)
VLAR subrange is = 0.00 – 0.05 (all <= one beam width)

So why use cuda if some wu do not run good see below

At the low end, VLAR may refer either to WUs with AR less than the beam width of 0.05 degrees which are all processed identically, or to those with AR less than 0.12 degrees which get the .vlar extension since they proved particularly difficult to process with CUDA GPU code.

The difficulty on the CUDA builds made by NVIDIA ranged up to totally unacceptable screen lags and even the OS resetting the video drivers because the card was unavailable for video output for too long. Those issues can be handled, the current Lunatics GPU builds do better.

What's left is that VLAR work is difficult to divide up so the hundreds of processors on a high end GPU are kept busy doing the same thing to different parts of the data. That difficulty is also yielding. For instance the splitter estimate for the amount of work in a 0.01 AR VLAR WU is the same as the work in a 0.4286 AR WU, and although the OpenCL ATI HD5 build may take about 50% longer to process the VLAR WU so do some CPU systems. Don't take that 50% approximation too literally, it is based on a single test run with a set of shortened test WUs.

BOINC only allows minimal control of which tasks can be delivered for crunching by a particular resource. Keeping the .vlar tasks off CUDA makes sense for now, but we can hope that will not remain too much longer. There are times when almost all the "Results ready to send" are VLAR tasks, and it's a sad thing for GPUs to go idle.

                                                                  Joe