IAU Minor Planet Center

MPC Status Page: Archive (2003 March-December)

Recent problems are listed elsewhere. Index of other older problems..

Older Enhancements and Resolved Problems

• Outgoing SMTP e-mail
  2003 Dec. 20: 17:45. We are having problems sending SMTP e-mail from one of our machines because of the Computation Facility's policy of blocking outgoing SMTP e-mail from all machines except those designated as SMTP servers. Currently, all but one of our machines are on an exceptions list to this SMTP blocking. The CF apparently expects us to comply with their new policy by Dec. 30. Basically, this means that they want us to designate a single machine in our cluster to handle all of our e-mail. We have pointed out that creating a new single point-of-failure is not a wise move. Discussions will presumably resume on Monday...

• References on MPECs
  2003 Dec. 20: 09:00. Astute readers of the MPECs will have noticed that a temporary reference is now being encoded on the observations that appear on the circulars. The reference is of the form "E"+half-month+circular number: e.g., 2003-Y14 would be encoded as EY014. Some users of the data included on the MPECs have in the past been remiss in referencing the source of observational material that they have subsequently reused. The explicit inclusion of the reference on the observations is a reminder that an appropriate reference must be given if the data are used elsewhere.
  • When the observations subsequently appear in the MPCs or MPSs, the temporary reference is replaced with a permanent reference.

• Unavailability of cfa-ftp
  2003 Dec. 11: 09:45. The Computation Facility has informed us that the anon-ftp server cfa-ftp.harvard.edu will be unavailable from 21:00-23:30 on Sunday, Dec. 14. The purpose of the downtime is to get the server up-to-date on operating system patches.

• Computer Upgrades
  2003 Dec. 9: 10:30. The MPC is embarking on a series of upgrades, system tunings and new installations for its computer network. The full implementation of the plans may take several months to complete (working in several discrete sessions). The work will reduce a number of bottle-necks in the MPC computer system, as well as tripling our computational capacity. It is not anticipated that there will be any serious disruption, but there may be brief periods where individual machines are unavailable (with the consequent loss of Web functionality if this is the webserver machine). We will try and keep you informed of pending outages.

• MPES
  2003 Dec. 4: 14:15. A user reported that trying to get comet details from a summary page didn't work. This has been fixed.
  • On a related matter, it seems the full range of comet elements (as documented in the PDF guide) is not currently available in the MPES. Specifically, only recent comets are accessible.
  • Dec. 4: 14:40: The documented range of comet elements should again be accessible.

• MPES
  2003 Nov. 28: 21:45. While performing some testing, a problem with ephemeris dates showed up. If you request an ephemeris at one-minute (or one-second) intervals, your requested start date should be rounded to an integral minute (or second). In practice, the date was rounded to an integral hour. This non-documentation-compliant behavior has been fixed.

• Acknowledgements
  2003 Nov. 28: 10:40. The SMTP server queues on a number of machines in the cluster shut down at some point overnight. The machine that sends the acknowledgements was one of those affected. The SMTP server queues have been restarted.
  • 11:40. All affected SMTP server queues have been restarted. The backlog of ACKs have been sent out.

• Residual Statistics
  2003 Nov. 24: 17:40. The preparation of the residual statistic pages was not completed properly after the last batch of MPCs were prepared. The residual blocks for the unnumbered objects were not examined due to a user's file overwriting a file needed by the command file that examined the blocks. The command file has been modified to minimize the chance of a similar conflict occurring in the future. The residual statistic files will be regenerated after the next MPC batch is prepared.

• Last night's DOU MPEC
  2003 Nov. 22: 08:40. Some previously-unusued code in the new DOU MPEC preparation program was triggered in last night's run. Unfortunately, an incorrect loop variable was specified in this previously-untested-in-combat block of code. The code failed and no MPEC was prepared. Last night's DOU MPEC has been abandoned. The code has now been fixed.

• Spam, spam, spam, eggs and spam
  2003 Nov. 14: 18:00. Due to the recent massive increase in incoming spam e-mail, we have been forced to install a spam filter. The spam filter is being triggered by e-mails that contain both a plain ASCII and an HTML version of the message. Observers submitting observation batches are urged in the strongest possible manner to disable the inclusion of the HTML copy. If you do so, your junk rating will improve!

