Computation Error -- Output File Absent

I don't have any Vega GPUs but I do have a lot of different Polaris - RX 460 -> RX 580.  I'm not seeing any real differences with unexpected/unusual compute errors as far as the different data types are concerned.

The event log information probably isn't the best place to get a handle on what is causing a problem.  The "output file absent" stuff is just BOINC saying that when the science app finished (in this case with a compute error) there weren't any of the usual result outputs to gather up and send back to the project.  Hardly surprising since the app had crashed.  What you need to do is click on the task ID link for a failed task on the website to see what the science app itself reported in the extra information stream, the std_err.txt output.  If you scroll to the end of that error output, you can see what the app was doing at the point of failure. For one of yours, this gave things like

% Binary point 505/1631
% Starting semicoherent search over f0 and f1.
% nf1dots: 41 df1dot: 2.512676418e-015 f1dot_start: -1e-013 f1dot_band: 1e-013
% Filling array of photon pairs
Error in computing index of fft input array, i:-1027760820 pair:281377
ERROR: prepare_ts_2_phase_diff_sorted() returned with error 18935032
22:46:35 (1480): [CRITICAL]: ERROR: MAIN() returned with error '1'
FPU status flags: PRECISION
22:46:47 (1480): [normal]: done. calling boinc_finish(65).
22:46:47 (1480): called boinc_finish

</stderr_txt>

I'm not a programmer, just a volunteer like you so I have no idea exactly why after processing 504 out of the total of 1631 binary points to be analysed (apparently quite successfully) the process should fail on binary point 505.  So whilst we really don't get much further without the input of the author of the app, we can probably make a few educated guesses.

Crunching pushes the hardware quite hard and can easily expose a whole range of issues from bugs in the app itself to problems with immature drivers or flaws in the hardware/firmware that have not yet been identified and worked around with driver updates.  There are also potential issues with heat/voltage/frequency that might push something over the edge.  My experience has been that many issues just like this can be mitigated by 'backing off' a little in what you are trying to extract out of the hardware, whilst making sure that heat removal and power quality are optimal.  Over the years, I've seen this solve many problems like this.

There are two quite different categories of task type for the FGRPB1G search but this is not something all that new - it's been going on for most of this year with data files alternating between the two distinct types. The latest transition happened right at the end of October.  The previous series (files like LATeah0104[TUVW].dat) changed to files like 1025L, 1031L, and then the current one 1032L, and tasks based on these take significantly longer to crunch than ones for the 0104? series. The new Turing series GPUs seem to be having the reverse problem to you.  They fail on the faster running previous series but seem to be OK on the current slower running series.

In looking at the details for your host, I notice that BOINC sees [5] GPUs.  Whilst it says 'Vega 64' they could be different but I'm wondering why BOINC says [5].  Do you really have 5 GPUs?   And what about other hosts that claim 10 or 20 GPU instances?   Are you running some sort of modified BOINC version or modified configuration that is inflating the GPU count?  Could any of that be why tasks are failing?