An AST Frame is an Object that is used to represent a coordinate system. Contrast this with a Mapping (§5), which is used to describe how to convert between coordinate systems. The two concepts are complementary and we will see how they work together in §13.
In this section we will discuss only basic Frames, which represent Cartesian coordinate systems. More specialised types of Frame (e.g. the SkyFrame, which represents celestial coordinate systems, and the SpecFrame, which represents spectral coordinate systems) are covered later (§8 and §9) and, naturally, inherit the properties and behaviour of the simple Frames discussed here.
The best way to think about a Frame is like the frame that you would plot around a graph. In two dimensions, you would have an “$x$” and a “$y$” axis, a title on the graph and labels on the axes, together with an indication of the physical units being plotted. The values marked along each axis would be formatted in a humanreadable way. The frame around a graph therefore defines a coordinate space within which you can locate points, draw lines, calculate distances, etc.
An AST Frame works in much the same way, embodying all of these concepts and a few more. It also allows any number of axes, which means that a Frame can represent coordinate systems with any number of dimensions. You specify how many when you create it.
Remember that the basic Frame we are considering here is completely general. It knows nothing of celestial coordinates, for example, and all its axes are equivalent. It can be adapted to describe any general purpose Cartesian coordinate system by setting its attributes, such as its Title and axis Labels, etc. to appropriate values.
Creating a Frame is straightforward and follows the usual pattern:
The first argument of the astFrame constructor function specifies the number of axes which the Frame should have.
We should briefly point out that the Frame we created above (§7.2) is also a Mapping (§5.1) and therefore inherits the properties and behaviour common to other Mappings.
One way to see this is to set the Frame’s Report attribute (inherited from the Mapping class) to a nonzero value and pass the Frame pointer to a coordinate transformation function, such as astTran2.
The resulting output might then look like this:
This is not very exciting because a Frame implements an identity transformation just like a UnitMap (§5.10). However, it illustrates that a Frame can be used as a Mapping and that its Nin and Nout attributes are both equal to the number of Frame axes.
When we consider more specialised Frames (e.g. §13), we will see that using them as Mappings can be very useful indeed.
Frames have a number of attributes which can take multiple values, one for each axis. These separate values are identified by appending the axis number in parentheses to the attribute name. For example, the Label(1) attribute is a character string containing the label which appears on the first axis.
Axis attributes are accessed in the same way as all other attributes (§4.5, §4.6 and §4.7). For example, the Label on the second axis might be obtained as follows:
Other attribute access functions (astSetX, astTest and astClear) may also be applied to axis attributes in the same way.
If the axis number is stored in a program variable, then its value must be formatted to generate a suitable attribute name before using this to access the attribute itself. For example, the following will print out the Label value for each axis of a Frame:
Note the use of the Naxes attribute to determine the number of Frame axes.
The output from this might look like the following:
In this case, the Frame’s default axis Labels have been revealed as rather unexciting. Normally, you would set much more useful values, typically when you create the Frame—perhaps something like:
Here, we have also set the (character string) Unit attribute for each axis to describe the physical units represented on that axis. All the attribute assignments have been combined into a single string, separated by commas.
We will now briefly outline the various attributes associated with a Frame (this is, of course, in addition to those inherited from the Mapping class). We will not delve too deeply into the details of each attribute, for which you should consult the appropriate description in Appendix C. Instead, we aim simply to sketch the range of facilities available:
There are also some further Frame attributes, not described above, which are important when Frames are used as templates to search for other Frames. Their use goes beyond the present discussion.
The coordinate values associated with each axis of a Frame are stored (e.g. within your program) as double values. The Frame class therefore provides a function, astFormat, to convert these values into formatted strings for display:
Here, the astFormat function is passed a Frame pointer, the number of an axis (“iaxis”) and a double precision value to format (“value”). It returns a pointer to character string containing the formatted value.
By default, the formatting applied will be determined by the Frame’s Digits attribute and will normally display results with seven digits of precision (corresponding approximately to the C “float” data type on many machines). Setting a different Digits value, however, allows you to adjust the precision as necessary to suit the accuracy of the coordinate data you are processing. If finer control is needed, it is also possible to set a Digits value for each individual axis by appending an axis number to the attribute name (e.g. “Digits(2)”). If this is done, it overrides the effect of the Frame’s main Digits value for that axis.
Even finer control is possible by setting the (character string) Format attribute for a Frame axis. The string given should contain a C format specifier which explicitly determines how the values on that axis should be formatted. This will override the effects of any Digits value^{12}. Any valid “printf” format specifier may be used so long as it consumes exactly one double value.
When setting Format values, remember that the “%” which appears in the format specifier may need to be doubled to “%%” if you are using a function (such as astSet) which interprets “printf” format specifiers itself.
It is recommended that you use astFormat whenever you display formatted coordinate values, even although you could format them yourself using “sprintf”. This is because it puts the Frame in control of formatting. When you start to handle more elaborate Frames (representing, say, celestial coordinates), you will need different formatting methods. This approach delivers them without any change to your software.
You should also consider regularly using the astNorm function, described below (§7.7), for any values that will be made visible to the user of your software.
The function astNorm is provided to cope with the fact that some coordinate systems do not extend indefinitely in all directions. Some may have boundaries, outside which coordinates are meaningless, while others wrap around on themselves, so that after a certain distance you return to the beginning again (coordinate systems based on circles and spheres, for instance). A basic Frame has no such complications, but other more specialised Frames (such as SkyFrames, representing the celestial sphere—§8) do.
The role played by astNorm is to normalise any arbitrary set of coordinates by converting them into a set which is “within bounds”, interpreted according to the particular Frame in question. For example, on the celestial sphere, a right ascension value of 24 hours or more can have a suitable multiple of 24 hours subtracted without affecting its meaning and astNorm would perform this task. Similarly, negative values of right ascension would have a multiple of 24 hours added, so that the result lies in the range zero to 24 hours. The coordinates in question are modified in place by astNorm, as follows:
If the coordinates supplied are initially OK, as they would always be with a basic Frame, then they are returned unchanged.
Because the main purpose of astNorm is to convert coordinates into the preferred range for human consumption, its use is almost always appropriate immediately before formatting coordinate values for display using astFormat (§7.6). Even if the Frame in question does not restrict the range of coordinates, so that astNorm does nothing, using it will allow you to process other more specialised Frames, where normalisation is important, without changing your software.
The process of converting a formatted coordinate value for a Frame axis, such as might be produced by astFormat (§7.6), back into a numerical (double) value ready for processing is performed by astUnformat. However, although this process is essentially the inverse of that performed by astFormat, there are a number of additional difficulties that must be addressed in practice.
The main use for astUnformat is in reading formatted coordinate values which have been entered by the user of a program, or read from a file. As such, we can rarely assume that the values are neatly formatted in the way that astFormat would produce. Instead, it is usually desirable to allow considerable flexibility in the form of input that can be accommodated, so as to permit “freeformat” data input by the user. In addition, we may need to extract individual coordinate values embedded in other textual data.
Underlying these requirements is the root difficulty that the textual format used to represent a coordinate value will depend on the class of Frame we are considering. For example, for a basic Frame, astUnformat may have to read a value like “1.25e6”, whereas for a more specialised Frame representing celestial coordinates it may have to handle a value like “07d 49m 13s”. Of course, the format might also depend on which axis is being considered.
Ideally, we would like to write software that can handle any kind of Frame. However, this makes it a little more difficult to analyse textual input data to extract individual coordinate values, since we cannot make assumptions about how the values are formatted. It would not be safe, for example, simply to assume that the values being read are separated by white space. This is not just because they might be separated by some other character, but also because celestial coordinate values might themselves contain spaces. In fact, to be completely safe, we cannot make any assumptions about how a formatted coordinate value is separated from the surrounding text, except that it should be separated in some way which is not ambiguous.
This is the very basic assumption upon which astUnformat works. It is invoked as follows:
It is supplied with a Frame pointer (“frame”), the number of an axis (“iaxis”) and a character string to be read (“string”). If it succeeds in reading a value, astUnformat returns the resulting coordinate to the address supplied via the final argument (“&value”). The returned function value indicates how many characters were read from the string in order to obtain this result.
The string is read as follows:
Note that failing to read a coordinate value does not constitute an error, at least so far as astUnformat is concerned. However, an error can occur if the sequence of characters read appears to have the correct form but cannot be converted into a valid coordinate value. Typically, this will be because it violates some constraint, such as a limit on the value of one of its fields. The resulting error message will give details.
For any given Frame axis, astUnformat does not necessarily always use the same algorithm for converting the sequence of characters it reads into a coordinate value. This is because some forms of input (particularly freeformat input) can be ambiguous and might be interpreted in several ways depending on the context. For example, the celestial longitude “12:34:56.7” could represent an angle in degrees or a right ascension in hours. To decide which to use, astUnformat may examine the Frame’s attributes and, in particular, the appropriate Format(axis) string which is used by astFormat when formatting coordinate values (§7.6). This is done in order that astFormat and astUnformat should complement each other—so that formatting a value and then unformatting it will yield the original value, subject to any rounding error.
To give a simple (but crucially incomplete!) example, consider reading a value for the axis of a basic Frame, as follows:
astUnformat will skip over the initial space in the string supplied and then examine each successive character. It will accept the sequence “1.5e6” as input, but reject the space which follows because it does not form part of the format of a floating point number. It will then convert the characters “1.5e6” into a coordinate value and skip over the three spaces which follow them. The returned function value will therefore be 9, equal to the total number of characters consumed. This result may be used to address the string during a subsequent read, so as to commence reading at the start of “99.0”.
Most importantly, however, note that if the user of a program mistakenly enters the string “ 1.5r6…” instead of “ 1.5e6…”, a coordinate value of 1.5 and a function result of 4 will be returned, because the “r” would prematurely terminate the attempt to read the value. Because this sort of mistake does not automatically result in an error but can produce incorrect results, it is vital to check the returned function value to ensure that the expected number of characters have been read.^{13} For example, if the string is expected to contain exactly one value, and nothing else, then the following would suffice:
If astUnformat does not detect an error itself, we check that it has read to the endofstring and consumed at least one character (which traps the case of a zerolength input string). If this reveals an error, the value of “n” indicates where it occurred.
Another common requirement is to obtain a position by reading a list of coordinates from a string which contains one value for each axis of a Frame. We assume that the values are separated in some unambiguous manner, perhaps using white space and/or some unspecified singlecharacter separator. The choice of separator is up to the data supplier, who must choose it so as not to conflict with the format of the coordinate values, but our software does not need to know what it is. The following is a template algorithm for reading data in this form:
In this case, “s” will point to the location of any input error.
Note that this algorithm is insensitive to the precise format of the data and will therefore work with any class of Frame and any reasonably unambiguous input data. For example, here is a range of suitable input data for a 3dimensional basic Frame:
Once a Frame has been created, it is not possible to change the number of axes it contains, but it is possible to change the order in which these axes occur. To do so, an integer permutation array is filled with the numbers of the axes so as to specify the new order, e.g.:
In this case, the axes of a 2dimensional Frame could be interchanged by passing this permutation array to the astPermAxes function. That is, an (${x}_{1},{x}_{2}$) coordinate system would be changed into an (${x}_{2},{x}_{1}$) coordinate system by:
If the axes are permuted more than once, the effects are cumulative. You are, of course, not restricted to Frames with only two axes.
An alternative to changing the number of Frame axes, which is not allowed, is to create a new Frame by selecting axes from an existing one. The method of doing this is very similar to the way astPermAxes is used (§7.9), in that we supply an integer array filled with the numbers of the axes we want, in their new order. In this case, however, the number of array elements need not equal the number of Frame axes.
For example, we could select axes 3 and 2 (in that order) from a 3dimensional Frame as follows:
This would return a pointer to a 2dimensional Frame (“frame2”) which contains the information associated with axes 3 and 2, in that order, from the original Frame (“frame1”). The original Frame is not altered by this process. Beware, however, that the axis information may still be shared by both Frames, so if you wish to alter either of them independently you may first need to use astCopy (§4.13) to make an independent copy.
In addition to the new Frame pointer, astPickAxes will also return a pointer to a new Mapping via its fourth argument (you may supply a NULL pointer as an argument if you do not want this Mapping). This Mapping will interrelate the two Frames. By this we mean that its forward transformation will convert coordinates originally in the coordinate system represented by “frame1” into that represented by “frame2”, while its inverse transformation will convert in the opposite direction. In this particular case, the Mapping would be a PermMap (§5.11) and would implement the following transformations:
This is our first introduction to the idea of interrelating pairs of Frames via a Mapping, but this will assume a central role later on.
Note that when using astPickAxes, it is also possible to request more axes than there were in the original Frame. This will involve selecting axes from the original Frame that do not exist. To do this, the corresponding axis number (in the “pick” array) should be set to zero and the effect is to introduce an additional new axis which is not derived from the original Frame. This axis will have default values for all its attributes. You will need to do this because astPickAxes does not allow you to select any of the original axes more than once.^{14}
Some complementary functions are provided for use with Frames to allow you to perform geometric operations without needing to know the nature of the coordinate system represented by the Frame.
Functions can be used to find the distance between two points, and to offset a specified distance along a line joining two points, etc. In essence, these define the metric of the coordinate space which the Frame represents. In the case of a basic Frame, this is a Cartesian metric.
The first of these functions, astDistance, returns a double distance value when supplied with the Frame coordinates of two points. For example:
This calculates the distance between the origin (0,0) and a point at position (1,1). In this case, the result, as you would expect, is $\surd 2$. However, this is only true for the Cartesian coordinate system which a basic Frame represents. In general, astDistance will calculate the geodesic distance between the two points, so that with a more specialised Frame (such as a SkyFrame, representing the celestial sphere) a greatcircle distance might be returned.
The astOffset function is really the inverse of astDistance. Given two points in a Frame, it calculates the coordinates of a third point which is offset a specified distance away from the first point along the geodesic joining it to the second one. For example:
This would fill the “point3” array with the coordinates of a point which is offset 0.5 units away from the origin (0,0) in the direction of the position (1,1). Again, this is a simple result in a Cartesian Frame, as varying the offset will trace out a straight line. On the celestial sphere, however (e.g. using a SkyFrame), it would trace out a great circle.
The functions astAxDistance and astAxOffset are similar to astDistance and astOffset, except that the curves which they use as “straight lines” are not geodesics, but curves parallel to a specified axis^{15}. One reason for using these functions is to deal with the cyclic ambiguity of longitude and latitude axes.
The astOffset2 function is similar to astOffset, but instead of using the geodesic which passes through two positions, it uses the geodesic which passes at a given position angle through the starting position.
Position angles are always measured from the positive direction of the second Frame axis to the required line, with positive angles being in the same sense as rotation from the positive direction of the second axis to the positive direction of the first Frame axis. This definition applies to all classes of Frame, including SkyFrame. The default ordering of axes in a SkyFrame makes the second axis equivalent to north, and so the definition of position angle given above corresponds to the normal astronomical usage, “from north, through east”. However, it should be remembered that it is possible to permute the axes of a SkyFrame (or indeed any Frame), so that north becomes axis 1. In this case, an AST “position angle” would be the angle “from east, through north”. Always take the axis ordering into account when deriving an astronomical position angle from an AST position angle.
Within a Cartesian coordinate system, the position angle of a geodesic (i.e. a straight line) is constant along its entire length, but this is not necessarily true of other coordinate systems. Within a spherical coordinate system, for instance, the position angle of a geodesic will vary along its length (except for the special cases of a meridian and the equator). In addition to returning the required offset position, the astOffset2 function returns the position angle of the geodesic at the offset position. This is useful if you want to trace out a path which involves turning through specified angles. For instance, tracing out a rectangle in which each side is a geodesic involves turning through 90 degrees at the corners. To do this, use astOffset2 to calculate the position of each corner, and then add (or subtract) 90 degrees from the position angle returned by astOffset2.
The astAngle function calculates the angle subtended by two points, at a third point. If used with a 2dimensional Frame the returned angle is signed to indicate the sense of rotation (clockwise or anticlockwise) in taking the “shortest route” from the first point to the second. If the Frame has more than 2 axes, the result is unsigned and is always in the range zero to $\pi $.
The astAxAngle function is similar to astAngle, but the “reference direction”, from which angles are measured, is a specified axis.
The astResolve function resolves a given displacement within a Frame into two components, parallel and perpendicular to a given reference direction.
The displacement is specified by two positions within the Frame; the starting and ending positions. The reference direction is defined by the geodesic curve passing through the starting position and a third specified position. The lengths of the two components are returned, together with the position on the reference geodesic which is closest to the third supplied point.
The Domain attribute is one of the most important properties of a Frame, although the concept it expresses can sometimes seem a little subtle. We will introduce it here, but its true value will probably not become apparent until later (§14.2).
To understand the need for the Domain attribute, consider using different Frames to represent the following different coordinate systems associated with a CCD image:
If we had two such CCD images, we might legitimately want to align them pixelforpixel (i.e. using the coordinate system based on pixel numbers) in order to, say, divide by a flatfield exposure. We might similarly consider aligning them using any of the other coordinate systems so as to achieve different results. For example, we might consider merging separate images from a CCD mosaic by using focal plane positions.
It would obviously not be legitimate, however, to directly compare positions in one image measured in pixels with positions in the other measured in mm, nor to equate chip positions in $\mu $m with sky coordinates in radians. If we wanted to intercompare these coordinates, we would need to do it indirectly, using other information based on the experimental setup. For instance, we might need to know the size of the pixels expressed in mm and the orientation of the CCD chip in the focal plane.
Note that it is not simply the difference in physical units which prevents certain coordinates from being directly intercompared (because the appropriate unit scaling factors could be included without any additional information). Neither is it the fact that different coordinate systems are in use (because we could legitimately intercompare two different celestial coordinate systems without any extra information). Instead, it is the different nature of the coordinate spaces to which these coordinate systems have been applied.
We normally express this by saying that the coordinate systems apply to different physical domains. Although we may establish ad hoc relationships between coordinates in different physical domains, they are not intrinsically related to each other and we need to supply extra information before we can convert coordinates between them.
In AST, the role of the (character string) Domain attribute is to assign Frames to their respective physical domains. The way it operates is as follows:
If the domain has several coordinate systems associated with it (e.g. the celestial sphere), then a coordinate conversion may be involved. Otherwise, coordinate values may simply be equated.
If any relationship does exist between such coordinate systems—and it need not—then additional information must be supplied in order to establish the relationship between them in any particular case. We will see later (§13) how to establish such relationships between Frames in different domains.
With the basic Frames we are considering here, each physical domain only has a single (Cartesian) coordinate system associated with it, so that if two such Frames have the same Domain value, their coordinate systems will be identical and may simply be equated. With more specialised Frames, however, more than one coordinate system may apply to each domain. In such cases, a coordinate conversion may need to be performed.
When a basic Frame is created, its Domain attribute defaults to an empty string. This means that all such Frames belong to the same (null) domain by default and therefore describe the same unspecified physical coordinate space. In order to assign a Frame to a different domain, you simply need to set its Domain value. This is normally most conveniently done when it is created, as follows:
Here, we have created two Frames in different physical domains. Although their coordinate values all have units of length, they cannot be directly intercompared (because their axes may be rotated with respect to each other, for instance).
All Domain values are automatically converted to upper case and white space is removed, but there are no other restrictions on the names you may use to label different physical domains. From a practical point of view, however, it is worth following a few conventions (§7.13).
When choosing a value for the Domain attribute of a Frame, it obviously makes sense to avoid generic names which might clash with those used for similar (but subtly different!) purposes by other programmers. If you are developing software for an instrument, for example, and want to identify an instrumental coordinate system, then it is sensible to add a distinguishing prefix. For instance, you might use $<$INST$>$_FOCAL_PLANE, where $<$INST$>$ (e.g. an acronym) identifies your instrument.
For some purposes, however, a standard choice of Domain name is desirable so that different items of software can communicate. For this purpose, the following Domain names are reserved by AST and the use recommended below should be carefully observed:
If data are copied or transformed to a new data grid (by whatever means), or a subset of the original grid is extracted, then the same rules apply to the copy or subset. Its first element therefore has GRID coordinate values of unity at its centre. Note that this means that GRID coordinates remain attached to the first element of the data grid and not to its data content (e.g. the features in an image).
Because the amount of shift is unspecified, the PIXEL domain is distinct from the GRID domain. The relationship between them contains a degree of uncertainty, such as typically arises from the different conventions used by different software systems. For instance, in some software the first pixel is regarded as being centred at (1,1), while in other software it is at (0.5,0.5). In addition, some software packages implement a “pixel origin” which allows pixel coordinates to start at an arbitrary value.
The GRID domain (which corresponds with the pixelnumbering convention used by FITS) is a special case of the PIXEL domain and avoids this uncertainty. In general, additional information is required in order to convert from one to the other.
Although we have drawn a necessary distinction here between the GRID and PIXEL domains, we will continue to refer in general terms to image “pixels” and “pixel coordinates” whenever this distinction is not important. This should not be taken to imply that the GRID convention for numbering pixels is excluded—in fact, it is usually to be preferred (at the level of data handling being discussed in this document) and we recommend it.
Each axis of a Frame has a Unit attribute which holds the physical units used to describe positions on the axis. The index of the axis to which the attribute refers should normally be placed in parentheses following the attribute name (“Unit(2)” for instance). However, if the Frame has only a single axis, then the axis index can be omitted.
In versions of AST prior to version 2.0, the Unit attribute was nothing more than a descriptive string intended purely for human readers—no part of the AST system used the Unit string for any purpose (other than inclusion in axis labels produced by the Plot class). In particular, no account was taken of the Unit attribute when finding the Mapping between two Frames. Thus if the conversion between a pair of 1dimensional Frames representing velocity was found (using astConvert ) the returned Mapping would always be a UnitMap, even if the Unit attributes of the two Frames were “km/h” and “m/s”. This behaviour is referred to below as a passive Unit attribute.
As of AST version 2.0, a facility exists which allows the Unit attribute to be active; that is, differences in the Unit attribute may be taken into account when finding the Mapping between two Frames. In order to minimise the risk of breaking older software, the default behaviour of simple Frames and SkyFrames is unchanged from previous versions (i.e. they have passive Unit attributes). However, the new functions astSetActiveUnit and astGetActiveUnit allow this default behaviour to be changed. The SpecFrame and TimeFrame classes always have an active Unit attribute (attempts to change this are ignored).
For instance, consider the above example of two 1dimensional Frames describing velocity. These Frames can be created as follows:
By default, these Frames have passive Unit attributes, and so an attempt to find a Mapping between them would ignore the difference in their Unit attributes and return a unit Mapping. To avoid this, we indicate that we want these Frames to have active Unit attributes, as follows:
If we then find the Mapping between them as follows:
the Mapping contained within the FrameSet returned by astConvert will be a onedimensional ZoomMap which simply scales its input (a velocity in $km/h$) by a factor of 0.278 to create its output (a velocity in $m/s$).
In fact we need not have set the Unit attribute active in “frame1” since the behaviour of astConvert is determined by its “to” Frame (the second Frame parameter).
Conversion between units systems relies on the use of a specific syntax for the Unit attribute. If the value of the Unit attribute does not conform to this syntax, then an error will be reported if an attempt is made to use it to determine an interunit Mapping (this will never happen if the Unit attribute is passive).
The adopted syntax is that described in FITSWCS paper I "Representation of World Coordinate in FITS" by Greisen & Calabretta. We distinguish here between “basic” units and “derived” units: derived units are defined in terms of other units (either derived or basic), whereas basic units have no such definitions. Derived units may be represented by their own symbol (e.g. “Jy”—the Jansky) or by a mathematical expression which combines other symbols and constants to form a definition of the unit (e.g. “km/s”—kilometres per second). Unit symbols may be prefixed by a string representing a standard multiple or submultiple.
In addition to the unit symbols listed in FITSWCS Paper I, any other arbitrary unit symbol may be used, with the proviso that it will not be possible to convert between Frames using such units. The exception to this is if both Frames refer to the same unknown unit string. For instance, an axis with unknown unit symbol "flop" could be converted to an axis with unit "Mflop" (Megaflop).
Unit symbols (optionally prefixed with a multiple or submultiple) can be combined together using a limited range of mathematical operators and functions, to produce new units. Such expressions may also contain parentheses and numerical constants (these may optionally use “scientific” notation including an “E” character to represent the power of 10).
The following tables list the symbols for the basic and derived units which may be included in a units string, the standard prefixes for multiples and submultiples, and the strings which may be used to represent mathematical operators and functions.
Basic units  
Quantity  Symbol  Full Name