• AUTOACK
  2003 Nov. 10: 11:30. Following a number of cases of incorrectly-specified headers in the MPCs caused by malformed observational headers, the requirements for AUTOACK to recognise an incoming e-mail as containing observations have been tightened. The observational header is required, the COD line must be the first line of the header and any otherwise-valid header lines that occur before the COD line will be ignored. Note that the formal definition of the observational header requires the COD line to come first, this change simply enforces this requirement.

• MPChecker
  2003 Nov. 8: 23:30. Following a user request, the MPChecker was enhanced to allow choice of total or separate motions.

• DOU MPECs
  2003 Nov. 6: 19:31. As noted on MPEC 2003-V27, the issuing of DOU MPECs has been suspended while the preparation routines are rewritten.
  • Nov. 7: 22:45. The necessary program and commmand file changes have been made. We intend to do a test run early tomorrow afternoon. If all works well, automatic issuance of the circulars will resume that night.
  • Nov. 8: 19:50. The manual issuance seems to be working okay. There were a number of minor problems detected that were easily fixed.
  • Nov. 9: 08:40. It seems that the DOU MPEC is not being mailed. Investigation is underway. Problem was found and fixed for future circulars.
  • Nov. 9: 08:45. One minor problem noted and corrected for future circulars. The new identifications and double designations were not referenced in our files following their appearance on MPEC 2003-V40, therefore they reappeared on MPEC 2003-V41.

• Last night's DOU MPEC
  2003 Nov. 4: 12:00. The referencing of unperturbed one-opposition orbits on last night's DOU MPEC failed, with the result that the orbits are not available in the MPES. Since MPC preparation is underway, a fix may be some time in coming,
  • Nov. 4: 14:15. The failure mentioned above is more properly described as a "failure to pick up all the unperturbed one-opposition orbits that needed publication".
  • Nov. 4: 14:15. An investigation indicates that part of the DOU MPEC preparation routine will need to be rewritten to better handle the differences between circular preparation during processing and MPC preparation periods and their overlap. This rewriting will happen after the Nov. MPCs are finished.

• (P)Recovery MPECs
  2003 Nov. 1: 13:00. A problem with special MPEC preparation yesterday caused two (p)recovery MPECs to not be issued. Although the observations appeared on last night's DOU MPEC the unusual circumstance of the problem means they will be reissued today.

• Incoming Email Processing System Upgrade IV
  2003 Oct. 31: 17:00. Because of the new way incoming messages are handled, the junk rating feature also needed modification. The junk rating value is now correct.

• Numbered Residual Blocks in MPES
  2003 Oct. 29: 14:00. A user reported that residual blocks for numbered minor planets were not available in the MPES. A quick check showed that the logical disk names on the web server had not been updated following the Oct. 14 hardware failure mentioned below. The logical disk names have now been updated.

• Magnitudes in MPES
  2003 Oct. 27: 18:00. Magnitudes are now suppressed if the computed magnitude is fainter than V = 35. This is to prevent silly magnitudes being displayed for objects that are showing very little (if any) of their sunlit side.

• Last night's DOU MPEC
  2003 Oct. 27: 10:00. Last night's DOU MPEC announced that it was the last MPEC to be issued prior to the preparation of the next batch of MPCs. This announcement is erroneous and should be ignored.

• Incoming Email Processing System Upgrade III
  2003 Oct. 25: 20:00. The recently introduced new e-mail processing system is more strict about requiring valid e-mail address in AC2 lines. The old system was more forgiving. The new system has now been tweaked to recognize patently invalid e-mail addresses and to inform user, via the acknowledgement message, when invalid entries occur. The junk rating feature has been reenabled, it being disabled when the new system was introduced.

• Last night's DOU MPEC
  2003 Oct. 23: 12:00. The new NEO observations failed to get put on last night's DOU MPEC. There was an error entry in the batch log file. It has been investigated and it has been determined that it was a transient problem. The missing observations will be on the next DOU MPEC.

