Scheduling sometimes fails completely

Query listing all relevant tickets

Gantt chart: 7 hours/day

Gantt chart:: 1 hour/day showing task structure

I think the problem is related to interpreting start/finish **dates** as **times**.

Tests were run on Feb 23rd. I notice lots of tasks are being scheduled to start on the 23rd (i.e. today). But this is happening despite them being blocked by tasks explicitly given start dates TOMORROW. Some kind of backward chaining then gives Task 63 (at 7 hours/day) given a finish date before its pre-specified start date!

What is the news from this plugin in general?

Replying to falkb:

What is the news from this plugin in general?

Sorry, all. I swapped out on a big project and haven't touched this in weeks.

I have some travel time coming up when I hope to get back in the swing.

Replying to anonymous:

Replying to falkb:

What is the news from this plugin in general?

Sorry, all. I swapped out on a big project and haven't touched this in weeks.

It is frustrating for everybody when The Day Job gets in the way like that. But sometimes a man's gotta do what a man's gotta do! Thanks for the work you have done and made available to us all.

I have some travel time coming up when I hope to get back in the swing.

Random thought: scheduling is a really hard task. I started looking at the scheduling code in the plugin, to see if I could see what was wrong. What stopped me was I couldn't see how much of Trac I would have to learn before I could fully understand the bit I wanted to work on. If you're working on this area, then documenting how the scheduling works, and how it interacts with the rest of Trac, might help others to help you...

(In [11416]) Bump up the maximum tickets to be returned from the query. Refs #9845.

I'm not sure this directly addresses this problem but I saw scheduling failures when I was omitting tickets.

Replying to anonymous:

For some sets of tasks, scheduling is so bad as to render the gantt chart useless. The problem might be related to short tasks. Attached are: * A listing of a small set of inter-related tasks * A JPeg of the Gantt chart produced (7 hours per day) showing most tasks being assigned start dates before those of the tasks blocking them. Inter-task relationships are shown, but have no effect on scheduling.

The width of the tasks is drawn badly (that is partly a bug and partly a limitation of showing hours of work on a day-scale chart) but they tasks are ordered top-to-bottom consistent with the dependencies. I believe that the schedule calculation is correct but the display is misleading.

* A JPeg of the Gantt chart produced for 1 hour per day (and removing all start dates), showing a reasonable flow of tasks given the relative task sizes and the actual blocking/blocked-by relationships. But, of course, the timescale is nonsense, and I can see no reason for the huge delay between the finish of 71 and the start of 72.

The gap is due to the start of the project and the end of the project both having explicit dates. All the work that follows the start is scheduled ASAP but task 72 is set to end on 3/9. The gap you see is slack time.

Replying to robert@interactive.co.uk:

I think the problem is related to interpreting start/finish **dates** as **times**. ...

I don't see a way to *not* treat them as times. Say I am scheduling 8 hours per day and I have a 1-hour task followed by a 8-hour task. If I ignore time, I schedule the 1-hour task at the start of the day then the 8-hour task either doesn't fit (so it gets started tomorrow, leaving a 7-hour gap) or it gets crammed in (overloading today with 9 hours of work).

With your data and the current code I see the last task elongated rather than showing slack time -- that's wrong -- but the start/finish times for the tasks seem quite reasonable (I used View Page Source to see this):

66, ... ,"2012-02-24 00:00","2012-02-24 01:00" ...

70, ... ,"2012-02-24 01:00","2012-02-24 05:00", ...

65, ... ,"2012-02-24 00:00","2012-02-24 06:00", ...

63, ... ,"2012-02-24 00:00","2012-02-27 01:00", ...

69, ... ,"2012-02-24 06:00","2012-02-27 01:00", ...

64, ... ,"2012-02-27 01:00","2012-02-27 03:00", ...

67, ... ,"2012-02-27 03:00","2012-02-27 04:00", ...

68, ... ,"2012-02-27 04:00","2012-02-27 05:00", ...

71, ... ,"2012-02-27 05:00","2012-02-28 01:00", ...

72, ... ,"2012-02-28 01:00","2012-03-09 07:00", ...

Replying to ChrisNelson:

The gap is due to the start of the project and the end of the project both having explicit dates.

Not sure about that.

