Rewrite of Scheduler planning
ClosedPublic

Authored by TallFurryMan on Oct 25 2018, 7:47 PM.

Details

Summary

This is a full rewrite and verification of all steps of evaluation of a list of scheduler jobs with the following existing constraints:

  • Dark sky, which schedules a job to the next astronomical dusk/dawn interval.
  • Minimal altitude, which schedules a job up to 24 hours away to the next date and time its target is high enough in the sky.
  • Moon separation, combined with altitude constraint, which allows a job to schedule if its target is far enough from the Moon.
  • Fixed startup date and time, which schedules a job at a specific date and time.
  • Culmination offset, which schedules a job to start up to 24 hours away to the next date and time its target is at culmination, adjusted by an offset.
  • Amount of repetitions, eventually infinite, which allows a job imaging procedure to repeat multiple times or indefinitely.
  • Fixed completion date and time, which terminates a job at a specific date and time.

The UI now displays target altitudes at the current simulation time, and at startup and completion times. It also displays the lead time or gap time between jobs to help with imaging time optimization. Warnings appear in some situations for the user to detect problematic situations, such as a job completing under the minimal altitude.

The rewrite starts by estimating the imaging duration of each job, and eventually reorders them based on option "Sort Jobs by Altitude and Priority".
The reordering algorithm sorts jobs by altitude, considering a setting target is higher than a rising target.
When the option is enabled, targets will be automatically sorted whenever jobs are evaluated, using the current simulation time for altitude calculations.
When the option is not enabled, a button is available to reorder jobs manually, using the first job startup time for altitude calculation.
This reordering helps to optimize imaging time when preparing a schedule with multiple targets.

The rewrites then proceeds to sequence jobs based on their order in the list, resolving each constraint one after the other.
The sequencing algorithm makes sure there is a minimal gap between jobs, as set in option "Lead Time".
Note that when executing, Scheduler will immediately start a job planned away from current simulation time by an offset smaller than that lead time.
The sequencing algorithm will attempt to resolve all constraints ten times before considering those can't be achieved.
There is no limit to the number of jobs that can be inserted in the queue, but the bounded number of attempts effectively poses a restriction to automated scheduling.

Known bug: The algorithm is not entirely optimized yet, and adding observations may slow the reactivity of the user interface on low-end systems while evaluating.
Known bug: The updated values of the Ekos options are taken into account at the next evaluation of the job list, and not automatically after the options pop-up is dismissed. As there is no periodic evaluation of the job list, the end-user needs to click the "refresh" icon to trigger a new evaluation with the updated settings.

Test Plan

Use case: start the observation of a target when its altitude is higher than X degrees

If the scheduler job to modify was created previously, double-click its line in the job table to enter edit mode. If the job is being created, the constraint can be set immediately.

Enable the "Minimum Altitude" constraint and specify a minimum altitude the target should be visible at from the KStars geographic location before starting the observation. The constraint is enabled by default with a value of 15 degrees.

Target observation will be then scheduled in the interval between the moment it rises higher than the minimum altitude, to the moment it sets lower that the minimum altitude plus 3 degrees. The altitude cut-off is there to avoid the situation where a scheduler job execution is started and aborted after a few minutes because its preparation steps - focus, alignment and guiding - delayed the capture step.

Known bug: You can set any altitude in [15,90] in the user interface. If you disable the constraint, the minimum value of 0 degrees is enforced. Although the code managing the constraint will only enforce the numerical limit when its value is higher than -90 degrees, the user interface will not allow an minimum altitude lower than 15 degrees, and the scheduler code will not allow a target to be lower than 0 degrees for observation.

Known bug: The altitude cut-off value considered when the target sets cannot be customized.

Use case: start the observation of a target when its angle to the Moon is greater than X degrees

If the scheduler job to modify was created previously, double-click its line in the job table to enter edit mode. If the job is being created, the constraint can be set immediately.