• Incoming Email Processing System Upgrade II
  2003 Oct. 18: 11:30. The recent total rewrite of the incoming e-mail processing system is working nicely. The new system aims to cut down on the number of batches (a very small fraction of the received batches) that do not get processed properly. It has also enabled us to put in some features to ensure better communication between MPC and CBAT (remembering that MPC and CBAT are separate organizations with different responsibilities and reporting to different parts of the IAU): CBAT will now get automatic copies of batches identified by the AUTOACK system as containing NEOCP observations.

• Hardware failure
  2003 Oct. 14: 10:30. Another SCSI card has failed in one of our machines sometime last night. As a result this machine crashed and failed to reboot. We can continue to process incoming observations, but some pages (such as the date of last observation pages) cannot be updated until the problem is fixed.
  • 10:30. If you are seeing problems with the web services, this is probably the reason.
  • 10:30. Trying to get hold of an administrator to confirm that service contract was renewed on Oct. 1...
  • 11:30. Can't get hold of an administator. Service has been called.
  • 12:00. After speaking with service we have determined that the problem is not with the SCSI card, but with the system disk. Awaiting call to tell us when local service will be coming with replacement.
  • 13:30. Local service called to say a replacement part would not be available until tomorrow morning. Fortunately, the two user disks on the affected machine were in an external expansion box. We have attached this box to another machine. All user disks are again visible across the cluster.

• Column Headings in Earth-Orbiting Space Junk Tracker
  2003 Oct. 11: 10:30. The layout of the column headings in the output from the EOSJT script was fixed so that the headings were over the columns.

• Comet Magnitudes for Perturbed Orbits
  2003 Oct. 8: 10:30. A small bug in calculated magnitudes for comets with perturbed orbits that only showed itself under certain circumstances was located and fixed.

• Incoming Email Processing System Upgrade
  2003 Oct. 1: 16:30. At some point in the next 36 hours or so we will be bringing our new incoming-email processing system online. This is the system that extracts observation-bearing emails, acknowledges them and places them in the appropriate processing queues. This new code has received extensive off-line testing, but it needs to be tested "in combat" on-line. We will first disable the existing system and then, over the course of a few hours, run the new system manually at irregular intervals so that we can watch the process running to ascertain that it is operating correctly. Once we are satisfied with new code, we will let it loose to run automatically. Observers may experience a delay in getting acknowledgements until the new code is running automatically. We emphasize that there will be no change in the submission address for observation batches and, once the new system is operating fully, the acknowledgements will arrive in the same timely fashion as before. From the MPCs viewpoint, the processing of the extracted batches will be significantly simplified.
  • Oct. 3: 16:30. The new system was brought on-line in manual mode. A number of problems were identified and fixed. The first batch to be processed was a routine batch from NEAT. The first batch to go through the system without any problems was a batch of comet observations from code 785.
  • Oct. 3: 22:38. After watching a number of batches being run through the new system, it was submitted for automatic execution at 22:38. Logging of the batch job has been enabled and a check of these logs will be made tomorrow morning to see if any other problems have arisen.
  • Oct. 4: 11:00. An examination of the overnight logs of the new system showed one minor problem with the misfiling of one type of batch. This has now been fixed, logging has been disabled and the new system is now the default.

• DISCSTATUS
  2003 Sept. 22: 12:00. The new version of DISCSTATUS seems to be producing correct results. The monthly DISCSTATUS are currently been generated by a sponge-queue process.
  • DISCSTATUS reports have been mailed. Note that bouncebacks are listed on the E-Mail Woes page.
  • Note that references of the form "MPC xxxxx" will appear on the next DOU MPEC. They are appearing because of the lateness of the the DISCSTATUS preparation this month.

• Invalid Observatory Codes in MPES
  2003 Sept. 19: 15:00. A user reported that entering an observatory code of the form "lower case letter + two digits" produced a stack dump. Such values are not valid. The code has been tightened up to flag such values as invalid and then return geocentric ephemerides.

• CF Web Pages Big Move
  2003 Sept. 16: 09:00. The Computation Facility is moving all the web pages on its webserver onto a larger physical device. We cannot update our pages while this process is on-going (it is expected to take two or three hours) and users of the ECS may see anomalous behavior.
  • The move is complete, but the promised "transparency" has not materialized. One of the "update ECS" command files is barfing with an ftp rename command. The CF is looking into the problem.
  • This ftp rename problem is the reason the PS and PDF files in the ECS are not correct. This will be resolved as soon as possible.
  • 13:10. All ftp-rename related problems have been fixed.