length  m  metre 
mass  g  gram 
time  s  second 
plane angle  rad  radian 
solid angle  sr  steradian 
temperature  K  Kelvin 
electric current  A  Ampere 
amount of substance  mol  mole 
luminous intensity  cd  candela 
Quantity  Symbol  Full Name  Definition

area  barn  barn  1.0E28 m**2 
area  pix  pixel  
area  pixel  pixel  
electric capacitance  F  Farad  C/V 
electric charge  C  Coulomb  A s 
electric conductance  S  Siemens  A/V 
electric potential  V  Volt  J/C 
electric resistance  Ohm  Ohm  V/A 
energy  J  Joule  N m 
energy  Ry  Rydberg  13.605692 eV 
energy  eV  electronVolt  1.60217733E19 J 
energy  erg  erg  1.0E7 J 
events  count  count  
events  ct  count  
events  ph  photon  
events  photon  photon  
flux density  Jy  Jansky  1.0E26 W /m**2 /Hz 
flux density  R  Rayleigh  1.0E10/(4*PI) photon.m**2 /s/sr 
flux density  mag  magnitude  
force  N  Newton  kg m/s**2 
frequency  Hz  Hertz  1/s 
illuminance  lx  lux  lm/m**2 
inductance  H  Henry  Wb/A 
length  AU  astronomical unit  1.49598E11 m 
length  Angstrom  Angstrom  1.0E10 m 
length  lyr  light year  9.460730E15 m 
length  pc  parsec  3.0867E16 m 
length  solRad  solar radius  6.9599E8 m 
luminosity  solLum  solar luminosity  3.8268E26 W 
luminous flux  lm  lumen  cd sr 
magnetic field  G  Gauss  1.0E4 T 
magnetic flux  Wb  Weber  V s 
mass  solMass  solar mass  1.9891E30 kg 
mass  u  unified atomic mass unit  1.6605387E27 kg 
magnetic flux density  T  Tesla  Wb/m**2 
plane angle  arcmin  arcminute  1/60 deg 
plane angle  arcsec  arcsecond  1/3600 deg 
plane angle  mas  milliarcsecond  1/3600000 deg 
plane angle  deg  degree  pi/180 rad 
power  W  Watt  J/s 
pressure, stress  Pa  Pascal  N/m**2 
time  a  year  31557600 s 
time  d  day  86400 s 
time  h  hour  3600 s 
time  yr  year  31557600 s 
time  min  minute  60 s 
D  Debye  1.0E29/3 C.m  
Submultiple  Name  Prefix  Submultiple  Name  Prefix

