The astronomer's interface with Herschel was an observation planning program called HSpot, or HerschelSpot. HSpot allows the astronomer to define targets and observations, to calculate the time required and likely s/n and to submit a proposal with the requested observations, as well as offering many other useful functionalities to plot observations on the sky, see how they were executed, check an observing field against images and catalogues at various ranges and to look for other observations taken of the target. At any stage of this process the work in progress can be saved and recovered later.
HSpot has many useful funcionalities for exploring how observations were carried out and overlaying catalogues over images, or AORs, or explorimng sky coverage in a region of sky, among many other possibilities. This gives it a a big legacy value. in post-Operations HSpot is only maintained on a minimal, best-efforts basis, but the HSpot 7.0 version of the program will our legacy version.
HSpot has been adapted from the original Spitzer Space Observatory SPOT program and thus will be familiar to Spitzer users. The part of HSpot directly adapted from SPOT is known as the "Spot Core" of the program and is maintained by IPAC (about 80%), while the HSC has maintained the layer of Herschel-specific functionality (about 20%); HSpot incorporates a total of more than 30 man-years of work between the two centres.
HSpot can be downloaded from the Herschel Science Centre web page at the url:
Alternatively, select the "Tools" option from the left hand menu of the Herschel Science Centre web page and "HSpot download" in the tools page.
HSpot is eminently user-friendly, simple to use and has many functionalities that are of interest even to non-infrared astronomers. New users can generally familiarise themselves with the main functions in an hour or so of simply playing with the program.
HSpot has been updated regularly during Operations. For the OT2 Guaranteed Time Call in 2011, a completely new and revised version was released (HSpot 5.3), including literally dozens of minor and major updates since the previous Open Time Call and also numerous updates to the underlying Spot Core. Version 6.0 was then released for the OT2 Open Time Call; this version was updated for Phase 2 of OT2 as HSpot 6.1 and was further updated during 2012 as HSpot 6.2. A final operational release of HSpot 6.3 was made for the final few months of observing. The final release of HSpot that is planned is the 7.0 version, in autumn 2013, for which the only actual changes are a change in the underlying software version on which HSpot is built and an update in the On-Line documentation for post-Operations.
A planned update of the installation software to allow HSpot to install successfully on Windows 8 computers has had to be deferred, although Windows 8 is not anyway, at this time, a supported operating System. It is possible that a Windows 8 fix, which will also address installer issues with Mac Mountain Lion, will be implemented to coincide with the HCSS 12 release planned for March 2014, with a new HSpot release, built on HCSS 12, being made at this time.
Occasionally, unexpected issues came to light, requiring a new update of HSpot between major releases, in which case a new release was made. Not all releases were public releases for the astronomical community; many contained only expert user updates of interest to HSC staff and calibration scientists at the ICCs, hence the jumps in numbering of versions that users may have noticed between user releases. These incremental changes were included in the regular user releases, although they were not visible to the majority of users. The default setting in HSpot is that it will download these updates automatically and offer them to users when a new user release is detected. It was strongly recommended to users not to change this option, as it could have led to submitting or revising their AORs against a wrong HSpot version, or to having incorrect time estimates for them due to using an outdated time estimator (in extreme cases it could have even led to a proposal being rejected automatically by the Proposal Handling servers at HSC).
Each time that you open HSpot, it will connect to the HSC server and check to see if a new version is available. If one is found, you will be offered a choice of closing HSpot immediately and re-opening it with the new version, of waiting to install the new version, or of refusing the update (in which case automatic updates are disabled in the future). You are strongly advised to accept the update immediately; normally it will be installed and operational in under a minute. It is still possible that, even after the HSpot 7.0 release, small updates will be needed very occasionally to maintain critical funcionality.
Similarly, occasionally a new time estimator version may have been announced on opening HSpot; the time estimator links the AORs to the latest instrument control software that set the parameters for each observation. Normally, by the second half of the mission, time estimator changes did not affect the duration of observations, but it did effect essential parameters in the set-up of observations. When the time estimator version was updated, the time estimate for your previously prepared AORs would be shown in red; it was essential to submit all proposals against the latest time estimator version - to do this, it was only necessary to re-run time estimation before submission so that all the time estimates were shown in black font. When loading old AORs from disk their time estimation may be seen as out of date.
Executed AORs downloaded from the HSC will show the time estimate resulting from the time estimator version that the AOR was executed with, which may be a particularly old version; on occasion you may find that this causes significant changes in time estimates when these AORs are updated with the final time estimator: when a proposal was updated and re-submitted, the system ignored all changes to AORs that had already been scheduled, including timing changes, hence on downloading an updated proposal, observations executed with a previous time estimator version would show, correctly, as out of date. This means that all AORs in the database are effectively frozen with the configuration that they had at execution, meaning that they can be retrieved and examined to see how they were executed by the observatory.
In post-Operations there is no need to submit and modify proposals and HSpot will only be used for legacy purposes. The legacy version of HSpot is 7.0 and includes a raft of final, small updates. It is not expected that there will be a further release (although a minor new release may be made in Spring 2014 to build HSpot 7 on the new HCSS 12 software, see Section 22.214.171.124), but it cannot be discounted that some small changes may be required to keep HSpot operating in the future.
The biggest potential difficulty for HSpot is future changes in operating systems and in Java creating incompatibilities. Plans are in place to virtualise HSpot so that it will remain operational even under future operating systems and Java versions.
HSpot has been developed to run on the three main operating systems currently in use: Unix/Linux, Windows and Mac. The development work was carried out on Solaris and ported to these operating systems and the system has been extensively tested and used operationally by many hundreds of users for some seven years. We thus know that HSpot should run reliably on all the principal operating systems available to users. For each operating system certain common platforms are supported. Users are strongly urged to use these standard combinations of operating system and platform, as no guarantee can be offered that HSpot will run correctly on other combinations and no guarantee can be made of support for other platforms; occasional serious issues have been reported with other platforms, particularly for Linux users due to the wide variety of platforms available for Linux (it is physically impossible to test or to support all possible Linux platforms), with new platforms appearing late in the mission that occasionally had serious compatibility issues. Similarly, users will understand that, for example, the Windows version of HSpot has been extensively tested on Windows XP, Vista and Windows 7, but was developed with Windows XP.
Detailed information on the operating systems and platforms supported can be found in the HSpot manual. HSpot runs under Java and users are strongly advised to ensure that all updates and patches of their operating system are installed.
HSpot will only run on Java 1.6 and its later updates. Older Mac machines that do not support a Dual Core and 64-bit architecture will not install HSpot as they cannot run Java 1.6. Due to the way that Mac handles Java, Mac users have occasionally experienced minor problems with HSpot that Windows, Solaris and Linux users have not.
As there is already a Java 1.7 release, some issues may arise when trying to use HSpot on a computer with Java 1.7 installed. On Windows and Linux HSpot is packaged with the appropriate Java 1.6 release, so HSpot should run correctly. Java is *not* packaged with HSpot for Mac and uses the Java version packaged with the operating system. Once Mac launches its successor for Mountain Lion, it will no longer be possible to have Java 1.6 installed on a Mac and thus, no guarantees can be made that HSpot will still run on Mac.
HSpot is tested on all Windows releases up to Windows 7. We know that Windows 6.3.2 -- the final Operations release -- will not install on Windows 8 machines. The reason is that the version of the InstallAnywhere software used to install HSpot with which this release was built was not Windows 8 compatible. Technically, the jre (Java Runtime Environment) will not install correctly with this version of InstallAnywhere. Although a newer version of InstallAnywhere is available, other issues have been found with it so, for the time being we are unable to support Windows 8. Other solutions are being investigated actively for these issues.
We are aware that the InstallAnwhere software will not work with Mac Mountain Lion and that the supplier has withdrawn support for this OS. As new platforms and operating systems become available such issues may be become more commonplace. Again, we are working actively on finding a more permanent solution.
Proposal presentation has been extremely simple with HSpot. Once the observations to be carried out were defined and saved, the proposal could be submitted quickly and easily from the "Tools" menu. A submitted proposal could be retrieved before the deadline for submission and revised as many times as required; this allowed users to submit a draft and then update it continuously so that, even in case of disaster (a local hard disk failure, the Internet falling over just before the submission deadline, etc), HSC always had a valid latest version of the proposal. Similarly, a ToO/DDT proposal could be revised as many times as necessary before the Project Scientist subjected it to evaluation when informed that the definitive version was available for this evaluation process.
Similarly, accepted proposals are public documents that may be retrieved and examined by any registered user. The original intention behind this was to allow new users of Herschel to be able to study successful proposals and their AORs to be able to prepare a more competitive and technically better proposal in the Open Time Calls. However, it has been found that it is often very useful to be able to look at a proposal to understand the AOR design, samples, s/n calculations, etc. also when studying data in the archive.
AORs and abstracts can be retrieved via the "View Accepted Proposal" option in the "File" menu of HSpot. The core of the proposal (i.e. the scientific justification) can though only be seen by the P.I. of a proposal and his or her designated co-Users.
To submit a proposal, apart from the AORs (that is, the source information, instrumental configuration, exposure time, etc. for each object to be observed) the proposer needed a text file with the proposal abstract (maximum 2000 characters, including spaces), which could be read in directly, a PDF file of the scientific justification (limited to a maximum of 5Mbt and prepared with the latest version of the HerschelFORM PDFLatex package that is available on the Herschel Science Centre webpage) and to give basic information such as the proposal title, list of co-Is and the observing call that the proposal is responding to.
When a proposal was submitted, HSpot would confirm that it had been transmitted correctly and, on completion of processing, an e-mail was received from the HSC Proposal Handling System confirming its successful receipt. The time taken to generate and transmit the acknowledgement e-mail was a strong function of the system load. When the HSC servers were heavily loaded close to a call closure, the acknowledgement e-mail could take tens of minutes or even, in extreme cases, a few hours to arrive. Until this e-mail was received, users were not able to retrieve and update the latest version of their proposal. All proposals that arrived were logged with the time of submission and the HSC knew that a proposal was in the system, even if the formal acknowledgement had not been received. Once formal Calls for Proposals ended, the load on the system was normally extremely low and a proposal would be acknowledged rapidly. However, proposals with large numbers of HIFI observations, especially Spectral Scans, were much slower to process than PACS or SPIRE photometry proposals and could still take some minutes to be processed and acknowledged.
The database is now frozen and cannot be changed by users save for minor details of adding co-users for data access (this only makes sense for proprietary data so, from November 2013, there will be no need to make such changes any longer and this capability will be removed as it makes no further sense to have it), or to allow them download complete proposals. Proposals, logically, can no longer be submitted or updated, but they and their AORs can still be retrieved and examined with HSpot. Retrieving and examining the AORs from a proposal may be useful to understand how data retrieved from the archive was obtained.