• Dates of Last Observation of Comets
  2003 Sept. 15: 12:00. This page was not rebuilt correctly during the normal monthly update. It has been rebuilt.

• Delay in Posting Sept. 10 MPCs
  2003 Sept. 14: 17:00. The on-line ECS posting of the datafiles associated with the Sept. 10 batch of MPCs has been delayed. This decision was made after some apparent continuing network connectivity problems in the CfA network. It would be folly for us to undertake the posting procedure (which involves a lot of network traffic) if we have doubts about the integrity of the network. Hopefully, the files will be posted sometime tomorrow.
  • Sept. 15: 11:00. Posting of data in ECS has begun.

• Sept. 13 DOU MPEC
  2003 Sept. 13: 15:30. The Sept. 13 DOU MPEC procedure seems to have stalled (possibly as a result of the network connectivity problem mentioned below). We are trying to determine where it stalled, but cannot currently gain access to the .LOG file as the process refuses to be killed.
  • 17:00. Process was killed and remainder of DOU MPEC preparation routine was run.

• New Standard Epoch Elements in MPES
  2003 Sept. 12: 12:30. As a result of the way the MPC preparation works, there is a delay between the availability for unnumbered and numbered objects of 2003 Dec. 27 epoch elements (unnumbered elements being available first). This occurs every time that the standard epoch is changed. Normally, the delay will be a few hours. For the 2003 Sept. 10 batch of MPCs it will be almost one day, due to delays in various parts of the processing. We emphasize that the numbered elements that are being supplied are not "wrong".

• Network Connectivity Problems
  2003 Sept. 12: 12:10. The CfA network collapsed around 11:22 (apparently as the result of a failure of a key component and the subsequent failure of the backup device to return control to the restored primary device). As a result all of our computers lost their cluster connectivity. The cluster rebooted automatically when the CfA network was restored around 12:05. Normal operation has resumed.

• References on MPES orbits
  2003 Sept. 9: 10:00. We've just noticed a quirk in the way we handle orbits during the MPC preparation process. The orbits that have been published since the last MPCs that are available in the MPES have the reference given as "MPC xxxxx" (i.e., the MPEC references have been removed as part of the MPC preparation routine). The orbits in the MPCORB database retain the MPEC references.
  • There is no quick fix for this problem.
  • We will examine whether we need to remove the MPEC references and if this is found to be the case we will not remove the references in future months.
  • If you need the reference they can be found in the MPCORB database.
  • Once the MPC preparation is complete, normality will return.

• Web server
  2003 August 30: 16:00. The webserver machine SCULLY's sole remaining SCSI interface card is reporting controller errors. This will require a service call. Until this is fixed we are reverting to manual extraction and ACKing of incoming observation batches.
  • 17:15. Service has been called. We are waiting to hear from the local field office. SCULLY has been rebooted and is currently serving NEOCP ephemerides. The machine will obviously need to be taken off-line to fit the new interface card. We will probably not be able to give much advance warning of this. Sorry.
  • 20:15. Field service dude arrived 15 minutes ago. Interface card has been replaced. System booted as normal. Normality should be restored.

• Access to Telnet Computer Service
  2003 August 26: 15:00. A number of users have reported that they have been unable to make a connection to the telnet Computer Services. The two machines that run these services are up and running and they respond to telnet connections from observatory-internal machines. Problems have also been reported with access to the anon-ftp server and receipt of designation e-mails. This suggests that some change in the network configuration is preventing telnet connections from being made. We will try and investigate this with the networking group at the observatory.
  • Aug. 27: 15:00. The connectivity problems are being blamed on a recent router "upgrade" that means that default routes are no longer broadcast. We are configuring static routes on our machines.
  • The anon-ftp problems are related to a tightening of the rules regarding anon-ftp passwords. You must give a password that looks like a fully qualified e-mail address (e.g., username@fullyqualified.domain.name, although username@ is apparently allowed). But generic or default email addresses (such as mozilla@, guest@ and anonymous@) will not work. Warnings are returned by the anon-ftp servers if an invalid password is offered.
    • Note that you need to explicitly set your browser's anon-ftp password in order for the ftp links to work. The default values in browsers such as Mozilla and Netscape will NOT work.
  • We are informed that an e-mail blacklist used by popular spam filter software has put cfa.harvard.edu on their blacklist.
  • We believe these problems (with the exception of the e-mail blacklist) are now fixed. If you find otherwise, please send e-mail to the usual address.

