Indeed they are.

Take the task ID eg:

CMD2_ 2500-1HCI_ A.clustersOccur-2O72_ A.clustersOccur_547_4413994_4414790_4414566_4414790_1

After the second "clustersOccur" is a sequence of digit-groups.
The first identifies the particular protein pairing (IIRC)
The last identifies the "replication" - 0 or 1 (usually)

Replications greater than 1 (in this research) mean that the job is being re-sent (no reply from receiver, error, inconclusive, not received by deadline or other problems)

If you just have these two numbers, this indicates it's a parent work unit.

If processing of the parent had not reached 60% after 6hrs processing (or had reached 60% but hadn't completed after 12 hrs processing) then the processing is stopped and the unit was returned. New work units ("child" units) are then created to process the remaining "positions."

These child units are identified by an extra pair of numbers (the start and end position numbers) between the first and last.

This can happen a second (third, fourth...) time and an extra pair of digits appear.

So - two numeric sequences after the second "clusterOccur" means a PARENT, four means a CHILD, six a GRANDCHILD and so on.

The significance is that we've been told that GRANDCHILDREN will only be sent out in this last batch (2500..2544) after all of the CHILDREN have been sent out. Also, most (85%, IIRC) work units are fully processed - so only 15% produce children. And 15% of those will produce grandchildren....

So - the appearance of grandchildren would seem to indicate that we've started to process the last 2% or so of the work for batches 2500..2544. There are of course, still children being processed, and these should be returned within 10 days. There'll be a flurry of work after that to process any grandchildren produced by the children being processed now, a few late/error, etc. units to make up, maybe a few great-grandchildren - but it should be all over by the end of September...

Since the grandchildren were not distributed and averaged out in the mix, is it fair to assume our client DCF's (duration correction factor) are currently waaaaaay off? ie: do grandchildren, on average, have less meat on the bone w.r.t. CPU crunch time?

The question I have .... will my previous 4 day cache that is now converting over to grandchildren ACTUALLY become a 2 day cache until the DCF re-adjusts in a few days (thus a false thinking that you're safe for a certain color badge or Nth year based on the old Children DCF might find you a few days short if the project were to suddenly run out --- yes, I'm cutting it that close ;-D ).

That's probably right, however.... if these are being handed out in sequence order, then in the first 12 hours we went through 2500, 2501, 2502, and 2503.... which seems to be a pretty fast clip. Weren't there about 68 sets in this bunch?

The other question is --> do grandchildren take the SAME average time to crunch ... because if not, then the burn rate of that estimated 500K is going to be much quicker.

I'm counting on between 5 and 8 days (strictly for my own planning and goal).