Not quite accurate in my book.

Using Speedy's example,

CMD2_2052-2I7T_A.clustersOccur-3D0G_A.clustersOccur_14_57349_57735_57633_ 57667_0--

Means:

..._14_0 was the parent. This hit a wall - 6hr or 12-hr.

..._14_57349_57735_0 was one child produced - there may have been many. Each child has ~387 positions (57735-57349 + 1 for the fencepost)

Hence there would probably be other children: ..._14_57736_58122_0 ..._14_58123_58529_0 and so on - not possible to tell since the numbering scheme doesn't show the parent unit's start and end position numbers.

..._14_57349_57735_0 was crunched and again hit a wall.

..._14_57349_57735_57633_57667_0 was one grandchild unit produced - and the size is down to 35 positions per unit.

Grandchildren produced could have been
...
..._14_57349_57735_57563_57597_0
..._14_57349_57735_57598_57632_0
..._14_57349_57735_57633_57667_0 (Speedy's target unit)
..._14_57349_57735_57668_57702_0
..._14_57349_57735_57703_57735_0
The '57735' here is merely indicates the LAST child of its generation. It has no further significance.

For instance, from my own results (on child level)
2067-2G59_A.clustersOccur-2IAE_A.clustersOccur_2_10728_12719_0--
2067-2G59_A.clustersOccur-2IAE_A.clustersOccur_2_12720_14711_0--

2067-2G59_A.clustersOccur-2IAE_B.clustersOccur_49_21103_21160_0--
2067-2G59_A.clustersOccur-2IAE_B.clustersOccur_49_21161_21218_0--
2067-2G59_A.clustersOccur-2IAE_B.clustersOccur_49_21219_21276_0--

2067-2G59_A.clustersOccur-2O61_A.clustersOccur_1_4644_5959_1--
2067-2G59_A.clustersOccur-2O61_A.clustersOccur_1_5960_7275_1--
2067-2G59_A.clustersOccur-2O61_A.clustersOccur_1_7276_8591_0--

(note the contiguous position blocks 10728..14711, 21103..21276, 4644..8591 - and that the terminal _0 or _1 is also not significant - each make-up job is sent out as two separate tasks since this is a replication-2 project - allotment of _0, _1 tasks may occur to the same machine but NOT sometasknumber_0 AND sometasknumber_1 to the SAME machine for the SAME tasknumber)

Thank you Mysteron347 for having already done the most tedious part of what I intended to post for Speedy51.
Nothing to change to it, I only want to add that from Speedy's reference to a "...14_ 57349_ 57735_ 57458_ 57492_ 0" WU there have also been three more grandchildren (at least) :
...14_ 57349_ 57735_ 57458_ 57492_ 0
...14_ 57349_ 57735_ 57493_ 57527_ 0
...14_ 57349_ 57735_ 57528_ 57562_ 0
before the ones you have listed.

Now I think that Speedy was also questioning about the shortness of
...14_ 57349_ 57735_ 57633_ 57667_ 0 (0.13 hour)
versus the long lasting
...14_ 57349_ 57735_ 57458_ 57492_ 0 (4.24 hours).

After watching so many HCMD2 WUs running in fast and slow devices I think I may say that positions of a given job fall into only two categories, easy and tough, and that, in a given device, all easy positions need about the same short time to compute, and all tough ones also need about the same long time.
The final duration of a HCMD2 work unit will depend on the mix of easy and tough positions in this work unit.

As grandchildren or even great-grandchildren WUs are generated the number of positions per WU is smaller and smaller and the probability that some contain nearly only easy ones or nearly only tough ones is higher and higher.

In Speedy's case of 35 positions per WU one can find that the easy positions need at most 0.13 / 35 * 3600 = 13.37 seconds to compute a single one, and that tough positions need at least 4.24 / 35 * 3600 = 436.11 seconds (or 7 mn and 16 s) to compute a single one, for this pair of molecules and this particular device.
And these numbers are perfectly consistent with what I have been able to observe in my devices, e.g. easy positions below 1 second and tough ones up to 3 minutes in a 3.0 GHz Q6600.

Thank you Mysteron347, SekeRob & JmBoullier for answering my questions. I understand now how the numbering of tasks works.

When I was asking about run time differences.

My system is a I7 980X @ 3.33ghZ

I picked up two today, but I also picked up 8 Beta WU's. It says something for how scarce HCMD2 are getting if Betas are more plentiful.

Let's get this project polished off so the scientists can get working on the results!

Come on Lyon!