• Normal service
  2003 August 18: 14:00. The procedures that failed over the previous two days as a result of the disk space problems on the CF webserver have been rerun. Normality has returned. If you find something still wonky with our site, please let us know (but please check that it is still a problem before reporting it).

• Mirror Pages
  2003 August 18: 11:00. We have set up an index page for the mirrored web pages, as it seems that many users did not know that we had mirror pages!

• CF Webserver disk space problems
  2003 August 18: 10:00. We have now talked to the CF. They have moved some of our web pages to an alternate (larger) disk. We will now rerun those procedures that failed. Some comments:
  • The VMS side of the operation worked flawlessly throughout this crisis.
  • The mirrored pages remained accessible, as did all the scripts served from the VMS webserver.

• CF Webserver disk space problems
  2003 August 17: 22:00. The CF webserver is now down to zero space. This means that, because of the behavior of Unix file systems, any file that is ftp'ed over to the webserver blanks out the existing file (rather than using a temporary file and a transparent rename). We would be examining the entire MPC website to see what can be deleted to clear space, except that the snapshot system means that any space freed up would be claimed by the snapshotted files! At time of writing, we (as an unprivileged user) still have no delete access to the snapshot directories. This is very frustating and requires that tonight's DOU MPEC be abandoned.
  • Attempts to delete files led to no space being freed. Total files deleted amounted to 1.6 GB. Disk usage remained at 100 percent with no free blocks!
  • There is no problem at the VMS end of the operation. All the grief is coming from the outside CF end.
  • Normal service will be restored as soon as possible on Monday morning.
  • We intend more pages to be mirrored on our VMS webserver. This work will proceed as time permits.

• CF Webserver disk space problems
  2003 August 17: 11:00. The CF webserver is still suffering from a lack of available disk space and this caused the update for the latest mid-month MPS batch to fail. The problem stems from the use of sixteen "snapshot" directories which allow access to accidentally-deleted files by giving access to copies of the source directory that were made at hourly/daily/ weekly intervals over the past 8 days or so. Snapshots are a wonderful idea that allow a user to recover a recently deleted file without bothering the Computation Facility, but the individual user has no delete access over the files in the snapshot directories (even though the files are shown as being owned by the user). There are currently many GB of "snapshotted" files (from just one directory) that we know can safely be deleted, but we don't have permission to do so!
  • The CF has suggested that our files be moved to another (larger) device. We are informed that this change will be transparent both to outside users and to our internal scripts that update our pages. We shall investigate this on Monday.
  • If space can be freed up today (it is dependent on a sysadmin being in the Computation Center), the files will be put up asap.

• MPEC 2003-Q01 associated data files
  2003 August 16: 15:00. The MPCUPDATE files associated with last night's DOU MPEC are incomplete due to the CF's webserver running out of disk space. We are fixing the problem by republishing all the orbits from Q01 on the next DOU MPEC. But unless the CF fixes its disk space problem, the problem will repeat. Of course, it is a weekend (see similarly badly timed problem below)...
  • We decided against republishing the Q01 orbits. We have fixed the affected datafiles and added the index page. The on-line MPEC (which was truncated due to the disk space problem) has been restored.
  • The amount of available disk space on the CF webserver has increased from 5 MB to 1.4 GB.

• UPS failure
  2003 August 15: 12:00. The UPS on one of our cluster machines failed last night. The affected machine is still receiving power but has no surge protection and so is now subject to the sometimes iffy power supply in Cambridge. Replacement batteries will be ordered on Monday (our Division Administrator is away this week). There is a slight risk that the machine will suffer a power loss before the batteries arrive. It is probable that the machine will rejoin the cluster without problem. But there is a slight chance that it will mess things up.

• DISCSTATUS
  2003 August 7: 12:00. The DISCSTATUS reports sent out last night should be ignored. The list of objects should be correct, but the orbital information may be incorrect. The program that generates the reports requires datafiles that were generated daily by the old MPES updating routines. These files are no longer updated. The program needs to be modified to use the new data structures. This will be done as soon as possible.