My description says the attachment is/was produced for 1 hour per day removing all start dates. The start dates I originally used (for the 7 hours per day case) were 24th of February, the day after the graphs/figures were produced. But the 1-hour-per-day case shows work starting on the 7th. I certainly would not have specified that as a start date, so I don't see why it should have left any slack.

It looks to me like the system worked backwards to derive the start dates for the various tasks, correctly honouring the blocking links and durations. But for most tasks, it worked backwards from "today/now", not from the (correctly calculated) start of the last task.

Replying to ChrisNelson:

Replying to robert@interactive.co.uk:

I think the problem is related to interpreting start/finish **dates** as **times**. ...

I don't see a way to *not* treat them as times.

It's a while since I wrote that, but my hazy memory is that I suspected a problem rounding times to days --- where tasks were finishing in the middle of a day, the tasks they were blocking were being allowed to start at the start of that same day.

Say I am scheduling 8 hours per day and I have a 1-hour task followed by a 8-hour task. If I ignore time, I schedule the 1-hour task at the start of the day then the 8-hour task either doesn't fit (so it gets started tomorrow, leaving a 7-hour gap) or it gets crammed in (overloading today with 9 hours of work).

Oh, I can see you have to deal with times/hours -- it's just that the system didn't seem to be doing it right!

With your data and the current code

I see the magic phrase "current code". and I notice that you have start times on the 27th and 28th, which I didn't get in either of my graphs...