Enable the "Moon Separation" constraint and specify a minimum angle the target and Moon should be separated from, as seen from the KStars geographic location, before starting the observation. The constraint is disabled by default. Target will be then scheduled on the day that separation is higher than the minimum angle.

Known bug: The implementation of this constraint is currently embedded into the altitude constraint, and prevents the altitude check from succeeding if the angle is not large enough. However, the altitude constraint will only look for a suitable date and time in the next rise and set cycle of the target, thus 24 hours at maximum. As the separation with the Moon will not change much during that time, the job will often end up invalid.

Use case: start the observation of a target during night time only

If the scheduler job to modify was created previously, double-click its line in the job table to enter edit mode. If the job is being created, the constraint can be set immediately.

Enable the "Twilight" constraint. The constraint is enabled by default.

Target observation will be then scheduled in the interval between the astronomical dusk to the astronomical dawn, minus the lead time set in the Ekos options. The lead time cut-off is there to avoid the situation where a scheduler job execution is started and aborted after a few minutes because its preparation steps, focus, alignment and guiding, delayed the capture step.

Known bug: The twilight constraint uses the astronomical dawn and dusk of the current simulation day, even if the target is scheduled to a date that is different. Though there is not much change to that interval day after day, it will cause unexpected delays or lost imaging time when an automated observatory is set to sleep for a few days.

Use case: start the observation of a target when it is culminating

If the scheduler job to modify was created previously, double-click its line in the job table to enter edit mode. If the job is being created, the constraint can be set immediately.

Change the start-up conditions to the "Culmination" constraint, and specify a positive or negative offset in minutes to the culmination time of the target from the KStars geographic location before starting the observation. The start-up constraint is set to "as soon as possible" by default.

Target observation will then be scheduled to start at the next culmination date and time, adjusted by the specified offset.

Known bug: Because the culmination calculation has a certain level of incertitude, it may happen that the schedule is not stable when evaluated at different date and time values: when re-evaluated later, the job may be found starting after the effective adjusted culmination, and pushed to the next day as jobs cannot be scheduled sooner than they are currently occurring at during an evaluation. To resolve this situation, increase the lead time in the Ekos options to relax the precision of the job start-up time.

Use case: start the observation of a target at a fixed time

If the scheduler job to modify was created previously, double-click its line in the job table to enter edit mode. If the job is being created, the constraint can be set immediately.

Change the start-up conditions to the "Start At" constraint, and specify a date and time at which starting the observation. The start-up constraint is set to "as soon as possible" by default. The date and time is local to the KStars geographic position.

Target observation will then be scheduled to start at the indicated date and time.

Known bug: Because the real conditions in which the jobs execute may make the duration of the previous job longer than expected, it may happen that some jobs are aborted before starting because the start-up time is passed at the moment they are started. It is currently not possible to customize the duration of the preliminary steps of a job, and a job scheduled to start at a fixed time will not accept to start at a different time. To partially resolve this situation, increase the lead time in the Ekos options to relax the precision of the job start-up time and help with the schedule of prior jobs.

Use case: finish the observation of a target at a fixed time

If the scheduler job to modify was created previously, double-click its line in the job table to enter edit mode. If the job is being created, the constraint can be set immediately.

Change the completion conditions to the "Finish At" constraint, and specify a date and time at which completing the observation. The completion constraint is set to "finish sequence" by default. The date and time is local to the KStars geographic position.

Target observation will then be scheduled to repeat until the indicated date and time. Because the real conditions in which the job execute may make the duration of that job longer than expected, using a fixed repeat count may result in a completion time later than planned. Using a fixed completion time ensure the following job will start at the expected fixed time.

Use case: change the order of observation of targets

If an observation target is currently edited, exit the edition mode by clicking on the "check" icon.

Open the Ekos option, and disable option "Sort Jobs per Altitude and Priority" in the Scheduler tab.