• Replacement of MPEPH3.COM
  2003 August 4: 17:10. When we upgraded the MPES, we omitted to update one web script. This meant that new elements (for both previously-designated and newly-designated objects) were not available through pre-generated pages such as the Dates of Last Observation of NEOs page. This anomaly has been corrected. Some work needs to be undertaken to make all the forms consistent, but the pages should again function.

• Modification to ACKing procedure
  2003 July 31: 15:43. The procedure that sends out the acknowledgements has been modified to include a "junk" rating (the percentage of the submitted message that does not consist of observations or observational/e-mail header material). Low "junk" ratings are good, high "junk" ratings are bad. Please pay attention to your ACK messages!

• Possible local network disruption
  2003 July 23: 19:18. We have been informed that the Computation Facility intends to upgrade its LAN routers on Saturday July 26 between 7:00 a.m. and 9:00 a.m. All traffic will be rerouted to the backup router. No interruptions are anticipated but there may be brief periods of instability.

• E-mail disruption
  2003 July 11: 09:36. We have been informed that the Computation Facility intends to replace the current cfa.harvard.edu computer at 7:45 a.m. on July 16. The downtime will be approximately 30-60 minutes. SMTP connections will fail during this period, but mail should queue up on the sending computer and they should be sent when the new machine is brought on-line.

• SCULLY downtime
  2003 July 10: 16:15. The troublesome fan on SCULLY is getting worse. We have called for service to replace the fan. The downtime will be as short as possible and will probably occur in the late morning of July 11.
  • The shutdown occurred at 10:55.
  • The system was restarted at 11:25.

• SCULLY downtime
  2003 July 8: 12:40. We had to take the webserver down at short notice to localize a worrying noise, fearing that a disk drive might be failing. It turns out that one of the fans is the problem.
  • Normal operation was restored at 12:50.

• Web Defacement Contest disruption?
  2003 July 6: 13:00. It appears that the recently-announced web defacement contest has started. Network traffic appears to be substantially impacted. The CF webserver appears not be responding, but the MPC mirror pages on SCULLY are active and responding (albeit slowly) to user requests.
  • 16:53. Internal access to the CF webserver has been restored.
  • 17:21. We are informed that the CF lost NIS earlier today and this affected CF-based web services. They have not given us the reasons for this loss of NIS.

• Accessing Comets with Minor-Planet Designations
  2003 July 4: 21:40. A user reported that requesting an ephemeris for 2003 KV2 returned a stack dump. This object was originally designated as a minor planet but is now P/2003 KV2. The options are to simply return a meaningful error message indicating that the minor planet designation has been deleted, indicate that the object is now comet such-and-such, or quietly change the minor-planet designation into a comet designation and continue.
  • Updated code was put on-line at 23:30 (it would have been earlier but the Boston fireworks needed watching...) that removes the stack-dump problem and transparently converts the designation into the appropriate cometary designation.

• No ephemeris returned
  2003 June 30: 14:49. A user reported that no ephemeris was returned when an small-interval ephemeris was requested for a MBA.
  • Updated code was put on-line at 16:50.

• Unexpected service outage
  2003 June 28: 13:31. The webserver removed itself from the cluster and did not reboot cleanly.
  • Normal service was restored at 15:20.

• MPES Documentation PDF file
  2003 June 18: 17:10. The on-line PDF documentation has been replaced with a much smaller file (the size has decreased from 8.5 MB to under 0.5 MB). This shrink was accomplished by converting the `deep sprite' images used in the document to `256-colour' images (RISC OS users will understand this!).

• Residual Blocks for Unperturbed Orbits
  2003 June 17: 17:00. Again, not a problem but an enhancement. Starting with last night's DOU MPEC, residual blocks for new 1-opposition unperturbed orbits will be available via the MPES.
  • June 17: 17:20. The available residual blocks have been back-extended to the June 14 DOU MPEC.
  • June 17: 17:23. The on-line documentation has been updated to reflect this change.

• Sometimes Incorrect Comet Magnitudes
  2003 June 17: 13:00. Under certain circumstances incorrect predicted magnitudes would be generated for comets. This has been fixed.