I've not updated the plugin since I reported the bug back in February. I'll try doing so (though it won't be for a few days, at least) and let you know if things have improved.

{{{ 66, ... ,"2012-02-24 00:00","2012-02-24 01:00" ... 70, ... ,"2012-02-24 01:00","2012-02-24 05:00", ... 65, ... ,"2012-02-24 00:00","2012-02-24 06:00", ... 63, ... ,"2012-02-24 00:00","2012-02-27 01:00", ... 69, ... ,"2012-02-24 06:00","2012-02-27 01:00", ... 64, ... ,"2012-02-27 01:00","2012-02-27 03:00", ... 67, ... ,"2012-02-27 03:00","2012-02-27 04:00", ... 68, ... ,"2012-02-27 04:00","2012-02-27 05:00", ... 71, ... ,"2012-02-27 05:00","2012-02-28 01:00", ... 72, ... ,"2012-02-28 01:00","2012-03-09 07:00", ... }}}

Replying to ChrisNelson:

... With your data and the current code I see the last task elongated rather than showing slack time -- that's wrong -- but the start/finish times for the tasks seem quite reasonable (I used View Page Source to see this): 66, ... ,"2012-02-24 00:00","2012-02-24 01:00" ...

So, 66 starts at the start of the specified start day and runs for one hour.

70, ... ,"2012-02-24 01:00","2012-02-24 05:00", ...

70 follows 66. It starts 1 hour into the same day and runs for 4 hours, ending 5 hours into the day.

65, ... ,"2012-02-24 00:00","2012-02-24 06:00", ...

65 starts at the start of the specified day and runs for six hours.

63, ... ,"2012-02-24 00:00","2012-02-27 01:00", ...

63 starts at the start of the specified day and runs for 8 business hours (skipping Saturday and Sunday 2-25 and 2-26) At 7 hours per day, there is an hour left to do on Monday, 2-27.

69, ... ,"2012-02-24 06:00","2012-02-27 01:00", ...

69 starts after 65 finishes. One hour on Friday and one on Monday.

64, ... ,"2012-02-27 01:00","2012-02-27 03:00", ...

64 starts when 63 is done and runs 2 hours.

67, ... ,"2012-02-27 03:00","2012-02-27 04:00", ...

67 starts when 64 is done and run one hour.

68, ... ,"2012-02-27 04:00","2012-02-27 05:00", ...

68 starts at the latest finish of 66 (02-24 01:00) & 67 (2-27 4:00)

71, ... ,"2012-02-27 05:00","2012-02-28 01:00", ...

71 starts at the latest finish of its predecessors and runs 2 hours on 2-27 and 1 on 2-28.

72, ... ,"2012-02-28 01:00","2012-03-09 07:00", ...

72 stretches from the end of 71 to its specified end date. I believe that's wrong.

Aside from 72 stretching, is there something wrong in there?

Replying to anonymous:

Replying to ChrisNelson:

The gap is due to the start of the project and the end of the project both having explicit dates.

Not sure about that. My description says the attachment is/was produced for 1 hour per day removing all start dates. The start dates I originally used (for the 7 hours per day case) were 24th of February, the day after the graphs/figures were produced. But the 1-hour-per-day case shows work starting on the 7th. I certainly would not have specified that as a start date, so I don't see why it should have left any slack. It looks to me like the system worked backwards to derive the start dates for the various tasks, correctly honouring the blocking links and durations. But for most tasks, it worked backwards from "today/now", not from the (correctly calculated) start of the last task.

It may have. The scheduling algorithm has been revised. Also, "today" has special meaning in at least some revisions where an unspecified start or finish date was handled as "today" and work was scheduled forward (ASAP) or backward (ALAP) from there.

Replying to anonymous:

Replying to ChrisNelson:

Replying to robert@interactive.co.uk:

... Oh, I can see you have to deal with times/hours -- it's just that the system didn't seem to be doing it right!

No doubt some iterations have not.

With your data and the current code

I see the magic phrase "current code". and I notice that you have start times on the 27th and 28th, which I didn't get in either of my graphs...

Sorry to be so long to respond that it's hard to reproduce what you were seeing/running.

I've not updated the plugin since I reported the bug back in February. I'll try doing so (though it won't be for a few days, at least) and let you know if things have improved.

Sure. Thanks.

today reconstructed here from previously attached screenshot, and exported to csv

today's trial how the use case behaves with today's svn revision

I attached the use case as attachment:query9845.csv file to this ticket. I checked how the current svn revision r12426 behaves with this use case. Look here: Some issues I noticed at first sight: 1. with today on 10/December, schedule=asap doesn't work correctly at all; please try it by yourself 2. a few dependency arrows point back to the past with hoursPerDay=7 3. the bar length of 63,66 and 65 are much too long compared to the estimated hours; I think it's because of the set enddate

P.S.: Uhm...Sorry, please, replace these ones with the English word: - Erweiterung = enhancement - Aufgabe = task - Arbeitspaket = work package

Replying to falkb:

I attached the use case as attachment:query9845.csv file to this ticket. I checked how the current svn revision r12426 behaves with this use case. Look here: ...

Which do you consider correct?

Replying to ChrisNelson:

Replying to falkb:

I attached the use case as attachment:query9845.csv file to this ticket. I checked how the current svn revision r12426 behaves with this use case. Look here: ...

Which do you consider correct?

Or do you consider both wrong and you're illustrating the affect of changing hours per day?

Replying to falkb:

I attached the use case as attachment:query9845.csv file to this ticket.

That's very helpful. Thanks.

... 1. with today on 10/December, schedule=asap doesn't work correctly at all; please try it by yourself

I think I understand why that happens and I'm not sure what to do about it. The logic is:

• tasks with an assigned start or end date get scheduled on the assigned dates
• in an ASAP schedule, you can't start an unscheudled task before *today* so anything without a predecessor gets scehedule today and we move foward

When you have a task with a fixed date in the past that follows one that start today, a lot of arrows go backward. I consider those backwards arrows to mean "Ooops, my dates are nonsensicle." What would you like to happen in this case?

2. a few dependency arrows point back to the past with hoursPerDay=7

Consider the arrow from 67 to 68. The JavaScript? for these two tasks includes the scheduled times:

...,"67 (new enhancement)","2012-03-09 00:00","2012-03-09 01:00",...
... "68 (new enhancement)","2012-03-09 01:00","2012-03-09 02:00",...

67 starts at the beginning of the work day and proceeds for 1 hour, then 68 starts one hour into the day and continues for another hour. Unforunately, in a day-scale chart, I can't show these partial days. Ideally, the JavaScript? would know how to display partial days but that's a *lot* of work in code I don't really undertand.

3. the bar length of 63,66 and 65 are much too long compared to the estimated hours; I think it's because of the set enddate

Yes, the logic goes:

• Working from the goal date backwards, compute the finish date/time based on successor tasks
  • The start of the task is the explicit start (if provided) or the finish minus the duration

I can see that the second step could be followed by: if the finish is "soft" (derived from dependencies) and the start is "hard" (explicit), adjust the finish to be hard start + duration. That's probably not hard to do and it makes a certain amount of sense.

(In [12427]) Dates derived from dependencies are not fixed. Refs #9845.

If A has a fixed start and a successor, B, with a fixed end, an ALAP schedule used to stretch A to run from its start to B's start. Now it shows A starting on schedule, ending after the expected duration, and with slack before B's start. (And vice versa for ASAP.)

ALAP schedule with slack (after last code change)

After r12427, I see

Replying to ChrisNelson:

Or do you consider both wrong and you're illustrating the affect of changing hours per day?

Actually, I just took the TracJsGanttChart? ticket with highest priority and thought it might help to recheck with the current SVN if it's fixed in the meanwhile and to help out with better input data. I just took 1 minutes for a check and just saw thoses 3 issues without checking anything in detail... :)

Replying to ChrisNelson:

After r12427, I see

Hmm... if e.g. 70 is blocking 71, they should never be in parallel at a time, shouldn't they?

Replying to falkb:

Replying to ChrisNelson:

After r12427, I see

Hmm... if e.g. 70 is blocking 71, they should never be in parallel at a time, shouldn't they?

They aren't, really. The JavaScript? says:

...,"#334:th9845-8:70 (new enhancement)","2012-03-08 00:00","2012-03-08 04:00",...
...,"#335:th9845-9:71 (new task)","2012-03-08 04:00","2012-03-08 07:00",...

So 70 starts at the start of the day and 71 four hours later, when 70 completes. I just can't show that on a day-scale chart.

Replying to ChrisNelson:

After r12427, I see ...

anyway, it looks like [12427] fixes the bar length! Cool :-)

Replying to ChrisNelson:

They aren't, really. The JavaScript? says: {{{ ...,"#334:th9845-8:70 (new enhancement)","2012-03-08 00:00","2012-03-08 04:00",... ...,"#335:th9845-9:71 (new task)","2012-03-08 04:00","2012-03-08 07:00",... }}} So 70 starts at the start of the day and 71 four hours later, when 70 completes. I just can't show that on a day-scale chart.

I see! Yes, understood.

Replying to ChrisNelson:

* in an ASAP schedule, you can't start an unscheudled task before *today* so anything without a predecessor gets scehedule today and we move foward When you have a task with a fixed date in the past that follows one that start today, a lot of arrows go backward. I consider those backwards arrows to mean "Ooops, my dates are nonsensicle." What would you like to happen in this case?

IMO this is a big disadvantage. Much better would be if dependencies ruled over setting today as start date. This likely means you need to run an estimate first before building up the chart simply from to today to future.

Replying to falkb:

Replying to ChrisNelson:

* in an ASAP schedule, you can't start an unscheudled task before *today* so anything without a predecessor gets scehedule today and we move foward When you have a task with a fixed date in the past that follows one that start today, a lot of arrows go backward. I consider those backwards arrows to mean "Ooops, my dates are nonsensicle." What would you like to happen in this case?

IMO this is a big disadvantage. Much better would be if dependencies ruled over setting today as start date. This likely means you need to run an estimate first before building up the chart simply from to today to future.

OK. How does that work? Let's say we have A -> B with B having a start or finish date in the past and A unconstrained. We sort by dependency, start scheduling A today, add its duration to get finish, go to schedule B and find that the fixed start is before the candiate finish. The scheduler only makes one pass so how do I fix that? I could figure out how much earlier the schedule would have to start so A finished before B, give up, and take another forward pass starting today minus that offset.

Or I could pause and work backwards, adjusting every start and finish of all already-scheduled tickets by the offset. But if the offset is, say, two days, a task that was schedule to take all of a Monday now falls on Saturday which violates the calendar. I guess I could use the calendar to find the work time xx hours earlier than the original scheduled dates.

Of course, which ever way this works, I'd want to ultimately show the "overdue" status in the chart. Work which hasn't begun but is scheduled in the past shows up red or something.

If a manager wants to make a ticket plan, he usually just sets the ticket dependencies and the planned time for each ticket. Then he sets a desired milestone date as the only fixed time. Next he generates the Gantt chart to see when things must start in ASAP and ALAP mode. This means he can see when the project must start at the latest. If he will notice that start is before today, he either must move the milestone date more forward in the future or things must set to be in parallel or he must reduce the planned ticket times. You see there is no relation to a "today" at all, everything depends on the milestone date, the dependencies and the ticket durations. Please, say Goodbye to your ASAP rule "you can't start an unscheudled task before *today*". :-)