Select an observation target by clicking on its line in the job table. That line is highlighted as a result, and the state of icons "up" and "down" above the job table comply with the following rules:

  • If the selected job is the first of the list, the "up" icon is disabled.
  • If the selected job is the last of the list, the "down" icon is disabled.
  • If the selected job is the only one in the list, the "up" and "down" icons are disabled.
  • In other situations both "up" and "down" icons are enabled.

Clicking the enabled "up" button will swap the selected job with its previous sibling. Clicking the enabled "down" button will swap the selected job with its following sibling.

The schedule of the observation targets following and including the swapped jobs will re-evaluate automatically after the operation.

Use case: sort observations of targets per their altitude

If an observation target is currently edited, exit the edition mode by clicking on the "check" icon.

Open the Ekos option, and disable option "Sort Jobs per Altitude and Priority" in the Scheduler tab.

Examine the start-up time of the first observation target of the job table. When the "sort" icon is clicked, the algorithm computes the altitudes of all observation targets, reorders them per their computed altitude, then re-evaluates the schedule of all jobs.

The sort algorithm orders altitude from set to rise:

  • If target A is setting and target B is rising, then A will be sorted before B.
  • If target A is lower than target B, but is setting, then A will be sorted before B.
  • If target A is lower than target B, but is rising, then A will be sorted after B.

Use case: systematically sort observations of targets per their altitude

If an observation target is currently edited, exit the edition mode by clicking on the "check" icon.

Open the Ekos option, and enable option "Sort Jobs per Altitude and Priority" in the Scheduler tab. When that option is enabled, evaluation of targets will systematically reorder observations. The algorithm computes the altitudes of all observation targets _at the current simulation time it is executed_, reorders them per their computed altitude, then re-evaluates the schedule of all jobs.

The sort algorithm orders altitude from set to rise:

  • If target A is setting and target B is rising, then A will be sorted before B.
  • If target A is lower than target B, but is setting, then A will be sorted before B.
  • If target A is lower than target B, but is rising, then A will be sorted after B.

Diff Detail

