Several computation errors

I had a look at this task. The exit status you saw (near top of page) is mostly not that useful.  If you scroll down into the actual output of the app, you can see (for example) the following, which represents the actual start of crunching for the app.  The INFO message confirms we are `starting from scratch' - ie. no previous checkpoint to start from.

2020-04-08 21:25:32.6707 (3336) [normal]: INFO: No checkpoint checkpoint.cpt found - starting from scratch
% --- Cpt:0, total:271, sky:1/1, f1dot:1/271

0.% --- CG:2118404 FG:123892 f1dotmin_fg:-2.955938795097e-008 df1dot_fg:8.253006451613e-014 f2dotmin_fg:-6.651808823529e-019 df2dot_fg:2.660723529412e-020 f3dotmin_fg:0 df3dot_fg:1
....INFO: Major Windows version: 6
c
..........c
..........c
..........c
..........c
..........c
..........c
..........c
..........c
..........c
..........c
..........c
..........c
..........putenv 'LAL_DEBUG_LEVEL=3'
2020-04-09 16:05:47.9425 (2892) [normal]: This program is published under the GNU General Public License, version 2
2020-04-09 16:05:47.9526 (2892) [normal]: For details see http://einstein.phys.uwm.edu/license.php
2020-04-09 16:05:47.9606 (2892) [normal]: This Einstein@home App was built at: Dec 19 2019 12:14:49

There is also other information - my interpretation (I could be wrong) is that cpt:0 means checkpoint zero out of an expected total of 271, sky 1/1 means we only have one skypoint to analyse and f1dot:1/271 means that we are starting the first of 271 calculation loops.

Within each loop, there are sub-loops (represented by the lines of dots) with a point where a new checkpoint is written (c) at the end of each line.  So having started at 2020-04-08 21:25:32.6707 (listed right at the top) calculations were stopped for the day (BOINC shut down) just before a checkpoint was going to be written.  This means that the unfinished partial line represents a small loss that will need to be recalculated at the next startup.

The calculations restarted with the "putenv" continuation of the last row of dots. It's the next day, 2020-04-09 16:05:47.9425.  If you continue reading the stuff after what I quoted above, you will find

[/10]2020-04-09 16:11:22.9149 (2892) [debug]: Successfully read checkpoint:25[/]

This just confirms that the crunching of the task was successfully resumed from the previously saved checkpoint.

After quite a lot more processing, you get to the actual error situation and the following is the best guide to the problem (I've left out the huge path string that precedes the actual filename of the routine in which the error occurred)

OpenCLutils.c:582): clEnqueueNDRangeKernel failed: CL_INVALID_COMMAND_QUEUE

I'm not a programmer so I've no clue about what was being done at line 582 in the code but, whatever it was, your GPU couldn't handle it and therefore crashed.  Since this same point would have been traversed many times in previous loops, something glitched with your GPU on this particular loop.  No doubt, the app developer would have some idea of the cause of "CL_INVALID_COMMAND_QUEUE" but I'd be surprised if it wasn't just characterised by "hardware glitch".

I decided to go through all this in such detail so that others experiencing similar failures can know how to investigate for themselves and perhaps realise that sometimes, the problem is just that their hardware isn't quite up to the demands being placed on it.

A 'once off' situation like this can probably be ignored, but if it's happening repeatedly with different tasks, it's time to check obvious things like GPU cooling, voltage stability, overall total loading, etc, and if there is no obvious hardware deficiency, give the hardware something a bit easier to crunch :-).