Technically, I would try to let the scheduler an estimation run forward which probably results in an negative offset. Then run backward and reduce each start time by that offset. In some situations (newly hit weekend or other calendar event) the backward run must increase the offset more to the past until it fits again. This way your backward run might result in a bigger offset than the forward scheduler run had estimated.

Could you post your screenshots of this use case for 1h/day and 7h/day, please? Then let's compare with attachment:TicketTable.JPG for ALAP mode.

Replying to falkb:

If a manager wants to make a ticket plan, he usually just sets the ticket dependencies and the planned time for each ticket. Then he sets a desired milestone date as the only fixed time.

For a first pass, I find I'm more likely to set the tasks, dependencies, and durations and do an ASAP to see "how soon can I get this done." Then pick a date comforbably later than that as the due date and switch to ALAP scheduling.

... You see there is no relation to a "today" at all, everything depends on the milestone date, the dependencies and the ticket durations. Please, say Goodbye to your ASAP rule "you can't start an unscheudled task before *today*". :-)

That is one solution. But I have to pick *some* date as the anchor for an ASAP schedule. Maybe I could start at the epoch, schedule it once, then measure slack and close up the schedule. (I think it would be the smallest (non-zero) slack that I'd get rid of.

Technically, I would try to let the scheduler an estimation run forward which probably results in an negative offset. Then run backward and reduce each start time by that offset. In some situations (newly hit weekend or other calendar event) the backward run must increase the offset more to the past until it fits again. This way your backward run might result in a bigger offset than the forward scheduler run had estimated.

Some of the leading academic scheduling algorithms do "forward/backward justification" which does something like that.

1 and 7 hours per day

Replying to falkb:

Could you post your screenshots of this use case for 1h/day and 7h/day, please? Then let's compare with attachment:TicketTable.JPG for ALAP mode.

Replying to ChrisNelson:

Replying to falkb:

Could you post your screenshots of this use case for 1h/day and 7h/day, please? Then let's compare with attachment:TicketTable.JPG for ALAP mode.

[[Image(th9845.png)]]

1h/day looks intuitively correct to me. There's a clash with 63 and 64 because 64 is actually blocked by 63, but on the other hand it traverses the tickets back from milestone->72->71->67->64 and resolves those dependencies and there is no duration left because of the fixed start date of 63. That back arrow actually must be a lightning arrow. :)

7h/day is harder to understand because of the missing resolution but it makes sense if I consider 72 starts on the first hour of the day. So 71 is on the day before, and 71,67,64 all fit into that day before 72. And 63 starts on that fixed date, so the time gap is also correct.

So I think this ticket #9845 is fixed now successfully, the ASAP story should continue in another ticket. I suggest #10311 for this.

Replying to falkb:

7h/day is harder to understand because of the missing resolution but it makes sense if I consider 72 starts on the first hour of the day. So 71 is on the day before, and 71,67,64 all fit into that day before 72. And 63 starts on that fixed date, so the time gap is also correct.

Except you want to let 72 start on the end-of-day minus its 3 hours. In this case 71 would also fit into the same day before the hours of 72. Then you probably would close this ticket #9845 after fixing it this way.

Replying to falkb:

Replying to falkb:

7h/day is harder to understand because of the missing resolution but it makes sense if I consider 72 starts on the first hour of the day. So 71 is on the day before, and 71,67,64 all fit into that day before 72. And 63 starts on that fixed date, so the time gap is also correct.

Except you want to let 72 start on the end-of-day minus its 3 hours. In this case 71 would also fit into the same day before the hours of 72. Then you probably would close this ticket #9845 after fixing it this way.

But it does. The details are:

..."72 (new task)","2012-03-09 04:00","2012-03-09 07:00",...
..."MS:th9845","2012-03-09 00:00","2012-03-09 07:00",...

Note that 72 finished at the milestone finish. (I'm not sure why the milestone seems to have a full-day duration but all the internal logic "knows" that MS have no duration and use only the finish for any calculations.)

Replying to ChrisNelson:

Replying to falkb:

Replying to falkb:

7h/day is harder to understand because of the missing resolution but it makes sense if I consider 72 starts on the first hour of the day. So 71 is on the day before, and 71,67,64 all fit into that day before 72. And 63 starts on that fixed date, so the time gap is also correct.

Except you want to let 72 start on the end-of-day minus its 3 hours. In this case 71 would also fit into the same day before the hours of 72. Then you probably would close this ticket #9845 after fixing it this way.

But it does. The details are: {{{ ..."72 (new task)","2012-03-09 04:00","2012-03-09 07:00",... ..."MS:th9845","2012-03-09 00:00","2012-03-09 07:00",... }}} Note that 72 finished at the milestone finish. (I'm not sure why the milestone seems to have a full-day duration but all the internal logic "knows" that MS have no duration and use only the finish for any calculations.)

Looking again, I see you're right about 71 not starting late enough.

remember 72 is 3 hours long, and 71 is also 3 hours long. So they should fit into one day. Even 67 should fit into the same last day.

(In [12440]) EXPERIMENTAL Add start, finish options for scheduler. Refs #9845.

When doing an ASAP schedule of A and B where A is required for B but B has a fixed start or finish date in the past, the Gantt chart would show a backward-pointing dependency arrow. This was because the schedule started today by default (on the theory that new work can't start in the past) so A started now and proceeded into the future but then B's explict date made it show up before A.

Now you can say [[TracJSGanttChart(schedule=asap,start=2012-01-01,...)]] to override the default start of today. (Similarly, you can use finish with alap to override the default.

It may be better to let the default start be the beginning of time for ASAP. I'm not sure what the corresponding end of time for an ALAP schedule would be. And those may only be valuable if at least one task in the project has a fixed date.

Replying to ChrisNelson:

(In [12440]) EXPERIMENTAL Add start, finish options for scheduler. Refs #9845.

This results to It means ASAP works then with the given test case now. Remaining backward-arrows are because of the fixed start and end dates, but that's normal.

It seems to me your experimental start=2012-01-01 should act as an alternative to "forward/backward justification", right? Not sure what your intention/strategy is now.

Replying to falkb:

It seems to me your experimental start=2012-01-01 should act as an alternative to "forward/backward justification", right? Not sure what your intention/strategy is now.

Perhaps I should have said "incomplete" rather than "experimental." I believe that allowing the user to specify the start or finish of the schedule is useful and valuable and I think that the implementation is OK, as far as it goes. I need to document the option (in macro help and on TH) and I want to consider a better default than "today." Python provides datetime.MINYEAR and datetime.MAXYEAR so I could use the "beginning of time" for ASAP and the "end of time" for ALAP but I need to experiment to see what that does if you have no explicit constraints in your project.

Replying to ChrisNelson:

... I want to consider a better default than "today." ...

Thinking naively, the worst case that can be as start date is: MIN(allFixedStartDates()) - SUM(allTicketDurations()). Am I right?

Replying to falkb:

Replying to ChrisNelson:

... I want to consider a better default than "today." ...

Thinking naively, the worst case that can be as start date is: MIN(allFixedStartDates()) - SUM(allTicketDurations()). Am I right?

No, I think it's MIN(allFixedStartDates()) - SUM(allPreceedingTicketDurations()). That is, if I have A -> B -> C and B has a fixed date, I only have to take off A's duration, not C's.

Replying to ChrisNelson:

Replying to falkb:

Replying to ChrisNelson:

... I want to consider a better default than "today." ...

Thinking naively, the worst case that can be as start date is: MIN(allFixedStartDates()) - SUM(allTicketDurations()). Am I right?

No, I think it's MIN(allFixedStartDates()) - SUM(allPreceedingTicketDurations()). That is, if I have A -> B -> C and B has a fixed date, I only have to take off A's duration, not C's.

But it's never that simple. If I add to the above D -> C where D is really long then D's start could be earlier than start(B) - dur(A).

Replying to ChrisNelson:

But it's never that simple. If I add to the above D -> C where D is really long then D's start could be earlier than start(B) - dur(A).

That's why my plain SUM(allTicketDurations()). At least it makes you independend from "the beginning of time", because it just uses its own given data.

Replying to falkb:

Replying to ChrisNelson:

But it's never that simple. If I add to the above D -> C where D is really long then D's start could be earlier than start(B) - dur(A).

That's why my plain SUM(allTicketDurations()). At least it makes you independend from "the beginning of time", because it just uses its own given data.

Yes, that certainly is an easily-calculated worst case.

(In [12764]) Bug in start/finish option experiment. Refs #9845, #9648.