getCal is a product of the Michelson Science Center.
getCal is an interferometric observation planning software suite. Its tools can be used to resolve common star names into standard catalog designations and astrometry; extract visibility calibrators from the Hipparcos catalog according to a variety of geometric, brightness, and astrophysical criteria; compute target zenith and delay accessibility; interface with the Simbad astronomical database, the PTI and KI sequencer GUIs, visibility calibration codes, and sky visualization software.
getCal also has other uses, is portable among UNIX varieties, can be autonomously driven over a list of sources, and can be accessed either from either the Unix command line or a (Perl/Tk) GUI.
More abstractly, getCal is an information synthesis tool; it aims to pull together the information needed to efficiently plan and analyze interferometric observations, and to present that information to you in a format you can easily integrate and comprehend.
To the user, getCal appears as an integrated application available from both the command line and GUI that:
An online version of getCal is available on the web, allowing the interested user to avoid the effort of installing this software. The gcWeb tool can be accessed at http://mscweb.ipac.caltech.edu/gcWeb . Or, see the Michelson Science Center software page at http://msc.caltech.edu/software.
Here we're going to give a few illustrative screenshots to whet your appetite and introduce you to a few of the more popular use cases for getCal suite.
Here is the basic user interface window produced by gcGui:
Here's the standard output window that displays the getCal results. The getCal invocation line is coded in blue, the GUI-consumable object designations are coded in red (getCal Format), and everything else is comments intended for your consumption. The "Simbad Browser" button allows you to spawn a Simbad query on the returned objects in an external web browser (see below).
Attached to the "Save Photometry" button in the top-level GUI is the ability to view, save, and edit the photometric data getCal retrieves from Simbad and 2Mass, and to iteratively process your edits through fbol.
Here's an example of the target/calibrator accessibility/timing calculations for 20 December 2002 computed with timing, and displayed with the timing GUI tool tGui.
Here we're actually displaying a whole night's observing schedule for Santa, but if invoked from getCal (gcGui) only the selected target gets displayed. The current UT/LST/local time indicators (vertical red line and text boxes) update in real-time (in case you're at the telescope); lighter red lines indicate target cluster transitions; and the bottom time axis labels toggle between off, LST (default), local time, and UT. Sunrise and sunset times are rendered (blue); timings are calculated by the timing component, and arbitrary sun twilight angles (e.g. 12 deg nautical (default), 18 deg astronomical) can be selected. Moon illumination and sky presence are indicated at the bottom of the graph. tGui renders timings for multiple baselines in multiple notebook pages accessible with tabs, and for multiple baseline observations a "Composite" page has the intersection of accessibility for all baselines. tGui also provides external-browser Simbad query support on the input target list (see below). There is also support for command-line options and batch-mode hardcopy (PostScript, pdf, jpeg, png) creation. Please see the tGui documentation for details.
Along these same lines, getCal components obsCalendar and ocGui respectively compute and display the annual accessibility of astronomical targets. Like the other timing/display components these function can be accessed either within or external to getCal proper.
Here's an example of the u-v track display tool uvTool for HD 187642 on 1 August 2006. The optional concentric circles indicate fringe spacings at various spatial frequencies (in case like me you can't do the conversion between Mlambda and mas in your head). The current UT/LST/HA markers (red arrows) and text update in real-time, as do the current time, hour angle, airmass...(you get the point). uvTool also provides external-browser Simbad query support (see below). Also new in uvTool is support for command-line options and batch-mode hardcopy (PostScript, pdf, jpeg, png) creaton. Please see the uvTool documentation for details.
Finally, here's an example of using the fbol module to fit a single component Plank black-body uniform stellar disk model to the Simbad-extracted broad-band photometry:
While we have done our best to simplify the installation procedures here, getCal can take some amount of effort to build and install. As an alternative, MSC provides a web-based version of getCal, cleverly named gcWeb, accessible online at http://mscweb.ipac.caltech.edu/gcWeb. The web tool provides most of the functionality of the getCal package without requiring the installation of this software.
The following table summarizes the dependencies of getCal, plus other software that is useful alongside it.
Note: Previous releases of getCal used the "lynx" utility as a tool for accessing web services such as Simbad. As of getCal-2.8, lynx is no longer required by getCal.
To build getCal, you will need a working *NIX (UNIX or Linux) system with the following items installed. Note that the list order reflects the packages' order of installation.
The starred items above are optional in varying degrees, so you may be able to get along without them. Please refer to the detailed notes below.
Several of these items may have been installed by the system administrator. If you are in doubt, the build scripts for getCal will examine the system and alert you if anything is missing.
A C++ compiler – for fbol. You almost certainly already have this, but in case you don't, gcc is a popular choice.
Perl 5.6.1 or higher is required. Almost all of getCal is in Perl, so there's no getting around it. Fortunately Perl is pretty pervasive these days, so this package may come bundled with your system. This dependency/version requirement is checked during the configuration step.
The Tk package is required if you want to use any of the GUI tools (gcGui, ocGui, tGui, uvTool) in the getCal suite. Thus it is highly recommended that you install Tk prior to building getCal.
The Tk toolkit is often installed by UNIX system administrators. Before installing it yourself, look for library file libtk.so and header tk.h.
A default Perl installation includes many useful modules. However, thousands more modules have been written and are publicly available. The Perl community has addressed the issue of distributing such modules by creating the Comprehensive Perl Archive Network (CPAN) Web site, http://www.cpan.org. getCal requires some of these add-on modules. If they are not already installed on your system, they must be installed before building getCal.
A handy utility module CPAN.pm exists to simplify the retrieval and installation of these modules. Once installed at your site, the CPAN module takes care of retrieving and installing other modules from CPAN. It allows you to sidestep the syndrome known as “dependency hell” because it is able to determine inter-module dependencies, find modules already installed on your system, and to transparently install all prerequisites for the modules that you really want. The instructions below use the CPAN module to assist with installing other needed modules.
An important decision to be made before continuing is whether modules will be installed in the site's Perl module repository, or in some private repository (e.g. under your home directory). Instructions are provided below for both types of installations.
Installing modules in the site repository will allow other users will be able to access the modules you install. However, depending on how Perl is installed on your system, root access may be necessary to install modules in the site repository. If you do not have root access or write permission to update the site repository you will probably not be able to use this option.
On the other hand, installing modules in a private repository may make cleanup easier should you have trouble with the installation and wish to start fresh, but requires a few extra steps to specify where modules should be installed, and to setup your environment to search for modules in that location.
The following sections describe the procedure for each of these alternatives. If you wish to install modules as a root user in the site repository, follow the steps in the next section. Otherwise, skip ahead to the following section.
Some networks have firewalls or gateways that block regular FTP traffic and require the use of "passive" FTP. If you are on such a network, or you find that the module installation procedure below seems to stall at the point of retrieving modules from the Internet, it may be helpful for you to set environment variable FTP_PASSIVE to a value of 1.
$ perl -MCPAN -e shell
If you find yourself looking at a cpan> prompt, CPAN.pm is
already installed and you can skip the next step.
gunzip -c CPAN-1.76.tar.gz | tar -xv
cd CPAN-1.76
perl Makefile.PL
make
make install
$ perl -MCPAN -e shell
The very first time you do this after installing CPAN.pm, you will be prompted on whether you want to perform a manual configuration of CPAN. You can generally answer no to this question and let the module work out its own initial settings. If it works, you'll save yourself a long Q&A session.
cpan> install LWP::UserAgent
You may be prompted that CPAN has found additional dependencies for the requested module, and given an option to prepend those dependencies to the build list. You should answer yes to this question.
From there on, the process is fairly automatic: CPAN should build, test and install all the required modules. Watch the output for error messages; it should be clear whether or not a module installed correctly.
Sometimes, the dependency processing doesn't work out cleanly and an installation will fail with a message saying that something wasn't found, even though the dependency was just installed. If an installation step fails, trying it a second time sometimes works.
If a module still fails to install correctly, you may need to use the `force' keyword–e.g.:
cpan> force install LWP::UserAgent
You need to use common sense with this option, though, since it won't do you any good to install a module that truly doesn't work.
cpan> install Time::CTime
cpan> install HTML::TreeBuilder
cpan> install HTML::FormatText
This item is somewhat optional, just like the Tk library. (The Tk module allows Perl programs to utilize the Tk library, which is written in C.) This module is highly recommended.
Before you install the Tk module, please be aware that the module's unit tests require an X server (DISPLAY should be defined in the environment). The build script may report errors if you attempt to install Tk via a console-only session.
cpan> install Tk
mkdir $HOME/perl
mkdir $HOME/perl/lib
Some networks have firewalls or gateways that block regular FTP traffic and require the use of "passive" FTP. If you are on such a network, or you find that the module installation procedure below seems to stall at the point of retrieving modules from the Internet, it may be helpful for you to set environment variable FTP_PASSIVE to a value of 1.
$ perl -MCPAN -e shell
If you find yourself looking at a cpan> prompt, CPAN.pm is
already installed and you can skip the next step.
gunzip -c CPAN-1.76.tar.gz | tar -xv
cd CPAN-1.76
perl Makefile.PL -- PREFIX=$HOME/perl LIB=$HOME/perl/lib
make
make install
$ perl -MCPAN -e shell
The very first time you do this after installing CPAN.pm, you will be prompted on whether you want to perform a manual configuration of CPAN. You can generally answer no to this question and let the module work out its own initial settings. If it works, you'll save yourself a long Q&A session.
cpan> o conf makepl_arg "PREFIX=~/perl LIB=~/perl/lib"
cpan> o conf commit
cpan> install LWP::UserAgent
You may be prompted that CPAN has found additional dependencies for the requested module, and given an option to prepend those dependencies to the build list. You should answer yes to this question.
From there on, the process is fairly automatic: CPAN should build, test and install all the required modules. Watch the output for error messages; it should be clear whether or not a module installed correctly.
Sometimes, the dependency processing doesn't work out cleanly and an installation will fail with a message saying that something wasn't found, even though the dependency was just installed. If an installation step fails, trying it a second time sometimes works.
If a module still fails to install correctly, you may need to use the `force' keyword–e.g.:
cpan> force install LWP::UserAgent
You need to use common sense with this option, though, since it won't do you any good to install a module that truly doesn't work.
cpan> install Time::CTime
cpan> install HTML::TreeBuilder
cpan> install HTML::FormatText
This item is somewhat optional, just like the Tk library. (The Tk module allows Perl programs to utilize the Tk library, which is written in C.) This module is highly recommended.
Before you install the Tk module, please be aware that the module's unit tests require an X server (DISPLAY should be defined in the environment). The build script may report errors if you attempt to install Tk via a console-only session.
cpan> install Tk
You need to have the Hipparcos catalog installed to perform the basic functionality of selecting calibrators and extracting astrometry. We did this quite intentionally – minimal planning functionality at the telescope must not be compromised even if the network connection is unavailable.
Hipparcos was an ESA space astrometry mission from the late 1980's and 1990's which surveyed roughly 120,000 stars brighter than V ~ 10 (exact magnitude limits are a function of galactic coordinates).
If you don't have the Hipparcos catalog already, you can find zipped copies of the main catalog and annexes at ftp://cdsarc.u-strasbg.fr/pub/cats/I/239.
New in release 2.8, getCal includes a utility makeHipIdx that will generate a set of indexes for the Hipparcos catalog to speed lookups. getCal will use the indexes, if present, to quickly locate records within the catalog instead of searching the entire catalog. Use of these indexes is optional, getCal will still work if they are not available.
If available getCal will scan the Hipparcos informational annexes, specifically concerning multiplicity and variability. getCal will still operate without access to the annexes, but if you're choosing visibility calibrators you really do want that additional information. If you don't have the annexes but would like them you can follow the URL link given above for the full catalog.
In particular, getCal uses the following annexes when available:
You should place the annexes into the same directory as the main Hipparcos catalog files, identified by runtime parameter GC_HIPPARCOS_PATH.
The Catalog of Infrared Observations. CIO is a valuable source of IR radiometric data. You can find the online information concerning CIOv5.1 (including instructions on how to get your very own copy) at http://ircatalog.gsfc.nasa.gov/.
tGui, ocGui, and uvTool use the Ghostscript translator ps2pdf to make PDF output. See http://www.cs.wisc.edu/~ghost/.
fbol can make spectrophotometry plots using gnuplot, but of course only if you have it. Most environments already have gnuplot installed, but in case yours doesn't, you can find it at http://www.gnuplot.info/. Note that some installations of gnuplot may not support the "png" terminal type. If your gnuplot does not support png, you will be unable to save fbol plots in the png format, but other formats (ps, eps) should still work.
tGui, ocGui, and uvTool use utilities from the netpbm package (namely pstopnm, pnmflip, ppmtogif, ppmtojpg, and pnmtopng) to generate GIF, JPEG, and PNG output. Please see http://netpbm.sourceforge.net/.
getCal can optionally drive the popular XEphem software for sky visualizations. XEphem can be found at the URL http://www.clearskyinstitute.com/xephem/xephem.html, and is worth the investment of your time to download if you don't already use it...
Building and installing getCal from a distribution tarball (i.e. getCal-*.tar.gz) looks something like this:
gunzip -c getCal-2.10.6.tar.gz | tar -xv
cd getCal-2.10.6
setenv GC_HIPPARCOS_PATH {path to Hipparcos catalog files}
./configure --prefix={installation prefix directory}
make
make index (optional)
make check
make install
The process in detail:
By default, configure looks for the Hipparcos catalog under $(prefix)/data/catalogs/hipparcos, so if your Hipparcos files have that position relative to your installation prefix, you don't need to set GC_HIPPARCOS_PATH explicitly, even while building.
One thing to consider in this step is where you will want getCal to be installed. If you have root access, you might want getCal to go under /usr/local (the default location) or another system-wide directory such as /opt. Otherwise, you'll probably prefer to have it go inside a personal directory such as ~/software.
The configure script takes a --prefix=[some path] argument. Use this to specify your installation prefix path.
If configure fails, it should print a descriptive message stating the problem. Generally, it fails because of some unsatisfied dependency; the point is to alert you to any problems as soon as possible.
Distribution tarballs should always contain a configure script. If you are not building from a tarball or otherwise do not find a configure script, the autoreconf utility will generate a new one. This should not be necessary when building from a distribution tarball. In the top level directory, run
autoreconf
If you do not have autoreconf available, you can instead try something like:
aclocal
automake
autoconf
Then, run the configure script and continue.
This is a fairly quick process but a lot of messages will scroll by. Take note of any error or warning messages.
If your system has the recommended DB_File Perl module, this optional step will run the makeHipIdx utility to create the Hipparcos catalog index files which getCal uses to speed Hipparcos lookups. You don't need to do this step if usable index files already exist.
This optional step runs getCal's unit tests. This step requires several minutes to run, but is a good idea since it exercises your build of getCal. If it passes these tests, getCal should work correctly after installation.
Note: There is also an option make check-long, which runs a more extensive series of tests. This option is intended primarily for the maintainers of the source code. If you are interested only in validating the build of getCal, make check is the command to use.
If you are installing to a system-wide directory such as /usr/local, you will need to perform this step as the root user.
For your reference, getCal-2.10.6 has been successfully built and tested on the following platforms/configurations:
getCal has a number of configuration parameters which can be changed by the user. These are documented below.
Prior to version 2.8, getCal required each user to set the run-time configuration through environment variables. Starting with 2.8, environment variables can still be used, but they are no longer required. Instead, getCal now uses a configuration file for most user-configurable values, and uses environment variables to override settings from the config file when desired. Additionally, getCal can use an alternate user-specified configuration file, minimizing the need for numerous environment variables to be set at runtime.
The sources for runtime-configurable values used by getCal are (in order of increasing precedence):
The gcConf utility lists all configuration parameters in force, and the source (env var, config file, etc) for each value. Use gcConf to resolve any confusion about what configuration parameters are in effect, and their origins.
The getCal suite of programs use the following parameters, configurable via getCal.conf or environment variables:
| Parameter | Description | Default
|
| GC_CONFIG | Location of getCal configuration file. | $(prefix)/etc/getCal.conf
|
| GC_CIO_CATALOG_PATH | directory containing CIO catalog files | $(prefix)/data/catalogs/CIO5.1/ciov5.1
|
| GC_BROWSER | Browser executable to use when running interactive Simbad queries. Can be any browser that accepts a URL on the command line. | `which mozilla` or `which netscape`
|
| GC_CAL_MINK | Min K mag constraint for calibrator stars | 2.0
|
| GC_CAL_MAXK | Max K mag constraint for calibrator stars | 5.0
|
| GC_CAL_MINV | Min V mag constraint for calibrator stars | 2.0
|
| GC_CAL_MAXV | Max V mag constraint for calibrator stars | 7.5
|
| GC_CAL_MINN | Min N mag constraint for calibrator stars | undefined
|
| GC_CAL_MAXN | Max N mag constraint for calibrator stars | undefined
|
| GC_CAL_MINL | Min L/L' mag constraint for calibrator stars | undefined
|
| GC_CAL_MAXL | Max L/L' mag constraint for calibrator stars | undefined
|
| GC_CAL_SEARCHRADIUS | Search radius constraint for calibrator stars. Units are degrees. | 10.0
|
| GC_2MASS_SEARCHRADIUS | Search radius for position matching done in 2MASS queries. Units are arcseconds. | 3
|
| GC_IRAS_SEARCHRADIUS | Search radius for position matching done in IRAS queries. Units are arcseconds. | 10
|
| GC_CIO_CATALOG_PATH | directory containing CIO catalog files | $(prefix)/data/catalogs/CIO5.1/ciov5.1
|
| GC_DEFAULT_BASELINE | Interferometer baseline, depends on location. See interferometers.pm. | all
|
| GC_DEFAULT_BIASOFFSET | Default delay bias offset (LDL), in meters. | 0.0
|
| GC_DEFAULT_FORMAT | Output format for getCal. Allowed values: new|old|sky. | new
|
| GC_DEFAULT_INTERFEROMETER | See interferometers.pm | all
|
| GC_DEFAULT_LOCATION | Default observing location. Allowed values are:
| Palomar
|
| GC_DEFAULT_TIMEOFFSET | Sets the graphic zero point for tGui. Should be a time offset in the form `hh:mm'. | 00:00
|
| GC_FIRSTPASS_K | If 2MASS Kmag was requested (option --K2Mass), model Kmag must be within this value (in mag) if the indicated Kmag min/max limits before getCal will actually query 2MASS. This reduces the overhead of performing unnecessary 2MASS lookups for stars where the model Kmag is far outside the desired min/max limits. | 0.5
|
| GC_FIRSTPASS_N | If IRAS-based Nmag was requested (option --NIRAS), model Nmag must be within this value (in mag) if the indicated Nmag min/max limits before getCal will actually query IRAS. This reduces the overhead of performing unnecessary IRAS lookups for stars where the model Nmag is far outside the desired min/max limits. | 0.5
|
| GC_HIPPARCOS_PATH | directory containing Hipparcos catalog (e.g., hip_main.dat) and annex files | $(prefix)/data/catalogs/hipparcos
|
| GC_HIPPARCOS_IDX_PATH | directory to place the Hipparcos catalog index files, created by makeHipIdx and used by getCal to speed catalog searches. | $(prefix)/data/getCal
|
| GC_HTTP_TIMEOUT | Seconds to wait before declaring a timeout on HTTP transactions. Should be a positive integer, or 0 for infinite. | 30
|
| GC_IDENT_HDC | Boolean value (0 or 1) to toggle the substitution of `HDC' in place of `HD' in object identifiers output by getCal. The `HDC' prefix is a convention used by PTI, but is otherwise nonstandard usage, so this should be only be used when preparing observing schedules for PTI. Use of `HDC' was the default behavior for getCal releases prior to 2.8. | 1
|
| GC_IRSA_HOST | IRSA web server | irsa.ipac.caltech.edu
|
| GC_NULLDEPTH_TRGDIAM | Default target angular size (mas) to use for null depth estimates | 1.5
|
| GC_NULLDEPTH_WAVELENGTH | Default Wavelength (um) to use for null depth estimates | 11.25
|
| GC_SIMBAD_HOST | Simbad web server | simbad.harvard.edu
|
| GC_SIMBAD_CACHEDIR | Directory for caching of Simbad queries, useful for testing against a known set of Simbad results. Also potentially useful for speeding repeated queries against the same set of objects, though may be dangerous if the cached results become stale, as no checking of the freshness of cached results is done. | None
|
| GC_SIMBAD_CACHEONLY | When set to 1, only previously cached Simbad results are used. If a query is not found in the cache, Simbad is NOT queried, and the query will fail. Useful for testing against a known set of Simbad results, and running getCal when Simbad is offline. | 0
|
| GC_TOLERANCE_K | A warning will be output if the difference between model and 2MASS Kmags exceeds this value. | 0.4
|
| GC_TOLERANCE_N | A warning will be output if the difference between model and IRAS Nmags exceeds this value. | 0.4
|
| GC_TWILIGHT_ANGLE | Default twilight angle limit (degrees below horizon) for sunrise/sunset calculations. | 12.0
|
| GC_XEPHEM_FIFO | Optional FIFO file that xeConvert should use for communicating with XEphem | None
|
| GC_ZENITH_ANGLE | Default zenith angle limit (degrees from zenith) for target accessibility calculations. | 35.0
|
| HTTP_PROXY | Use this parameter to route HTTP traffic (Simbad and IRSA) through an HTTP proxy server (e.g., `localhost:8080'). | None
|
getCal can be a fairly slow application. Some parts of it are CPU-intensive; some are I/O-bound; still others spend time waiting for replies from the SIMBAD or IRSA web servers. Here are some ways to improve getCal's performance.
getCal uses an appreciable amount of CPU time. If you have a choice of hosts on which to run it, you should opt for the faster CPU (e.g., choose Intel ahead of SPARC), and opt for an unloaded, single-user machine over a multi-user system.
getCal makes extensive use of the Hipparcos catalog; this catalog is stored as a set of files in the local filesystem. It is advisable that the Hipparcos catalog files be stored on a local disk if possible. The GC_HIPPARCOS_PATH parameter tells getCal where to find the catalog files.
New in release 2.8 is an indexing feature for the Hipparcos catalog. getCal includes a utility makeHipIdx that will create a set of index files to greatly speed Hipparcos catalog lookups by allowing getCal to consult the index instead of scanning the entire file. The GC_HIPPARCOS_IDX_PATH parameter tells getCal where to store and find these index files. If the indexes are not available, getCal will still work, but Hipparcos lookups (and the hipRecord command) will function more slowly.
In the process of acquiring up-to-date information about targets and calibrator stars, getCal issues web-based queries to SIMBAD and IRSA. The time taken performing those queries and waiting for responses can add up, especially when running repeated queries for the same sources.
The overhead of repeated web queries can be reduced by using a caching HTTP proxy server, and routing getCal's queries through that proxy. Depending on your level of interest in improving getCal query performance (and your thirst for adventure), you can also set up such a server on your own system. One such proxy server is Squid (http://www.squid-cache.org), some advice on installing Squid on linux is given below.
A version of Squid, along with a nice gui control panel for it, is available in pre-packaged form for MacOSX. See http://homepage.mac.com/adg/SquidMan/index.html. After installing the package, see the configuration information in the next section.
The remainder of this section provides a first-person account of how Squid was used to speed up getCal on one machine. It is not intended as a replacement for Squid's user manual, but rather as a complement to it.
Squid server configuration (root user):
438,439c438,439
< acl QUERY urlpath_regex cgi-bin \?
< no_cache deny QUERY
---
> #acl QUERY urlpath_regex cgi-bin \?
> #no_cache deny QUERY
3189c3195
< # strip_query_terms on
---
> strip_query_terms off
477c477
< # cache_mem 8 MB
---
> cache_mem 100 MB
527c527
< # maximum_object_size_in_memory 8 KB
---
> maximum_object_size_in_memory 512 KB
692c692
< # cache_dir ufs /var/cache/squid 100 16 256
---
> cache_dir ufs /var/cache/squid 500 16 256
1465c1465
< refresh_pattern . 0 20% 4320
---
> refresh_pattern . 4320 20% 10080 override-expire reload-into-ims
1871a1872,1877
> # Only allow access to domains that getCal uses
> acl getcal_usage dstdom_regex simbad.harvard.edu|simbad.u-strasbg.fr|irsa.ipac.caltech.edu
> http_access deny !getcal_usage
> # Only allow access to local machines
> acl ipac_clients src 192.168.1.0/24 192.168.2.0/24
> http_access allow ipac_clients
Client configuration (non-root user):
time make check
to establish a rough baseline of how long getCal takes to complete its test suite without using Squid. This took 8 minutes, 55 seconds.
time make check
again. This time, it completed in 3 minutes, 28 seconds.
grep TCP_ /var/log/squid/access.log
and observed that TCP_HIT appeared throughout the log's entries. TCP_MISS would have indicated that some pages were not cached. Since I had previously run getCal's test suite against Squid, all the required pages should have been–and were, in fact–already loaded in Squid's cache.
Note that the access log's location may vary by system; it is set in Squid's configuration file.
Command-line tools:
Catalog-lookup tools:
GUI's:
Other Utilities:
getCal is the “driver” application for most of the command-line tools in the getCal suite. Given a target, it selects calibrator stars; orchestrates the lookup of target and calibrator data in one or more catalogs; calculates various spectral, photometric and timing-related values of interest; and outputs these data in one of several formats.
getCal {target options} [other options]
--searchRA= --searchDec=
--targetName= | --targetHD= | --targetHIP= | --targetDM=
--cal= | --noCalibrators
--searchRadius= --effTemp --linearDiam --lClass=
--maxAD= --minK= --maxK= --minV= --maxV= --minN= --maxN= --minL= --maxL=
--useMeasurement
--K2Mass --NIRAS --Nband --Lband --Lprime
(Enabled by --fbol; implies --simbadInteractiveQuery):
[from fbol]
--constrainTemp
[from fbolFormat]
--2Mass --CIO --fLambda --fNu --geneva --gezari --hipparcos/--tycho
--longWL --noB --noPlx --noU --noV --stromgren/--uvby
SIMBAD Options (enable with --simbadInteractiveQuery):
--allData/--meas --browser --commonNames --coord --FK5 --HD= --HIP=
--SAO --html --identifiers/--pseudonyms --Kmag --lineWidth= --list --url
Timing Options (enable with --timing):
--airmass= --baseline= --biasOffset=/--LDL=/--offset= --day=
--delayLimit= --delayMax= --delayMin= --location= --month=
--noEcho --noPreamble --noPrecess --noTargets --precess --replace
--twilightAngle= --year= --za=/--zenithAngle=
--table --tableStep=
--nullDepth -NDstep --NDwavelength --trgAngDiam=
Observation Calendar Options (enable with --obsCalendar):
--hourAngle= --location= --noEcho --noPreamble --replace
--twilightAngle= --year=
--calScript
--format=new|old|sky --noInterspersed --photometry/--savePhotometry
--noMessages/--noWarnings/--quiet --verbose
--plx/--parallax --sigFigures=
--rename --identHDC/--noIdentHDC
--xEphemDisplay
--copyright --debug --help --longHelp --version
General comments: The use of command-line options in getCal adheres to the Unix standard, except that all the options have long (more than single-character) names. Technically this is referred to as the POSIX standard with GNU extensions. (Handling of options is by Perl's Getopt::Long module, and most of the positive attributes of our command-line processing is by virtue of that module.)
Options should be prefaced by double dashes. You may be able to get away with using single dashes or with abbreviating options, but you could run into trouble–e.g., --searchR could match either --searchRA or --searchRadius.
Options that require arguments should have an equal sign (--option=)as per the GNU convention, though --option val may also work.
--searchRA=331.75
--searchRA=22:07
--searchRA=22h7m00s
--searchRA=22_07_00
--searchDec=25.3333333333333
--searchDec=25d20m
--searchDec=25:20:00
--searchDec=+25_20
If you want to use spaces in the arguments, you may, as long as you quote the arguments using double quotes–e.g.:
--searchRA="22 07 00" --searchDec="25 20 00"
Note that using seconds is optional for both RA and Dec, but using minutes is not. Without a minutes argument the program will think you're trying to give it a decimal degrees (i.e. --searchRA=22 will be interpreted as 22.0 degrees), probably not what you had in mind.
When used, these options require a string argument.
(BTW, yes the DM option really works, it just works slowly. Try a --targetDM=B+24_4533 (iota Peg) and go get some lunch. Notice you need to replace the spaces in the DM designations by underlines.)
Note that this is the option of choice when your target doesn't have a HIP entry and you want to observe it anyway. getCal will do its best to compose an appropriate GUI line out of the Simbad coordinate return. The user should especially be on the lookout for missing proper motions...
--lClass=III IV V
will just get the giants, while
--lClass=III --lClass=IV --lClass=V
gets them all. When used, this option requires a string argument.
When used, these options require a numerical argument (mag). Defaults for these values can be controlled by Run-Time Configuration.
The calculation applies a IRAS color correction factor (based on object estimated effective temperature), per the method described in the IRAS PSC Explanatory Supplement, Sec VI. A passband correction factor is then applied to convert the corrected IRAS 12um flux into an estimated N-band (10micron) flux.
If no IRAS information is found for a source within the configured IRAS position search radius (see getCal config param GC_IRAS_SEARCHRADIUS), getCal will issue a warning message and revert to using a value calculated from an internal V-N model.
See also --Nband, which is implied when --NIRAS is used.
In the "new" output format, the N-band magnitude appears as an addtional tagged field on the output line (N=...). In the "old" output format, the N-band magnitude will be inserted between the B-V color index and the spectral type. See getCal Format. No argument when used.
The --fbol option directs getCal to compute apparent diameter estimates based on effective temperature and a bolometric flux model fit to available photometry. (Photometry sources are SIMBAD and 2MASS). Defaults to no.
--fbol sub-options delegated to fbol (see fbol Command-Line Options):
--fbol sub-options delegated to fbolFormat:
Enable the lookup of calibrator stars in SIMBAD with --simbadInteractiveQuery. By default this option prints out just the Simbad object classification (e.g. `iota peg Type: Spectroscopic Binary'), but this behavior is customizable through a number of additional options:
simbadInteractiveQuery --browser --list iota_Peg 51_Peg
simbadInteractiveQuery NGC_1068 --browser
--baseline=PTI_NS --baseline=PTI_NW
Default all provides timings for all supported baselines at selected location, and supercedes all other baseline arguments. Value of "none" computes no delay timings. May be invoked multiple times.
--obsCalendar directs getCal to compute observing calendar information for the composed program using obsCalendar. Depending on additional arguments (e.g. --year=) this option can determine calendar constraints for this year, or any other observation year. When used, this option does not take an argument.
Both obsCalendar and timing use the GC_DEFAULT_LOCATION and GC_DEFAULT_BASELINE runtime parameters to define defaults, and fall back to PTI and PTI_NS and PTI_NW baselines if they are not set. A discrete set of other locations and baselines can be used (see --location and --baseline below).
Sub-options enabled with --obsCalendar:
HDC4676 00 48 58.708 +16 56 26.318 -0.002 -0.202 5.1 3.7 0.50 SPECTYP=F8V... ROLE=TRG PID=? PLX=0.0418
The --format=sky option turns on the Keck observatory “sky” format, e.g.:
HDC4676 00 48 58.708 +16 56 26.318 2000 pmra=-0.002 pmdec=-0.202 vmag=5.1 3.7 F8V... 0.0 xxx xxx trg
The default value for this option is is new.
Please see getCal formats for more information on these formats.
The format of the "parallax-enhanced" "old-format" line looks like:
HDC120136 13 47 15.743 +17 27 24.862 -0.504 0.054 0.06412 4.5 3.2 F7V xxx xxx trg
that is, the parallax (64.12 mas for tau Boo) has been inserted between the dec PM and the V-magnitude. In the "new" output format, the parallax is tagged with "PLX=". See getCal Format.
Note this argument requires you to have xephem running separately, and configured to accept objects through the FIFO mechanism. Please consult the xeConvert on-line documentation.
In its most basic form, getCal resolves designations into standard catalog representations, and makes potential calibration source recommendations. This takes the command-line form:
getCal --targetName=iota_Peg
which results in:
### GUI catalog from getCal-2.8 ###
# Resolving target iota_peg via SIMBAD
# target HD 210027
HDC210027 22 07 00.666 +25 20 42.402 0.328 0.027 3.8 2.7 0.43 F5V 0.0 xxx xxx trg
# HIP 106897 (HD 206043) has his variability flag set (1)
# with 0.020 mag scatter in 166 observations
HDC206043 21 39 01.189 +20 15 55.623 0.131 -0.001 5.8 5.0 0.31 F2V 8.2 0.37+/-0.1 cal HDC210027
# HIP 107310 (HD 206826) has his multiple component flag set to C
# the C designation indicates solutions were found for individual components
# 2 components:
# A component -- V= 4.856
# B component -- V= 6.308 at sep 2.002 arcsec/PA 302 deg
HDC206826 21 44 08.578 +28 44 33.476 0.297 -0.243 4.5 3.3 0.51 F6V 6.1 0.67+/-0.4 cal HDC210027
HDC208527 21 56 23.984 +21 14 23.490 0.002 0.015 6.4 3.5 1.70 K5V 4.8 0.58+/-1.1 cal HDC210027
HDC210074 22 07 28.593 +19 28 31.893 0.129 0.037 5.7 4.9 0.33 F2V: 5.9 0.32+/-0.2 cal HDC210027
HDC210460 22 10 19.021 +19 36 58.821 0.098 -0.094 6.2 4.8 0.69 G0V 5.8 0.32+/-0.3 cal HDC210027
# HIP 110548 (HD 212395) has his multiple component flag set to C
# the C designation indicates solutions were found for individual components
# 2 components:
# A component -- V= 6.391
# B component -- V= 9.287 at sep 0.42 arcsec/PA 0 deg
HDC212395 22 23 39.565 +20 50 53.627 0.359 -0.015 6.2 4.9 0.52 F7V 5.9 0.36+/-0.1 cal HDC210027
The format of getCal's output is documented in getCal Format.
getCal supports a legacy “old” format, originally used by the Palomar Testbed Interferometer (PTI, http://msc.caltech.edu/palomar.html ) sequencer.
Here are a couple of sample lines:
# Simbad Search HD 210027: Type: Spectroscopic binary F5V V=3.76 * iot Peg * iot Peg A * 24 Peg
HDC210027 22 07 00.666 +25 20 42.402 0.328 0.027 3.8 2.7 0.43 F5V 0.0 xxx xxx trg
# Simbad Search HD 206043: Type: Variable Star of delta Sct type F2V V=5.783 V* NZ Peg
HDC206043 21 39 01.189 +20 15 55.623 0.131 -0.001 5.8 5.0 0.31 F2V 8.2 0.37+/-0.1 cal HDC210027
A description is given for each of these fields in the following table:
| Field | Item | Description
|
| 1 | Designation | Object Designation (string). No spaces are allowed.
|
| 2-4 | RA (J2000) | Object right ascension in hh mm ss.s format (J2000)
|
| 5-7 | Dec (J2000) | Object declination in +/-dd mm ss.s format (J2000)
|
| 8 | PMra | RA Proper motion (arcsec/yr)
|
| 9 | PMdec | Dec Proper motion (arcsec/yr)
|
| 10 | V | Object V magnitude (mag)
|
| 11 | K | Object K magnitude (mag)
|
| 12 | B-V | Object B-V color (mag)
|
| 13 | SpYtpe | Object spectral type descriptor (string)
|
| 14 | AngSep | Angular separation from target (zero for target) (deg)
|
| 15 | AngDiam | Estimated angular diameter (xxx for target) (mas)
|
| 16 | AngDiamErr | Estimated angular diameter error (xxx for target) (mas)
|
| 17 | trg/cal | Target/Calibrator designation (string)
|
There are several optional variants to this format:
Parallax
One variant on the getCal output format also includes the parallax in
arcsec, inserted between the PMdec and V fields:
# Simbad Search HD 210027: Type: Spectroscopic binary F5V V=3.76 * iot Peg * iot Peg A * 24 Peg
HDC210027 22 07 00.666 +25 20 42.402 0.328 0.027 0.085 3.8 2.7 0.43 F5V 0.0 xxx xxx trg
This variant is controlled by using the --parallax or --plx command-line option (see getCal Command-Line Options), or the parallax button (see gcGui controls).
N-band Photometry
Another available variant on the getCal output line is the inclusion of an N-band photometry estimate, inserted between the B-V color and spectral type fields:
# Simbad Search HD 4676: HD 4676 -- Spectroscopic binary F8V V=5.07 * 64 Psc
HDC4676 00 48 58.708 +16 56 26.318 -0.002 -0.202 5.1 3.7 0.50 3.7 F8V... 0.0 xxx xxx trg
This variant is controlled by using the --Nband and/or --IRAS command-line options (see getCal Command-Line Options), or the N-band and/or IRAS buttons (see gcGui controls).
Because of evolving getCal requirements and other new software, a "new" output format has been defined. As of version 2.8, this format is the default for getCal, and is currently used by the Keck Interferometer (KI, http://msc.caltech.edu/keck.html) sequencer.
This format looks like:
HDC4676 00 48 58.708 +16 56 26.318 -0.002 -0.202 5.1 3.7 0.50 SPECTYP=F8V... ROLE=TRG PID=? PLX=0.0418 N=3.8
HDC2454 00 28 20.052 +10 11 23.452 0.033 -0.203 6.0 4.8 0.45 SPECTYP=F6Vawvar ROLE=CAL DIAM=0.36 DIAMERR=0.120 CALFOR=HDC4676 PLX=0.02751 D=8.4 N=4.8
The first 12 fields (Designation through B-V) are identical to the normal "old" getCal format (without the parallax), and the rest of the fields are formatted as "TAG=value", as listed below. Some of these tagged fields are required and some are optional. (For now, the tagged fields will be in the order below as well, but this may change at any time!)
CALFOR tag gives the target name for which the source is a calibrator;
required for calibrators. Ex.:
CALFOR=HDC4676
D tag gives the distance from the target to the calibrator;
optional for calibrators. Ex.:
D=8.4
DIAM tag gives the angular diameter of the calibrator;
requir