$1{0}^{1}$  deci  d  $10$  deca  da 
$1{0}^{2}$  centi  c  $1{0}^{2}$  hecto  h 
$1{0}^{3}$  milli  m  $1{0}^{3}$  kilo  k 
$1{0}^{6}$  micro  u  $1{0}^{6}$  mega  M 
$1{0}^{9}$  nano  n  $1{0}^{9}$  giga  G 
$1{0}^{12}$  pico  p  $1{0}^{12}$  tera  T 
$1{0}^{15}$  femto  f  $1{0}^{15}$  peta  P 
$1{0}^{18}$  atto  a  $1{0}^{18}$  exa  E 
$1{0}^{21}$  zepto  z  $1{0}^{21}$  zetta  Z 
$1{0}^{24}$  yocto  y  $1{0}^{24}$  yotta  Y 
Mathematical operators & functions
 
String  Meaning

sym1 sym2  multiplication (a space) 
sym1*sym2  multiplication (an asterisk) 
sym1.sym2  multiplication (a dot) 
sym1/sym2  division 
sym1**y  exponentiation ($y$ must be a numerical constant) 
sym1^y  exponentiation ($y$ must be a numerical constant) 
log(sym1)  common logarithm 
ln(sym1)  natural logarithm 
exp(sym1)  exponential 
sqrt(sym1)  square root 
If an Axis has an active Unit attribute, changing its value (either by setting a new value or by clearing it so that the default value is reinstated) may cause the Label and Symbol attributes to be changed accordingly. For instance, if an Axis has Unit, Label and Symbol of “Hz”, “Frequency” and “nu”, then changing its Unit attribute to “log(Hz)” will cause AST to change its Label and Symbol to “log(Frequency)” and “Log(nu)”. These changes are only made if the Unit attribute is active, and a Mapping can be found from the old units to the new units. On the other hand, changing the Unit from “Hz” to “MHz” would not cause any change to the Label or Symbol attributes.
^{12}The exception to this rule is that if the Format value includes a precision of “$.\ast $”, then Digits will be used to determine the actual precision used.
^{13}Anyone who seriously uses the C run time library “scanf” function will know about the need for this check!
^{14}It will probably not be obvious why this restriction is necessary, but consider creating a Frame with one longitude axis and two latitude axes. Which latitude axis should be associated with the longitude axis?
^{15}For instance, a line of constant Declination is not a geodesic