Repository
R321 KStars
Branch
improve__visual_sort (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 4531
Build 4549: arc lint + arc unit
TallFurryMan created this revision.Oct 25 2018, 7:47 PM
Restricted Application added a project: KDE Edu. · View Herald TranscriptOct 25 2018, 7:47 PM
Restricted Application added a subscriber: kde-edu. · View Herald Transcript
TallFurryMan requested review of this revision.Oct 25 2018, 7:47 PM
wreissenberger requested changes to this revision.Oct 28 2018, 3:35 PM

There are some things that do not work correctly:

  1. Select "Sort jobs by Altitude and Priority" and load a schedule with several jobs with priority 10. Now select a sequence for editing and change the priority of a sequence, e.g. first from 10 to 1. In my case, the job jumps on position 1. Up to here everything is fine. If you change it now to 15, it moves down, but the selection does not follow to the new position. In my case, the first line remains highlighted.
  2. Change the option "Sort jobs by Altitude and Priority". No matter in which direction, the Scheduler tab is not updated. If the option is set, the jobs remain unsorted. If the option is not set, the position buttons are disabled.

In general, sorting by altitude and priority is kind of weird for me, since the table shows only the score value. For me sorting is not transparent. I would really appreciate if the table shows altitude and priority to make the sorting order more comprehensive.

This revision now requires changes to proceed.Oct 28 2018, 3:35 PM
yurchor added inline comments.
kstars/ekos/scheduler/scheduler.cpp
973

Is this second semicolon important?

1782

Typo: alitude->altitude

2064

Typo: best->the best

kstars/ekos/scheduler/scheduler.h
446

Actually, this should be

* param observationDateTime when ...

to not confusing doxygen.

Thanks for this report!

  1. Yes, agreed, the way the QWidgetTable works for selection is implemented and documented in such a contrived way that it appears to be bugged. SelectRow() should be used, but never results in the right effect. There are apparently several follow-up signals that make a mess with the rendering...
  2. I agree also there, the behavior of the sort option is opaque. Well, for the altitude at least. It works well only when the targets are all asap, and all rising. I plan to change the order predicate so that prioritary targets are the one setting, not the highest ones. Moreover, there's no point in sorting both in priority and altitude probably. Except for infinitely looping jobs, priority is a weird feature now...

This weekend I found out that most calculations in the scheduler were using the current date instead of the job date (which could be the next day, thus offset with ~15min), and that sometimes local to universal conversions were using the time zone of the system running KStars, instead of the geographic location of the observatory. But trying for instance to calculate the culmination of a target at a future date is somewhat tricky with the current code.

kstars/ekos/scheduler/scheduler.cpp
973

Seems to be a copy&paste error, thanks!

2064

Arguable but OK. Will address the FIXME soon anyway.

kstars/ekos/scheduler/scheduler.h
446

Thanks, I'll sync declaration and definition.

I also plan to add altitude for startup time, with an icon showing whether the target is rising or setting.

This is still a WIP. Posting advancements to share progress.

  • Fix altitude cutoff issue, rewrite calculateAltitudeTime.
  • Fix altitude cutoff issue, rewrite calculateAltitudeScore.
  • Fix stability of culmination search, rewrite calculateCulminationOffset.
  • Rewrite getDarkSkyScore to use an argument date.
  • Fix job reordering algorithm.
  • Fix reset and evaluation of jobs when they are moved in the list.
  • Rewrite Moon separation algorithm.
  • Rewrite total score consolidation.
  • Adjust weather score documentation.
  • Integrity fixes for startup and estimated times of SchedulerJob.
  • Remove logs for astronomical twilight.
  • Fix for decimale display in altitude constraint log.
  • Rewrite findAltitude to duplicate code.
  • Rewrite calculateAltitudeTime.
  • Make getDarkSkyScore const on Scheduler.
  • Rewrite calculateCulmination to duplicate code.
  • Make getWeatherScore const on Scheduler.
  • Rewrite score calculations to duplicate code.
  • Rewrite planning algorithm.
  • fixup! Rewrite findAltitude to duplicate code.
mutlaqja requested changes to this revision.Nov 3 2018, 2:05 PM
mutlaqja added inline comments.
kstars/ekos/scheduler/scheduler.cpp
641

Would this lead to memory leak or is it reparented when setItem(..) is used?

938

extra ;

973

extra ;

1513

can such jobs be scheduled later than 24 hours later?

This revision now requires changes to proceed.Nov 3 2018, 2:05 PM
TallFurryMan marked an inline comment as done.Nov 3 2018, 2:52 PM
TallFurryMan added inline comments.
kstars/ekos/scheduler/scheduler.cpp
1513

There is no temporal boundary anymore, jobs can be even be scheduled a few years in advance.
So far in the future obviously doesn't make any sense, but a schedule can be now be created spanning several weeks.
If during runtime the Scheduler is robust enough and the setup stable enough, this algorithm is a solid base for a robotic observatory.
I will allow customization of step duration, and add information about "lost" imaging time between jobs.

2281

This will require deeper investigation. KStarsDateTime possibly has a bug with TimeSpec.
Julian Day must be calculated from Universal Time, which KStarsDateTime doesn't enforce in its constructor.

TallFurryMan planned changes to this revision.Nov 3 2018, 2:52 PM
TallFurryMan added inline comments.Nov 3 2018, 8:37 PM
kstars/ekos/scheduler/scheduler.cpp
641

Not sure I understand the question. This code is only executed when adding a new line at currentRow.
If it is about the lone new, documentation states all cells are deleted when the widget is destroyed (which breaks the allocation owner rule, but well...)

Still WIP, need to rebase, fix a few logs and add altitude as a column.

  • Rewrote algorithm documentation.
  • Fixes from Phabricator comments.
TallFurryMan abandoned this revision.Nov 3 2018, 8:38 PM
TallFurryMan reclaimed this revision.
TallFurryMan planned changes to this revision.
TallFurryMan marked 6 inline comments as done.Nov 3 2018, 8:41 PM

Still WIP, not entirely rebased, but shows were the rewrite is at.
UI is probably prettier than it was before, but that won't help the first Ekos tab.
Altitude sorting is clarified with the UI rework, but clicking the sort button is not stable.
Row selection is still to be fixed.
All schedule consolidation issues are now fixed!
I'm nearly finished, still quite a bit of testing needed.

  • Fix move still possible just after enabling sort.
  • Fix jobs not reset after move, refactor evaluation.
  • Optimize UI refresh with manual content update after cell assignment refactoring.
  • Refactor cell assignment when adding a new job or editing one.
  • Reorder jobs automatically when "Sort Jobs by Altitude and Priority" is enabled.
  • Add a few assertions.
  • Fix management of score value zero, which is acceptable for observation.
  • Rewrite dark sky score calculation to consider seconds at most when comparing times.
  • Rewrite altitude score calculation to not modify the job startup time, move logs to caller.
  • Fix altitude cutoff issue, rewrite calculateAltitudeTime.
  • Fix altitude cutoff issue, rewrite calculateAltitudeScore.
  • Fix stability of culmination search, rewrite calculateCulminationOffset.
  • Rewrite getDarkSkyScore to use an argument date.
  • Fix job reordering algorithm.
  • Fix reset and evaluation of jobs when they are moved in the list.
  • Rewrite Moon separation algorithm.
  • Rewrite total score consolidation.
  • Adjust weather score documentation.
  • Integrity fixes for startup and estimated times of SchedulerJob.
  • Remove logs for astronomical twilight.
  • Fix for decimale display in altitude constraint log.
  • Rewrite findAltitude to duplicate code.
  • Rewrite calculateAltitudeTime.
  • Make getDarkSkyScore const on Scheduler.
  • Rewrite calculateCulmination to duplicate code.
  • Make getWeatherScore const on Scheduler.
  • Rewrite score calculations to duplicate code.
  • Rewrite planning algorithm.
  • Rewrote algorithm documentation.
  • Fixes from Phabricator comments.
  • Remove warning for infinite loop, and convert some logs in imaging duration.
  • Refresh imaging duration after sequencing when job has repeats or loops.
  • Add invariants for imaging time estimation, and fix some issues regarding duration.
  • Fix rising/setting determination, hours are already considering LST and are in [0,24[ !!
  • Add altitude and lead time columns to job table.
  • Fixed unused minimum altitude to -90 instead of -1.
  • Added lead time from a previous job to scheduler job.
  • fixup! Fix rising/setting determination, hours are already considering LST and are in [0,24[ !!
  • fixup! Add altitude and lead time columns to job table.
  • Change the job sorting predicate to consider rise/set, introduce manual sort and reset count when re-evaluating manually.

Differential changes are now complete.
Please start testing now while I write the changeset documentation and describe integration tests!

  • Fix rising/setting determination, hours are already considering LST and are in [0,24[ !!
  • Add altitude and lead time columns to job table.
  • Fixed unused minimum altitude to -90 instead of -1.
  • Added lead time from a previous job to scheduler job.
  • Change the job sorting predicate to consider rise/set, introduce manual sort and reset count when re-evaluating manually.
  • Adjust lead and imaging time cell rendering and tooltip.
  • Optimize altitude calculation when rendering cells and sorting.
TallFurryMan retitled this revision from [WIP] Rewrite of Scheduler planning to Rewrite of Scheduler planning.Nov 10 2018, 4:11 PM
TallFurryMan edited the summary of this revision. (Show Details)
TallFurryMan edited the summary of this revision. (Show Details)Nov 12 2018, 7:29 AM
TallFurryMan edited the summary of this revision. (Show Details)Nov 17 2018, 2:07 PM
TallFurryMan edited the test plan for this revision. (Show Details)
TallFurryMan edited the test plan for this revision. (Show Details)
TallFurryMan edited the summary of this revision. (Show Details)Nov 17 2018, 2:09 PM
TallFurryMan edited the summary of this revision. (Show Details)Nov 17 2018, 2:33 PM
TallFurryMan edited the test plan for this revision. (Show Details)
TallFurryMan edited the summary of this revision. (Show Details)Nov 18 2018, 9:10 AM
TallFurryMan edited the test plan for this revision. (Show Details)
TallFurryMan added a comment.EditedNov 20 2018, 6:39 AM

Issue found: when changing the start-up constraint from asap to culmination time, and there are two jobs in the list, the second job is overwritten with the first job contents.
Investigation in progress to determine the root cause.

wreissenberger requested changes to this revision.Nov 21 2018, 3:11 PM

With the option "Sort Jobs per Altitude and Priority" enabled, re-sorting in the edit mode leads to a wrong selection in the queue table.

Test case:

  • Create a schedule with two jobs, where the two jobs have different priorities. Edit the job with the higher priority and change it to a value that its new priority is lower than that of the other job.
  • As a result, the schedule is automatically reordered.
  • Nevertheless, the selection in the queue table remains at the same position.
This revision now requires changes to proceed.Nov 21 2018, 3:11 PM

With the option "Sort Jobs per Altitude and Priority" enabled, re-sorting in the edit mode leads to a wrong selection in the queue table.

Test case:

  • Create a schedule with two jobs, where the two jobs have different priorities. Edit the job with the higher priority and change it to a value that its new priority is lower than that of the other job.
  • As a result, the schedule is automatically reordered.
  • Nevertheless, the selection in the queue table remains at the same position.

Thanks. Originally I didn't plan to resolve the selection and highlight issues because the differential is quite big already. I settled for a "known bug" entry, do you think I should continue fixing in the current context?

That said, I also reported a problem with a two-job list, so perhaps I can have a look.

I think I found the problem with the selection bug. The function reorderJobs() seems to be buggy and it does not look like a new bug.

@TallFurryMan: What do you prefer: shall I simply post here the patch or is it better when we fix this in a separate diff?

Go ahead and post, I can integrate it to this differential.

Issue Found: When a job finishes its sequence after repeating, Scheduler re-evaluates the plan before starting the next job. However, the next job doesn't start immediately even if it scheduled to start asap. There is a delay that is added, possibly equal to the last job single-repeat duration.

Enhancement Planned: Jobs which exceed their completion time are marked "Invalid", they should be marked "Complete" instead, as Scheduler is done with them.

Unrelated Issue Reproduced: Alignment unsuccessful, keeping adding sync points without being able to make the mount move. The situation doesn't result in an alignment failure, it seems the failure count is reset when a solution is found, which doesn't help in this situation. I had "Reset Mount Model Before Each Job" set, so that situation either appears during a single alignment procedure, or the option is not entirely functional.

Unrelated Issue Reproduced: PHD2 lost connection with the camera for more than its configured timeout, and stopped guiding. Guide module did not detect the failure to attempt to recover, and Capture simply stayed in the guiding deviation loop. Scheduler wasn't informed of anything.

Unrelated Issue Reproduced: Upon meridian flip, PHD2 guiding was not properly aborted, and PHD2 detected that mount started slewing and aborted guiding by itself. This had the unexpected consequence of disconnecting the external guider on the Guide module side. When the external guider is disconnected, the Guide module is unable to reconnect by itself, and subsequent guiding requests are failing.

Unrelated Issue Reproduced: Guide module is unable to clear PHD2 calibration when "Always Reset Calibration" is set.

Unrelated Issue Reproduced: After meridian flip, option "Use Differential Slewing Instead Of Syncing" is unexpectedly moving the mount in the opposite direction it should slew.

Go ahead and post, I can integrate it to this differential.

et voilà...

@wreissenberger Thanks your patch! I observed that when sorting jobs per altitude manually and sorting is not expected to change the order, the selection moves up by itself one row at a time. I'll check this.

OK the index concept of currentRow and the index concept of selectRow are different. I will move to a custom QModelIndex as soon as possible.

TallFurryMan edited the test plan for this revision. (Show Details)

Complete list of changes. Job selection highlight is now under control.

  • Fix move still possible just after enabling sort.
  • Fix jobs not reset after move, refactor evaluation.
  • Optimize UI refresh with manual content update after cell assignment refactoring.
  • Refactor cell assignment when adding a new job or editing one.
  • Reorder jobs automatically when "Sort Jobs by Altitude and Priority" is enabled.
  • Add a few assertions.
  • Fix management of score value zero, which is acceptable for observation.
  • Rewrite dark sky score calculation to consider seconds at most when comparing times.
  • Rewrite altitude score calculation to not modify the job startup time, move logs to caller.
  • Fix altitude cutoff issue, rewrite calculateAltitudeTime.
  • Fix altitude cutoff issue, rewrite calculateAltitudeScore.
  • Fix stability of culmination search, rewrite calculateCulminationOffset.
  • Rewrite getDarkSkyScore to use an argument date.
  • Fix job reordering algorithm.
  • Fix reset and evaluation of jobs when they are moved in the list.
  • Rewrite Moon separation algorithm.
  • Rewrite total score consolidation.
  • Adjust weather score documentation.
  • Integrity fixes for startup and estimated times of SchedulerJob.
  • Remove logs for astronomical twilight.
  • Fix for decimale display in altitude constraint log.
  • Rewrite findAltitude to duplicate code.
  • Rewrite calculateAltitudeTime.
  • Make getDarkSkyScore const on Scheduler.
  • Rewrite calculateCulmination to duplicate code.
  • Make getWeatherScore const on Scheduler.
  • Rewrite score calculations to duplicate code.
  • Rewrite planning algorithm.
  • Rewrote algorithm documentation.
  • Fixes from Phabricator comments.
  • Remove warning for infinite loop, and convert some logs in imaging duration.
  • Refresh imaging duration after sequencing when job has repeats or loops.
  • Add invariants for imaging time estimation, and fix some issues regarding duration.
  • Fix rising/setting determination, hours are already considering LST and are in [0,24[ !!
  • Add altitude and lead time columns to job table.
  • Fixed unused minimum altitude to -90 instead of -1.
  • Added lead time from a previous job to scheduler job.
  • Change the job sorting predicate to consider rise/set, introduce manual sort and reset count when re-evaluating manually.
  • Adjust lead and imaging time cell rendering and tooltip.
  • Optimize altitude calculation when rendering cells and sorting.
  • Fix job reordering and row selection (from Wolfgang).
  • Rewrite pre-evaluation of jobs.
  • Fix lead time tooltip.
TallFurryMan edited the summary of this revision. (Show Details)Dec 2 2018, 2:35 AM
TallFurryMan added a reviewer: lancaster.
TallFurryMan edited the test plan for this revision. (Show Details)Dec 3 2018, 7:24 AM

Scheduler is always marked as "Idle" below the jobs table.

Tested tonight. Scheduler executes script, unparks dome, ..etc. then goes to sleep because first job is not ready yet. The startup sequence should not be initiated up until the first job is ready (or leadtime-minutes before it)

  • Fix regression on current job status.
  • Minor grammar typo.
mutlaqja accepted this revision.Dec 7 2018, 8:40 AM
This revision was not accepted when it landed; it landed in state Needs Review.Dec 7 2018, 8:41 AM
This revision was automatically updated to reflect the committed changes.