Developer's notes for SPR 756 Marnix Bindels, July 13 2006 The insertion of a slew into rev n+1 when altering rev n's pEntry is thought to be a sensible check and it should remain. The code inserting this slew from pExit to the first pointing seems sound: it removes the orignal slew first, then tries the to build and insert a new slew. The actions that lead to the occurence of SPR 756's Event Clash are outside operational use: when scheduling a complete revolution, unscheduling it and then scheduling it again without generating files does not give proper results. Erik and Celia always use a fresh scheduling session for each try. A reason for this procedure not ginving proper results is the following. Scheduling of non fixed time obs is goverened by per revolution time pointers (RevolutionSchedule.oTime and SchedulingSession.theSchedulingPointers[]). The observations scheduled by scheduleForward, are scheduled at a time after the oTime pointer, which upon success is increased. However, when unscheduling this pointer is not reset to the beginning of the revolution. Hence, scheduling again will be starting at the latest successful time of the previous, unscheduled attempt. Two excellent observations above, how does this explain the occurence of 756? They do not! The problem could not be recreated, so I have no clue. With appropriate orbit data installed, scheduling 424 with 03xx109/0061 fixedtime and 0320092/0003 first time around yields a full schedule. Unscheduling and rescheduling only schedules 0061 and cannot do 0003 because in cannot find an obs window for eTime 6 april 2006 06:58:.. (1st time around eTime is 3 April 2006, 16:49:53). The logging at the time of the orignal error is: DEBUG 23-03-2006 16:09:59 nl.esa.estec.isoc.oss.db.SchedulingDataModule getPointing: Returning cached pointing Pointing0425000400010006 DEBUG 23-03-2006 16:09:59 esa.isoc.util.properties.Settings getBool: Getting boolean: logEvent ERROR 23-03-2006 16:09:59 nl.esa.estec.isoc.oss.scheduling.schedules.EventList logError: The event list at time of error is The event list has the following: Slew: start: Sat Apr 08 00:51:09 GMT 2006 end: Sat Apr 08 00:54:18 GMT 2006 type: 1 closed: false accel: 57.0 rateM: 150.0 from: Pointing: start: Thu Apr 06 14:31:49 GMT 2006 end: Thu Apr 06 14:36:08 GMT 2006 RA: 261.6032083 Dec: - 30.1016111 Roll: 0.078344 to: Pointing: start: Sat Apr 08 00:54:23 GMT 2006 end: Sat Apr 08 01:05:42 GMT 2006 RA: 265.8858333 Dec: -34.1278056 Roll: 0.078711 Pointing: start: Sat Apr 08 00:54:23 GMT 2006 end: Sat Apr 08 01:05:42 GMT 2006 RA: 265.8858333 Dec: -34.1278056 Roll: 0.078711 ERROR 23-03-2006 16:10:00 nl.esa.estec.isoc.oss.db.SchedulingDataModule getRevolutionSchedule: Events Clash @ 425,4,2,3; error as not found S lew: start: Sat Apr 08 01:05:37 GMT 2006 end: Sat Apr 08 01:07:07 GMT 2006 type: 1 closed: true accel: 43.5 rateM: 90.0 from: Pointing: start: Sat Apr 08 00:54:23 GMT 2006 end: Sat Apr 08 01:05:42 GMT 2006 RA: 265.8858333 Dec: - 34.1278056 Roll: 0.078711 to: Pointing: start: Sun Apr 09 09:55:23 GMT 2006 end: Sun Apr 09 09:55:24 GMT 2006 RA: 265.8858333 Dec: -34.1278056 Roll: 0.078711 DEBUG 23-03-2006 16:10:15 esa.isoc.util.properties.Settings getBool: Getting boolean: logEvent Note that the Event Clash occurs in getRevolutionSchedule(). Perhaps the error does not happen not while scheduling, but in the progress monitoring thread instead? If so, it could be considered a nuissance but not critical. Especially as one needs to use the system beyond standard operating procedures to get it. (I am giving up for now)