• Incorrect Vaisala elements
  2003 June 17: 12:00. There was confusion between the Vaisala elements of recently-observable and not-recently observed minor planets. E.g, you requested 2003 GV₃₇ and you got 1992 SK₂₁ (!). This has been fixed.

• Designations in the new MPES
  2003 June 13: 17:50. It has been reported that the provisional to permanent designation converter is not working for the objects newly numbered in the June MPCs. The necessary data *are* present in the relevant files. We are investigating...
  • June 13: 18:10. The problem wasn't with the designation conversion routines, but rather with the file of numbered minor planets elements. The file used by the MPES was generated by the old MPES routines and these have been disabled. The relevant bits of the old processing have been reactivated for the future and the file of numbered elements is being rebuilt now.
  • Corrected files were on-line by 18:35.

• Occasionally Incorrect Magnitudes in NOEG
  2003 May 30: 10:40. It appears that the New Object Ephemeris Generator can occasionally return incorrect magnitudes in the ephemeris.
  • The problem was tracked down to different orbits being used occasionally for calculation of the absolute magnitude and the calculation of the ephemeris. A corrected script was put on-line at 11:30.

• "File locked" in MPES
  2003 May 27: 11:15. This problem is now considered fixed. In reference to the May 15 remarks, the problem was not caused by the current version of the MPES code.

  2003 May 20: 14:00. We have received no reports of "Locked" errors since the previous posting on this subject. If there are no reports by the coming weekend, we will move this "Outstanding Problem" to the "Resolved Problem" section.

  2003 May 15: 11:20. During extensive testing on the new improved MPES code, we have yet to see a single "Locked" message. If users experience 'File locked' error messages after 15:20 UT on May 15, please send an email to gwilliams@cfa.harvard.edu.

  2003 May 14: 15:40. It was hoped that the removal of the dodgy interface card would fix this problem. And indeed, it looked as though it had. Alas, the problem persists.

  2003 April 7: 18:15. Our belief of March 20 that we knew which file is being locked has turned out to be erroneous (if it had been correct, there would not have been any more 'File locked' problems after March 27!). The investigation is continuing as time permits.

• MPU.ARC file in WebECS
  2003 Mar. 20: The file MPU.ARC in the MPCAT-OBS service does not have the observations of the newly-numbered objects removed.
  • A modified version was made available at 21:45. Note that the file sizes given on the MPCAT-OBS page are for the original version.

• Date of Last Observation pages not being updated
  2003 Mar. 20: The processes that update the Date of Last Observations pages were not restarted after the crash on Mar. 17. The updating of residuals blocks for the MPES was also affected.
  • Fixes for both problems were initiated at 18:15.

• Incorrect residual blocks for newly-numbered objects in MPES
  2003 Mar. 19, 14:00: More fallout from the failure of one of the cluster machines on Mar. 17. If you request the residual block for numbered object N, you actually get the residual block for object N+1. This is relatively trivial to fix.
  • The correct residual blocks were reinstated at 14:20.

• No new numberings in MPES
  2003 Mar. 19: The failure of one of the cluster machines on Mar. 17 had a broader effect than we first realised. Regeneration of a number of datafiles required by the MPES is on-going. All orbits published since MPC preparation began will need to be republished on the Mar. 20 DOU MPEC before the MPES is restored fully.
  • Access to the newly-numbered orbits was restored around 11:00.
  • Access to the other orbits mentioned above will be restored with the next DOU MPEC.

• No matches in MPChecker and SNChecker
  2003 Mar. 18: This problem is also due to the failure noted in the next section. Resolution of this problem will have to await the auto-correction that will come the issuance of the next DOU MPEC.
  • As expected, this problem was fixed with the issuance of the Mar. 19 DOU MPEC.

• No numbered orbits in MPES
  2003 Mar. 18: One of the computers in the cluster crashed last night and did not reboot cleanly. This affected the preparation of the DOU MPEC and associated files: the MPEC was not posted on the web (although it was e-mailed out); and the orbit files for use in the web services were not generated correctly, with orbits of many objects not being accessible (where orbits are available, the results are correct).
  • A fix for the first problem was put on-line at 12:45.
  • A fix for the second problem was put on-line at 19:12.