The hyperdrive calibration solutions format
-Jones matrices are stored in a fits file as an "image" with 4 dimensions
-(timeblock, tile, chanblock, float, in that order) in the "SOLUTIONS" HDU (which
+
Jones matrices are stored in a fits file as an "image" with 4 dimensions
+(timeblock, tile, chanblock, float, in that order) in the "SOLUTIONS" HDU (which
is the second HDU). An element of the solutions is a 64-bit float (a.k.a.
double-precision float). The last dimension always has a length of 8; these
correspond to the complex gains of the X dipoles (\( g_x \)), the leakage of
@@ -157,10 +158,10 @@
-Note that in the context of the MWA, "antenna" and "tile" are used
+
Note that in the context of the MWA, "antenna" and "tile" are used
interchangeably.
Metadata
@@ -186,17 +187,17 @@ Cal
path to this file.
Raw MWA data corrections
PFB describes the PFB gains flavour applied to
-the raw MWA data. At the time of writing, this flavour is described as "jake",
-"cotter2014", "empirical", "levine", or "none".
-D_GAINS is "Y" if the digital
+the raw MWA data. At the time of writing, this flavour is described as "jake",
+"cotter2014", "empirical", "levine", or "none".
+D_GAINS is "Y" if the digital
gains were applied to the raw MWA
-data. "N" if they were not.
-CABLELEN is "Y" if the cable length
+data. "N" if they were not.
+CABLELEN is "Y" if the cable length
corrections were applied to the raw
-MWA data. "N" if they were not.
-GEOMETRY is "Y" if the geometric delay
+MWA data. "N" if they were not.
+GEOMETRY is "Y" if the geometric delay
correction
-was applied to the raw MWA data. "N" if they were not.
+was applied to the raw MWA data. "N" if they were not.
Others
MODELLER describes what was used to generate model visibilities in
calibration. This is either CPU or details on the CUDA device used, e.g.
@@ -204,18 +205,18 @@
Others
Extra HDUs
More metadata are contained in HDUs other than the first one (that which
contains the metadata keys described above). Other than the first HDU and the
-"SOLUTIONS" HDU (HDUs 1 and 2, respectfully), all HDUs and their contents are
+"SOLUTIONS" HDU (HDUs 1 and 2, respectfully), all HDUs and their contents are
optional.
TIMEBLOCKS
See blocks for an explanation of what timeblocks are.
-The "TIMEBLOCKS" HDU is a FITS table with three columns:
+The "TIMEBLOCKS" HDU is a FITS table with three columns:
StartEndAverage
Each row represents a calibration timeblock, and there must be the same number
-of rows as there are timeblocks in the calibration solutions (in the "SOLUTIONS"
+of rows as there are timeblocks in the calibration solutions (in the "SOLUTIONS"
HDU). Each of these times is a centroid GPS timestamp.
It is possible to have one or multiple columns without data; cfitsio will
write zeros for values, but hyperdrive will ignore columns with all zeros.
@@ -226,7 +227,7 @@ TIMEBLOCKS
timesteps in that timeblock are used, then the average time could be 12.666 or
13.333.
TILES
-The "TILES" HDU is a FITS table with up to five columns:
+The "TILES" HDU is a FITS table with up to five columns:
AntennaFlagTILES
DipoleDelays
Antenna is the 0-N antenna index (where N is the total number of antennas in
-the observation). These indices match the "Antenna" column of an MWA
+the observation). These indices match the "Antenna" column of an MWA
metafits file.
Flag is a boolean indicating whether an antenna was flagged for calibration
(1) or not (0).
@@ -248,7 +249,7 @@ TILES
There are 16 values per tile.
CHANBLOCKS
See blocks for an explanation of what chanblocks are.
-The "CHANBLOCKS" HDU is a FITS table with up to three columns:
+The "CHANBLOCKS" HDU is a FITS table with up to three columns:
IndexFlagCHANBLOCKS
If any of the frequencies is an NaN, then hyperdrive will not use the Freq
column.
RESULTS (Calibration results)
-The "RESULTS" HDU is a FITS image with two dimensions -- timeblock and
+
The "RESULTS" HDU is a FITS image with two dimensions -- timeblock and
chanblock, in that order -- that describe the precision to which a chanblock
converged for that timeblock (as double-precision floats). If a chanblock was
flagged, NaN is provided for its precision. NaN is also listed for chanblocks
that completely failed to calibrate.
These calibration precisions must have the same number of timeblocks and
-chanblocks described by the calibration solutions (in the "SOLUTIONS" HDU).
+chanblocks described by the calibration solutions (in the "SOLUTIONS" HDU).
BASELINES
-The "BASELINES" HDU is a FITS image with one dimension. The values of the
-"image" (let's call it an array) are the double-precision float baseline weights
+
The "BASELINES" HDU is a FITS image with one dimension. The values of the
+"image" (let's call it an array) are the double-precision float baseline weights
used in calibration (controlled by UVW minimum and maximum cutoffs). The length
of the array is the total number of baselines (i.e. flagged and unflagged).
Flagged baselines have weights of NaN, e.g. baseline 0 is between antennas 0 and
@@ -282,10 +283,12 @@
BASELINES
These baseline weights must have a non-NaN value for all tiles in the
observation (e.g. if there are 128 tiles in the calibration solutions, then
there must be 8128 baseline weights).
-
+
A full example of reading and plotting solutions is
@@ -295,20 +298,20 @@
BASELINES
from astropy.io import fits
-f = fits.open("hyperdrive_solutions.fits")
-sols = f["SOLUTIONS"].data
+f = fits.open("hyperdrive_solutions.fits")
+sols = f["SOLUTIONS"].data
num_timeblocks, num_tiles, num_chanblocks, _ = sols.shape
-obsid = f[0].header["OBSID"]
-pfb_flavour = f[0].header["PFB"]
-start_times = f[0].header["S_TIMES"]
+obsid = f[0].header["OBSID"]
+pfb_flavour = f[0].header["PFB"]
+start_times = f[0].header["S_TIMES"]
-tile_names = [tile["TileName"] for tile in f["TILES"].data]
-tile_flags = [tile["Flag"] for tile in f["TILES"].data]
+tile_names = [tile["TileName"] for tile in f["TILES"].data]
+tile_flags = [tile["Flag"] for tile in f["TILES"].data]
-freqs = [chan["FREQ"] for chan in f["CHANBLOCKS"].data]
+freqs = [chan["FREQ"] for chan in f["CHANBLOCKS"].data]
-cal_precisions_for_timeblock_0 = f["RESULTS"].data[0]
+cal_precisions_for_timeblock_0 = f["RESULTS"].data[0]
diff --git a/defs/cal_sols_rts.html b/defs/cal_sols_rts.html
index 56fc5e4c..e3512dd5 100644
--- a/defs/cal_sols_rts.html
+++ b/defs/cal_sols_rts.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -153,10 +154,12 @@
+
hyperdrive solutions-convert /path/to/rts/solutions/ rts-as-hyp-solutions.fits -m /path/to/obs.metafits
@@ -167,10 +170,12 @@
+
I (CHJ) spent a very long time trying to make the writing of RTS solutions
diff --git a/defs/coords.html b/defs/coords.html
index 94c67111..14163012 100644
--- a/defs/coords.html
+++ b/defs/coords.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -152,38 +153,38 @@
ITRF
-frame (internally we refer to this as "geocentric XYZ"). There's also a
-"geodetic XYZ" frame; an example of this is WGS
+frame (internally we refer to this as "geocentric XYZ"). There's also a
+"geodetic XYZ" frame; an example of this is WGS
84 (which we assume
everywhere when converting, as it's the current best ellipsoid). Finally,
-there's also an "East North Height" coordinate system.
+there's also an "East North Height" coordinate system.
To calculate UVW baseline coordinates, geodetic XYZ coordinates are
required1. Therefore, various coordinate conversions are required to obtain
UVWs. The conversion between all of these systems is briefly described below.
The relevant code lives within Marlu.
-ITRF and "geocentric XYZ"
+ITRF and "geocentric XYZ"
As the name implies, this coordinate system uses the centre of the Earth as a
reference. To convert between geocentric and geodetic, an array position is
-required (i.e. the "average" location on the Earth of the instrument collecting
+required (i.e. the "average" location on the Earth of the instrument collecting
visibilities). When all antenna positions are geocentric, the array position is
given by the mean antenna position.
-Measurement sets indicate the usage of ITRF with the "MEASURE_REFERENCE" keyword
-attached to the POSITION column of an ANTENNA table (value "ITRF").
+Measurement sets indicate the usage of ITRF with the "MEASURE_REFERENCE" keyword
+attached to the POSITION column of an ANTENNA table (value "ITRF").
The uvfits
standard states
-that only supported frame is "ITRF", and hyperdrive assumes that only ITRF is
+that only supported frame is "ITRF", and hyperdrive assumes that only ITRF is
used. However, CASA/casacore seem to write out antenna positions incorrectly;
the positions look like what you would find in an equivalent measurement set.
The incorrect behaviour is detected and accounted for.
-"Geodetic XYZ"
+"Geodetic XYZ"
This coordinate system is similar to geocentric, but uses an array position as
its reference.
-Measurement sets support the WGS 84 frame, again with the "MEASURE_REFERENCE"
-keyword attached to the POSITION column of an ANTENNA table (value "WGS84").
+
Measurement sets support the WGS 84 frame, again with the "MEASURE_REFERENCE"
+keyword attached to the POSITION column of an ANTENNA table (value "WGS84").
However, hyperdrive currently does not check if geodetic positions are used;
it instead just assumes geocentric.
-When read literally, the antenna positions in a uvfits file ("STABXYZ" column of
-the "AIPS AN" HDU) should be geodetic, not counting the aforementioned
+
When read literally, the antenna positions in a uvfits file ("STABXYZ" column of
+the "AIPS AN" HDU) should be geodetic, not counting the aforementioned
casacore bug.
East North Height (ENH)
MWA tiles positions are listed in metafits files with
@@ -232,7 +233,7 @@
UVWs
Note that this is a UVW coordinate for an antenna. To get the proper baseline
UVW, a difference between two antennas' UVWs needs to be taken. The order of
-this subtraction is important; hyperdrive uses the "antenna1 - antenna2"
+this subtraction is important; hyperdrive uses the "antenna1 - antenna2"
convention. Software that reads data may need to conjugate visibilities if this
convention is different.
Further reading
diff --git a/defs/dut1.html b/defs/dut1.html
index 0006932b..47c222da 100644
--- a/defs/dut1.html
+++ b/defs/dut1.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -164,7 +165,7 @@ More explan
A lot of good, easy-to-read information is
here.
UTC keeps track with TAI but only through the aid of leap seconds (both are
-"atomic time frames"). UT1 is the "actual time", but the Earth's rate of
+"atomic time frames"). UT1 is the "actual time", but the Earth's rate of
rotation is difficult to measure and predict. DUT1 is not allowed to be more
than -0.9 or 0.9 seconds; a leap second is introduced before that threshold is
reached.
diff --git a/defs/fd_types.html b/defs/fd_types.html
index a5a7ea67..15b68099 100644
--- a/defs/fd_types.html
+++ b/defs/fd_types.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,10 +152,12 @@ Flux-de
This page describes supported flux-density types within hyperdrive. The
following pages detail their usage within sky-model source lists. This
page details how each type is estimated in modelling.
-
+
Most astrophysical sources are modelled as power laws. These are simply
@@ -163,16 +166,18 @@
Flux-de
spectral index \( \alpha \).
Curved power laws are formalised in Section 4.1 of Callingham et al.
2017. These are
-the same as power laws but with an additional "spectral curvature" parameter \(
+the same as power laws but with an additional "spectral curvature" parameter \(
q \).
Both kinds of power law flux-density representations are preferred in
hyperdrive.
-
+
The list type is simply many instances of a Stokes \( \text{I} \), \(
diff --git a/defs/modelling/estimating.html b/defs/modelling/estimating.html
index f60bd4eb..66a9a755 100644
--- a/defs/modelling/estimating.html
+++ b/defs/modelling/estimating.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -155,10 +156,12 @@
+
Both power-law and curved-power-law sources have a spectral index (\( \alpha
@@ -199,13 +202,15 @@
+
-When estimating flux densities from a list, it is feared that the "jagged" shape
+
When estimating flux densities from a list, it is feared that the "jagged" shape
of a component's spectral energy distribution introduces artefacts into an EoR
power spectrum.
It is relatively expensive to estimate flux densities from a list type. For all
diff --git a/defs/modelling/intro.html b/defs/modelling/intro.html
index 7129a089..ca482fa2 100644
--- a/defs/modelling/intro.html
+++ b/defs/modelling/intro.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/defs/modelling/rime.html b/defs/modelling/rime.html
index e2470068..e0799f3d 100644
--- a/defs/modelling/rime.html
+++ b/defs/modelling/rime.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,10 +149,12 @@
mwa_hyperdrive documentation
Measurement equation
-
+
A lot of this content was taken from Jack Line's
diff --git a/defs/mwa/corrections.html b/defs/mwa/corrections.html
index 1f5a7233..2c7bd4ab 100644
--- a/defs/mwa/corrections.html
+++ b/defs/mwa/corrections.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,16 +149,18 @@ mwa_hyperdrive documentation
Raw data corrections
-A number of things can be done to "correct" or "pre-process" raw MWA data before
+
A number of things can be done to "correct" or "pre-process" raw MWA data before
it is ready for calibration (or other analysis). These tasks are handled by
Birli, either as the Birli
executable itself, or internally in hyperdrive.
cotter used to perform these tasks
but it has been superseded by Birli.
-
+
Many MWA observations do not apply a geometric correction despite having a
@@ -168,44 +171,50 @@
Raw
on calibration!
-
+
The poly-phase filter bank used by the MWA affects visibilities before they get
-saved to disk. Over time, a number of "flavours" of these gains have been used:
+saved to disk. Over time, a number of "flavours" of these gains have been used:
-- "Jake Jones" (
jake; 200 Hz)
-- "cotter 2014" (
cotter2014; 10 kHz)
-- "RTS empirical" (
empirical; 40 kHz)
-- "Alan Levine" (
levine; 40 kHz)
+- "Jake Jones" (
jake; 200 Hz)
+- "cotter 2014" (
cotter2014; 10 kHz)
+- "RTS empirical" (
empirical; 40 kHz)
+- "Alan Levine" (
levine; 40 kHz)
-When correcting raw data, the "Jake Jones" gains are used by default. For each
+
When correcting raw data, the "Jake Jones" gains are used by default. For each
flavour, the first item in the parentheses (e.g. cotter2014) indicates what
should be supplied to hyperdrive if you want to use those gains instead. There
-is also a none "flavour" if you want to disable PFB gain correction.
+is also a none "flavour" if you want to disable PFB gain correction.
In CHJ's experience, using different flavours have very little effect on
calibration quality.
Some more information on the PFB can be found
here.
-
+
Each tile is connected by a cable, and that cable might have a different length
to others. This correction aims to better align the signals of each tile.
-
+
todo!()
diff --git a/defs/mwa/dead_dipoles.html b/defs/mwa/dead_dipoles.html
index 75e3453b..0c140dff 100644
--- a/defs/mwa/dead_dipoles.html
+++ b/defs/mwa/dead_dipoles.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,16 +149,16 @@ mwa_hyperdrive documentation
Dead dipoles
-Each MWA tile has 16 "bowties", and each bowtie is made up of two dipoles (one
-X, one Y). We refer to a "dead" dipole as one that is not functioning correctly
+
Each MWA tile has 16 "bowties", and each bowtie is made up of two dipoles (one
+X, one Y). We refer to a "dead" dipole as one that is not functioning correctly
(hopefully not receiving any power at all). This information is used in
generating beam responses as part of modelling visibilities. The more accurate
the visibilities, the better that calibration performs, so it is important to
account for dead dipoles if possible.
Beam responses are generated with
hyperbeam and dead dipole
-information is encoded as a "dipole gain" of 1 ("alive") or 0 ("dead"). It is
-possible to supply other values for dipole gains with a "DipAmps" column; see
+information is encoded as a "dipole gain" of 1 ("alive") or 0 ("dead"). It is
+possible to supply other values for dipole gains with a "DipAmps" column; see
the metafits page.
For the relevant functions, dead dipole information can be ignored by supplying
a flag --unity-dipole-gains. This sets all dipole gains to 1.
@@ -166,8 +167,8 @@ Dead dipolesSee this
page for
more info on dipole ordering.
-
In the image below, you can see the 12th Y dipole is dead for "Tile022". All
-other dipoles are "alive".
+In the image below, you can see the 12th Y dipole is dead for "Tile022". All
+other dipoles are "alive".
diff --git a/defs/mwa/delays.html b/defs/mwa/delays.html
index 693c33da..d08c827b 100644
--- a/defs/mwa/delays.html
+++ b/defs/mwa/delays.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,7 +149,7 @@ mwa_hyperdrive documentation
Dipole delays
-A tile's dipole delays control where it is "pointing". Delays are provided as
+
A tile's dipole delays control where it is "pointing". Delays are provided as
numbers, and this controls how long a dipole's response is delayed before its
response correlated with other dipoles. This effectively allows the MWA to be
more sensitive in a particular direction without any physical movement.
@@ -168,8 +169,8 @@ Dipole delays
would correspond to the example above. Note that these user-supplied delays will
override delays that are otherwise provided.
-Dipoles cannot be delayed by more than "31". "32" is code for "dead
-dipole", which means that these dipoles should not be used
+
Dipoles cannot be delayed by more than "31". "32" is code for "dead
+dipole", which means that these dipoles should not be used
when modelling a tile's response.
Ideal dipole delays
Most (all?) MWA observations use a single set of delays for all tiles. Dipole
@@ -178,10 +179,10 @@
Ideal
- In the
DELAYS key in HDU 1; and
- For each tile in HDU 2.
-The delays in HDU 1 are referred to as "ideal" dipole delays. A set of delays
-are not ideal if any are "32" (i.e. dead).
-However, the HDU 1 delays may all be "32". This is an indication from the
-observatory that this observation is "bad" and should not be used. hyperdrive
+
The delays in HDU 1 are referred to as "ideal" dipole delays. A set of delays
+are not ideal if any are "32" (i.e. dead).
+However, the HDU 1 delays may all be "32". This is an indication from the
+observatory that this observation is "bad" and should not be used. hyperdrive
will proceed with such observations but issue a warning. In this case, the ideal
delays are obtained by iterating over all tile delays until each delay is not
32.
diff --git a/defs/mwa/metafits.html b/defs/mwa/metafits.html
index dfda8050..b019910a 100644
--- a/defs/mwa/metafits.html
+++ b/defs/mwa/metafits.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,25 +149,29 @@ mwa_hyperdrive documentation
Metafits files
-The MWA tracks observation metadata with "metafits" files. Often these accompany
-the raw visibilities in a download, but these could be old (such as the "PPD
-metafits" files). hyperdrive does not support PPD metafits files; only new
+The MWA tracks observation metadata with "metafits" files. Often these accompany
+the raw visibilities in a download, but these could be old (such as the "PPD
+metafits" files). hyperdrive does not support PPD metafits files; only new
metafits files should be used.
This command downloads a new metafits file for the specified observation ID:
-
+
-OBSID=1090008640; wget "http://ws.mwatelescope.org/metadata/fits?obs_id=${OBSID}" -O "${OBSID}".metafits
+OBSID=1090008640; wget "http://ws.mwatelescope.org/metadata/fits?obs_id=${OBSID}" -O "${OBSID}".metafits
-
+
Measurement sets and uvfits files do not contain MWA-specific information,
@@ -175,10 +180,12 @@
Metafits files<
uvfits file may also lack dipole delay information.
-
+
The database of MWA metadata can change over time for observations conducted
@@ -191,11 +198,11 @@
Metafits files<
Controlling dipole gains
-If the "TILEDATA" HDU of a metafits contains a "DipAmps" column, each row
+
If the "TILEDATA" HDU of a metafits contains a "DipAmps" column, each row
containing 16 double-precision values for bowties in the M&C order, these are
-used as the dipole gains in beam calculations. If the "DipAmps" column isn't
+used as the dipole gains in beam calculations. If the "DipAmps" column isn't
available, the default behaviour is to use gains of 1.0 for all dipoles, except
-those that have delays of 32 in the "Delays" column (they will have a gain of
+those that have delays of 32 in the "Delays" column (they will have a gain of
0.0, and are considered dead).
diff --git a/defs/mwa/mwaf.html b/defs/mwa/mwaf.html
index 54eb2f70..c3e15aa5 100644
--- a/defs/mwa/mwaf.html
+++ b/defs/mwa/mwaf.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -157,10 +158,12 @@ mwaf flag fil
At the time of writing, hyperdrive only utilises mwaf files when reading
visibilities from raw data.
-
+
cotter-produced mwaf files are unreliable because
diff --git a/defs/mwa/mwalib.html b/defs/mwa/mwalib.html
index ca12b618..ba400ada 100644
--- a/defs/mwa/mwalib.html
+++ b/defs/mwa/mwalib.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,7 +152,7 @@ mwalib
mwalib is the official MWA
raw-data-reading library. hyperdrive users usually don't need to concern
themselves with it, but mwalib errors may arise.
-mwalib can be quite noisy with log messages (particularly at the "trace"
+
mwalib can be quite noisy with log messages (particularly at the "trace"
level); it is possible to suppress these messages by setting an environment
variable:
RUST_LOG=mwalib=error
diff --git a/defs/mwa/picket_fence.html b/defs/mwa/picket_fence.html
index 46b8fc38..619d33b5 100644
--- a/defs/mwa/picket_fence.html
+++ b/defs/mwa/picket_fence.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,8 +149,8 @@ mwa_hyperdrive documentation
Picket fence observations
-A "picket fence" observation contains more than one "spectral window" (or
-"SPW"). That is, not all the frequency channels in an observation are
+
A "picket fence" observation contains more than one "spectral window" (or
+"SPW"). That is, not all the frequency channels in an observation are
continuous; there's at least one gap somewhere.
hyperdrive does not currently support picket fence observations, but it will
eventually support them properly. However, it is possible to calibrate a
diff --git a/defs/pols.html b/defs/pols.html
index f7fc334a..2c72e000 100644
--- a/defs/pols.html
+++ b/defs/pols.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/defs/source_list_ao.html b/defs/source_list_ao.html
index b3d758d6..483e5510 100644
--- a/defs/source_list_ao.html
+++ b/defs/source_list_ao.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -157,20 +158,22 @@
Source names are allowed to have spaces inside them, because the names are
surrounded by quotes. This is fine for reading, but when converting one of these
sources to another format, the spaces need to be translated to underscores.
-
+
skymodel fileformat 1.1
source {
- name "J002549-260211"
+ name "J002549-260211"
component {
type point
position 0h25m49.2s -26d02m13s
@@ -185,7 +188,7 @@
+
@@ -83,7 +84,7 @@
@@ -161,10 +162,12 @@
+
The following are the contents of a valid YAML file. super_sweet_source1 is a
@@ -224,10 +227,12 @@
+
The following are the contents of a valid JSON file. super_sweet_source1 is a
@@ -235,79 +240,79 @@
{
- "super_sweet_source1": [
+ "super_sweet_source1": [
{
- "ra": 10.0,
- "dec": -27.0,
- "comp_type": "point",
- "flux_type": {
- "list": [
+ "ra": 10.0,
+ "dec": -27.0,
+ "comp_type": "point",
+ "flux_type": {
+ "list": [
{
- "freq": 150000000.0,
- "i": 10.0
+ "freq": 150000000.0,
+ "i": 10.0
},
{
- "freq": 170000000.0,
- "i": 5.0,
- "q": 1.0,
- "u": 2.0,
- "v": 3.0
+ "freq": 170000000.0,
+ "i": 5.0,
+ "q": 1.0,
+ "u": 2.0,
+ "v": 3.0
}
]
}
}
],
- "super_sweet_source2": [
+ "super_sweet_source2": [
{
- "ra": 0.0,
- "dec": -35.0,
- "comp_type": {
- "gaussian": {
- "maj": 20.0,
- "min": 10.0,
- "pa": 75.0
+ "ra": 0.0,
+ "dec": -35.0,
+ "comp_type": {
+ "gaussian": {
+ "maj": 20.0,
+ "min": 10.0,
+ "pa": 75.0
}
},
- "flux_type": {
- "power_law": {
- "si": -0.8,
- "fd": {
- "freq": 170000000.0,
- "i": 5.0,
- "q": 1.0,
- "u": 2.0,
- "v": 3.0
+ "flux_type": {
+ "power_law": {
+ "si": -0.8,
+ "fd": {
+ "freq": 170000000.0,
+ "i": 5.0,
+ "q": 1.0,
+ "u": 2.0,
+ "v": 3.0
}
}
}
},
{
- "ra": 155.0,
- "dec": -10.0,
- "comp_type": {
- "shapelet": {
- "maj": 20.0,
- "min": 10.0,
- "pa": 75.0,
- "coeffs": [
+ "ra": 155.0,
+ "dec": -10.0,
+ "comp_type": {
+ "shapelet": {
+ "maj": 20.0,
+ "min": 10.0,
+ "pa": 75.0,
+ "coeffs": [
{
- "n1": 0,
- "n2": 1,
- "value": 0.5
+ "n1": 0,
+ "n2": 1,
+ "value": 0.5
}
]
}
},
- "flux_type": {
- "curved_power_law": {
- "si": -0.6,
- "fd": {
- "freq": 150000000.0,
- "i": 50.0,
- "q": 0.5,
- "u": 0.1
+ "flux_type": {
+ "curved_power_law": {
+ "si": -0.6,
+ "fd": {
+ "freq": 150000000.0,
+ "i": 50.0,
+ "q": 0.5,
+ "u": 0.1
},
- "q": 0.2
+ "q": 0.2
}
}
}
diff --git a/defs/source_list_rts.html b/defs/source_list_rts.html
index b8bf038f..e27111c8 100644
--- a/defs/source_list_rts.html
+++ b/defs/source_list_rts.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -155,16 +156,18 @@
Keywords like SOURCE, COMPONENT, POINT etc. must be at the start of a line
(i.e. no preceding space).
-RTS sources always have a "base source", which can be thought of as a
+
RTS sources always have a "base source", which can be thought of as a
non-optional component or the first component in a collection of components.
-
+
Taken from srclists, file
diff --git a/defs/source_lists.html b/defs/source_lists.html
index e8a7f824..0869d501 100644
--- a/defs/source_lists.html
+++ b/defs/source_lists.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -160,13 +161,15 @@
-hyperdrive can also convert between formats, although in a "lossy" way;
+
hyperdrive can also convert between formats, although in a "lossy" way;
non-hyperdrive formats cannot represent all component and/or flux-density
types.
-
+
-
+
-
+
-
+
Each component in a sky model is represented in one of three ways:
@@ -216,7 +225,7 @@ Point sources are the simplest. Gaussian sources could be considered the same as
point sources, but have details on their structure (major- and minor-axes,
position angle). Finally, shapelets are described the same way as Gaussians but
-additionally have multiple "shapelet components". Examples of each of these
+additionally have multiple "shapelet components". Examples of each of these
components can be found on the following documentation pages and in the examples
directory.
diff --git a/defs/vis_formats_read.html b/defs/vis_formats_read.html
index 58b50cad..4d68cae4 100644
--- a/defs/vis_formats_read.html
+++ b/defs/vis_formats_read.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,13 +149,15 @@ mwa_hyperdrive documentation
Supported visibility formats for reading
-
+
-Raw "legacy" MWA data comes in "gpubox" files. "MWAX" data comes in a similar
+
Raw "legacy" MWA data comes in "gpubox" files. "MWAX" data comes in a similar
format, and *ch???*.fits is a useful glob to identify them. Raw data can be
accessed from the ASVO.
Here are examples of using each of these MWA formats with di-calibrate:
@@ -167,10 +170,12 @@
+
hyperdrive di-calibrate -d *.ms *.metafits -s a_good_sky_model.yaml
@@ -186,10 +191,12 @@ below for more info.
-
+
hyperdrive di-calibrate -d *.uvfits *.metafits -s a_good_sky_model.yaml
@@ -203,10 +210,12 @@ here.
-
+
When using a metafits file with a uvfits/MS, the tile names in the metafits and
diff --git a/defs/vis_formats_write.html b/defs/vis_formats_write.html
index cb03f383..791676b5 100644
--- a/defs/vis_formats_write.html
+++ b/defs/vis_formats_write.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -152,10 +153,12 @@
+
hyperdrive solutions-apply \
@@ -165,10 +168,12 @@
+
hyperdrive solutions-apply \
@@ -180,10 +185,12 @@ here.
-
+
When writing out visibilities, they can be averaged in time and frequency. Units
@@ -210,10 +217,12 @@
+
All aspects of hyperdrive that can write visibilities can write to multiple
diff --git a/dev/ndarray.html b/dev/ndarray.html
index 200f6a88..bd24651f 100644
--- a/dev/ndarray.html
+++ b/dev/ndarray.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/dev/vec1.html b/dev/vec1.html
index 8c4d286f..4d92ab93 100644
--- a/dev/vec1.html
+++ b/dev/vec1.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/index.html b/index.html
index 333d1b6e..7a6cef95 100644
--- a/index.html
+++ b/index.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/installation/from_source.html b/installation/from_source.html
index 50c1b2ce..d3588bef 100644
--- a/installation/from_source.html
+++ b/installation/from_source.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -150,10 +151,12 @@
mwa_hyperdrive documentation
Installing hyperdrive from source code
Dependencies
hyperdrive depends on these C libraries:
-
+
@@ -173,10 +176,12 @@ Dependencies
-
+
@@ -196,10 +201,12 @@ Dependencies
Optional dependencies
-
+
@@ -213,10 +220,12 @@ O
-
+
@@ -233,10 +242,12 @@ O
-
+
@@ -261,10 +272,12 @@ O
Installing Rust
-
+
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
@@ -289,20 +302,24 @@
+
It is possible to compile with more optimisations if you give --profile production to the cargo install command. This may make things a few percent
faster, but compilation will take much longer.
-
+
Do you have a CUDA-capable NVIDIA GPU? Ensure you have installed
@@ -316,8 +333,8 @@
cargo install --path . --locked --features=cuda,gpu-single
-If you're using "datacentre" products (e.g. a V100 available on the
-Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
+
If you're using "datacentre" products (e.g. a V100 available on the
+Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
floats:
cargo install --path . --locked --features=cuda
@@ -329,17 +346,19 @@
+
Do you have a HIP-capable AMD GPU? Ensure you have installed HIP (instructions
are above), and compile with the hip feature (single-precision floats):
cargo install --path . --locked --features=hip,gpu-single
-If you're using "datacentre" products (e.g. the GPUs on the "setonix"
+
If you're using "datacentre" products (e.g. the GPUs on the "setonix"
supercomputer), you probably want double-precision floats:
cargo install --path . --locked --features=hip
@@ -348,10 +367,12 @@
+
The aforementioned C libraries can each be compiled by cargo. all-static
@@ -361,10 +382,12 @@
+
cargo features can be chained in a comma-separated list:
@@ -372,10 +395,12 @@
+
If you're having problems compiling, it's possible you have an older Rust
@@ -390,10 +415,12 @@
+
hyperdrive used to depend on the ERFA C
diff --git a/installation/intro.html b/installation/intro.html
index b0b865d9..a99a3ea0 100644
--- a/installation/intro.html
+++ b/installation/intro.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/installation/post.html b/installation/post.html
index 9189312c..63af0d1c 100644
--- a/installation/post.html
+++ b/installation/post.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,10 +149,12 @@
mwa_hyperdrive documentation
Post installation instructions
-
+
Many hyperdrive functions require the beam code to function. The MWA FEE beam
diff --git a/installation/pre_compiled.html b/installation/pre_compiled.html
index 136226e5..d6f12e5c 100644
--- a/installation/pre_compiled.html
+++ b/installation/pre_compiled.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,30 +152,32 @@
Visit the GitHub releases page. You should see releases like the following:
-- Under "Assets", download one of the
tar.gz files starting with
+ - Under "Assets", download one of the
tar.gz files starting with
mwa_hyperdrive;
- Untar it (e.g.
tar -xvf mwa_hyperdrive*.tar.gz); and
- Run the binary (
./hyperdrive).
If you intend on running hyperdrive on a desktop GPU, then you probably want
-the "CUDA-single" release. You can still use the double-precision version on a
+the "CUDA-single" release. You can still use the double-precision version on a
desktop GPU, but it will be much slower than single-precision. Instructions to
install CUDA are on the next page.
It is possible to run hyperdrive with HIP (i.e. the AMD equivalent to
NVIDIA's CUDA), but HIP does not appear to offer static libraries, so no static
feature is provided, and users will need to compile hyperdrive themselves with
instructions on the next page.
-
+
The pre-compiled binaries are made by GitHub actions using:
cargo build --release --locked --no-default-features --features=hdf5-static,cfitsio-static
This means they cannot plot calibration solutions.
-"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
+"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
the cuda and gpu-single features. CUDA cannot legally be statically linked
so a local installation of CUDA is required.
diff --git a/mdbook-admonish.css b/mdbook-admonish.css
new file mode 100644
index 00000000..45aeff05
--- /dev/null
+++ b/mdbook-admonish.css
@@ -0,0 +1,348 @@
+@charset "UTF-8";
+:is(.admonition) {
+ display: flow-root;
+ margin: 1.5625em 0;
+ padding: 0 1.2rem;
+ color: var(--fg);
+ page-break-inside: avoid;
+ background-color: var(--bg);
+ border: 0 solid black;
+ border-inline-start-width: 0.4rem;
+ border-radius: 0.2rem;
+ box-shadow: 0 0.2rem 1rem rgba(0, 0, 0, 0.05), 0 0 0.1rem rgba(0, 0, 0, 0.1);
+}
+@media print {
+ :is(.admonition) {
+ box-shadow: none;
+ }
+}
+:is(.admonition) > * {
+ box-sizing: border-box;
+}
+:is(.admonition) :is(.admonition) {
+ margin-top: 1em;
+ margin-bottom: 1em;
+}
+:is(.admonition) > .tabbed-set:only-child {
+ margin-top: 0;
+}
+html :is(.admonition) > :last-child {
+ margin-bottom: 1.2rem;
+}
+
+a.admonition-anchor-link {
+ display: none;
+ position: absolute;
+ left: -1.2rem;
+ padding-right: 1rem;
+}
+a.admonition-anchor-link:link, a.admonition-anchor-link:visited {
+ color: var(--fg);
+}
+a.admonition-anchor-link:link:hover, a.admonition-anchor-link:visited:hover {
+ text-decoration: none;
+}
+a.admonition-anchor-link::before {
+ content: "§";
+}
+
+:is(.admonition-title, summary.admonition-title) {
+ position: relative;
+ min-height: 4rem;
+ margin-block: 0;
+ margin-inline: -1.6rem -1.2rem;
+ padding-block: 0.8rem;
+ padding-inline: 4.4rem 1.2rem;
+ font-weight: 700;
+ background-color: rgba(68, 138, 255, 0.1);
+ print-color-adjust: exact;
+ -webkit-print-color-adjust: exact;
+ display: flex;
+}
+:is(.admonition-title, summary.admonition-title) p {
+ margin: 0;
+}
+html :is(.admonition-title, summary.admonition-title):last-child {
+ margin-bottom: 0;
+}
+:is(.admonition-title, summary.admonition-title)::before {
+ position: absolute;
+ top: 0.625em;
+ inset-inline-start: 1.6rem;
+ width: 2rem;
+ height: 2rem;
+ background-color: #448aff;
+ print-color-adjust: exact;
+ -webkit-print-color-adjust: exact;
+ mask-image: url('data:image/svg+xml;charset=utf-8,');
+ -webkit-mask-image: url('data:image/svg+xml;charset=utf-8,');
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-size: contain;
+ content: "";
+}
+:is(.admonition-title, summary.admonition-title):hover a.admonition-anchor-link {
+ display: initial;
+}
+
+details.admonition > summary.admonition-title::after {
+ position: absolute;
+ top: 0.625em;
+ inset-inline-end: 1.6rem;
+ height: 2rem;
+ width: 2rem;
+ background-color: currentcolor;
+ mask-image: var(--md-details-icon);
+ -webkit-mask-image: var(--md-details-icon);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-size: contain;
+ content: "";
+ transform: rotate(0deg);
+ transition: transform 0.25s;
+}
+details[open].admonition > summary.admonition-title::after {
+ transform: rotate(90deg);
+}
+
+:root {
+ --md-details-icon: url("data:image/svg+xml;charset=utf-8,");
+}
+
+:root {
+ --md-admonition-icon--admonish-note: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-abstract: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-info: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-tip: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-success: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-question: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-warning: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-failure: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-danger: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-bug: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-example: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-quote: url("data:image/svg+xml;charset=utf-8,");
+}
+
+:is(.admonition):is(.admonish-note) {
+ border-color: #448aff;
+}
+
+:is(.admonish-note) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(68, 138, 255, 0.1);
+}
+:is(.admonish-note) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #448aff;
+ mask-image: var(--md-admonition-icon--admonish-note);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-note);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-abstract, .admonish-summary, .admonish-tldr) {
+ border-color: #00b0ff;
+}
+
+:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 176, 255, 0.1);
+}
+:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00b0ff;
+ mask-image: var(--md-admonition-icon--admonish-abstract);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-abstract);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-info, .admonish-todo) {
+ border-color: #00b8d4;
+}
+
+:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 184, 212, 0.1);
+}
+:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00b8d4;
+ mask-image: var(--md-admonition-icon--admonish-info);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-info);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-tip, .admonish-hint, .admonish-important) {
+ border-color: #00bfa5;
+}
+
+:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 191, 165, 0.1);
+}
+:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00bfa5;
+ mask-image: var(--md-admonition-icon--admonish-tip);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-tip);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-success, .admonish-check, .admonish-done) {
+ border-color: #00c853;
+}
+
+:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 200, 83, 0.1);
+}
+:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00c853;
+ mask-image: var(--md-admonition-icon--admonish-success);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-success);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-question, .admonish-help, .admonish-faq) {
+ border-color: #64dd17;
+}
+
+:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(100, 221, 23, 0.1);
+}
+:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #64dd17;
+ mask-image: var(--md-admonition-icon--admonish-question);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-question);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-warning, .admonish-caution, .admonish-attention) {
+ border-color: #ff9100;
+}
+
+:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 145, 0, 0.1);
+}
+:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff9100;
+ mask-image: var(--md-admonition-icon--admonish-warning);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-warning);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-failure, .admonish-fail, .admonish-missing) {
+ border-color: #ff5252;
+}
+
+:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 82, 82, 0.1);
+}
+:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff5252;
+ mask-image: var(--md-admonition-icon--admonish-failure);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-failure);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-danger, .admonish-error) {
+ border-color: #ff1744;
+}
+
+:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 23, 68, 0.1);
+}
+:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff1744;
+ mask-image: var(--md-admonition-icon--admonish-danger);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-danger);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-bug) {
+ border-color: #f50057;
+}
+
+:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(245, 0, 87, 0.1);
+}
+:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #f50057;
+ mask-image: var(--md-admonition-icon--admonish-bug);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-bug);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-example) {
+ border-color: #7c4dff;
+}
+
+:is(.admonish-example) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(124, 77, 255, 0.1);
+}
+:is(.admonish-example) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #7c4dff;
+ mask-image: var(--md-admonition-icon--admonish-example);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-example);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-quote, .admonish-cite) {
+ border-color: #9e9e9e;
+}
+
+:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(158, 158, 158, 0.1);
+}
+:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #9e9e9e;
+ mask-image: var(--md-admonition-icon--admonish-quote);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-quote);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+.navy :is(.admonition) {
+ background-color: var(--sidebar-bg);
+}
+
+.ayu :is(.admonition),
+.coal :is(.admonition) {
+ background-color: var(--theme-hover);
+}
+
+.rust :is(.admonition) {
+ background-color: var(--sidebar-bg);
+ color: var(--sidebar-fg);
+}
+.rust .admonition-anchor-link:link, .rust .admonition-anchor-link:visited {
+ color: var(--sidebar-fg);
+}
diff --git a/print.html b/print.html
index 930def8f..f5e1e13d 100644
--- a/print.html
+++ b/print.html
@@ -31,6 +31,7 @@
+
@@ -84,7 +85,7 @@
@@ -189,30 +190,32 @@ IntroductionVisit the GitHub releases page. You should see releases like the following:
-- Under "Assets", download one of the
tar.gz files starting with
+ - Under "Assets", download one of the
tar.gz files starting with
mwa_hyperdrive;
- Untar it (e.g.
tar -xvf mwa_hyperdrive*.tar.gz); and
- Run the binary (
./hyperdrive).
If you intend on running hyperdrive on a desktop GPU, then you probably want
-the "CUDA-single" release. You can still use the double-precision version on a
+the "CUDA-single" release. You can still use the double-precision version on a
desktop GPU, but it will be much slower than single-precision. Instructions to
install CUDA are on the next page.
It is possible to run hyperdrive with HIP (i.e. the AMD equivalent to
NVIDIA's CUDA), but HIP does not appear to offer static libraries, so no static
feature is provided, and users will need to compile hyperdrive themselves with
instructions on the next page.
-
+
The pre-compiled binaries are made by GitHub actions using:
cargo build --release --locked --no-default-features --features=hdf5-static,cfitsio-static
This means they cannot plot calibration solutions.
-"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
+"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
the cuda and gpu-single features. CUDA cannot legally be statically linked
so a local installation of CUDA is required.
@@ -220,10 +223,12 @@ Introduction
Installing hyperdrive from source code
Dependencies
hyperdrive depends on these C libraries:
-
+
@@ -243,10 +248,12 @@ Dependencies
-
+
@@ -266,10 +273,12 @@ Dependencies
Optional dependencies
-
+
@@ -283,10 +292,12 @@ O
-
+
@@ -303,10 +314,12 @@ O
-
+
@@ -331,10 +344,12 @@ O
Installing Rust
-
+
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
@@ -359,20 +374,24 @@
+
It is possible to compile with more optimisations if you give --profile production to the cargo install command. This may make things a few percent
faster, but compilation will take much longer.
-
+
Do you have a CUDA-capable NVIDIA GPU? Ensure you have installed
@@ -386,8 +405,8 @@
cargo install --path . --locked --features=cuda,gpu-single
-If you're using "datacentre" products (e.g. a V100 available on the
-Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
+
If you're using "datacentre" products (e.g. a V100 available on the
+Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
floats:
cargo install --path . --locked --features=cuda
@@ -399,17 +418,19 @@
+
Do you have a HIP-capable AMD GPU? Ensure you have installed HIP (instructions
are above), and compile with the hip feature (single-precision floats):
cargo install --path . --locked --features=hip,gpu-single
-If you're using "datacentre" products (e.g. the GPUs on the "setonix"
+
If you're using "datacentre" products (e.g. the GPUs on the "setonix"
supercomputer), you probably want double-precision floats:
cargo install --path . --locked --features=hip
@@ -418,10 +439,12 @@
+
The aforementioned C libraries can each be compiled by cargo. all-static
@@ -431,10 +454,12 @@
+
cargo features can be chained in a comma-separated list:
@@ -442,10 +467,12 @@
+
If you're having problems compiling, it's possible you have an older Rust
@@ -460,10 +487,12 @@
+
hyperdrive used to depend on the ERFA C
@@ -471,10 +500,12 @@
Post installation instructions
-
+
Many hyperdrive functions require the beam code to function. The MWA FEE beam
@@ -512,10 +543,12 @@
+
hyperdrive itself is split into many subcommands. These are simple to list:
@@ -537,7 +570,7 @@ hyperdrive-solutions-plot 0.2.0-alpha.11
-Plot calibration solutions. Only available if compiled with the "plotting" feature.
+Plot calibration solutions. Only available if compiled with the "plotting" feature.
USAGE:
hyperdrive solutions-plot [OPTIONS] [SOLUTIONS_FILES]...
@@ -558,16 +591,18 @@
+
It's possible to save keystrokes when subcommands aren't ambiguous, e.g. use
solutions-p as an alias for solutions-plot:
hyperdrive solutions-p
-<help text for "solutions-plot">
+<help text for "solutions-plot">
This works because there is no other subcommand that solutions-p could refer
to. On the other hand, solutions won't be accepted because both
@@ -577,8 +612,8 @@
DI calibration
-Direction-Independent (DI) calibration "corrects" raw telescope data.
-hyperdrive achieves this with "sky model calibration". This can work very
+
Direction-Independent (DI) calibration "corrects" raw telescope data.
+hyperdrive achieves this with "sky model calibration". This can work very
well, but relies on two key assumptions:
- The sky model is an accurate reflection of the input data; and
@@ -615,10 +650,12 @@ Install hyperdrive if you haven't already.
-
+
Feel free to try your own data, but test data is available in the hyperdrive
@@ -633,10 +670,12 @@
+
It's very important to use a sky model that corresponds to the data you're
@@ -646,10 +685,12 @@
+
We're going to run the di-calibrate subcommand of hyperdrive. If you look at
@@ -659,10 +700,12 @@
+
The above command can be more neatly expressed as:
@@ -675,10 +718,12 @@
+
The command we ran in step 3 should give us information on the input data, the
@@ -700,16 +745,18 @@
+
-A "chanblock" is a frequency unit of calibration;
+
A "chanblock" is a frequency unit of calibration;
it may correspond to one or many channels of the input data.
-Calibration is done iteratively; it iterates until the "stop threshold" is
-reached, or up to a set number of times. The "stop" and "minimum" thresholds
+
Calibration is done iteratively; it iterates until the "stop threshold" is
+reached, or up to a set number of times. The "stop" and "minimum" thresholds
are used during convergence. If the stop threshold is reached before the maximum
number of iterations, we say that the chanblock has converged well enough that
we can stop iterating. However, if we reach the maximum number of iterations,
@@ -725,7 +772,7 @@
@@ -733,10 +780,12 @@
+
Note that in the context of the MWA, "antenna" and "tile" are used +
Note that in the context of the MWA, "antenna" and "tile" are used interchangeably.
Raw MWA data corrections
PFB describes the PFB gains flavour applied to
-the raw MWA data. At the time of writing, this flavour is described as "jake",
-"cotter2014", "empirical", "levine", or "none".
D_GAINS is "Y" if the digital
+the raw MWA data. At the time of writing, this flavour is described as "jake",
+"cotter2014", "empirical", "levine", or "none".
D_GAINS is "Y" if the digital
gains were applied to the raw MWA
-data. "N" if they were not.
CABLELEN is "Y" if the cable length
+data. "N" if they were not.
CABLELEN is "Y" if the cable length
corrections were applied to the raw
-MWA data. "N" if they were not.
GEOMETRY is "Y" if the geometric delay
+MWA data. "N" if they were not.
GEOMETRY is "Y" if the geometric delay
correction
-was applied to the raw MWA data. "N" if they were not.
Others
MODELLER describes what was used to generate model visibilities in
calibration. This is either CPU or details on the CUDA device used, e.g.
@@ -204,18 +205,18 @@
Others
Extra HDUs
More metadata are contained in HDUs other than the first one (that which contains the metadata keys described above). Other than the first HDU and the -"SOLUTIONS" HDU (HDUs 1 and 2, respectfully), all HDUs and their contents are +"SOLUTIONS" HDU (HDUs 1 and 2, respectfully), all HDUs and their contents are optional.
TIMEBLOCKS
See blocks for an explanation of what timeblocks are.
-The "TIMEBLOCKS" HDU is a FITS table with three columns:
+The "TIMEBLOCKS" HDU is a FITS table with three columns:
StartEndAverage
Each row represents a calibration timeblock, and there must be the same number -of rows as there are timeblocks in the calibration solutions (in the "SOLUTIONS" +of rows as there are timeblocks in the calibration solutions (in the "SOLUTIONS" HDU). Each of these times is a centroid GPS timestamp.
It is possible to have one or multiple columns without data; cfitsio will
write zeros for values, but hyperdrive will ignore columns with all zeros.
TIMEBLOCKS
timesteps in that timeblock are used, then the average time could be 12.666 or 13.333.TILES
-The "TILES" HDU is a FITS table with up to five columns:
+The "TILES" HDU is a FITS table with up to five columns:
AntennaFlag
@@ -235,7 +236,7 @@ DipoleDelays
TILES
Antenna is the 0-N antenna index (where N is the total number of antennas in
-the observation). These indices match the "Antenna" column of an MWA
+the observation). These indices match the "Antenna" column of an MWA
metafits file.
Flag is a boolean indicating whether an antenna was flagged for calibration
(1) or not (0).
TILES
There are 16 values per tile.CHANBLOCKS
See blocks for an explanation of what chanblocks are.
-The "CHANBLOCKS" HDU is a FITS table with up to three columns:
+The "CHANBLOCKS" HDU is a FITS table with up to three columns:
IndexFlag
@@ -264,16 +265,16 @@ - "Jake Jones" (
jake; 200 Hz)
- - "cotter 2014" (
cotter2014; 10 kHz)
- - "RTS empirical" (
empirical; 40 kHz)
- - "Alan Levine" (
levine; 40 kHz)
+ - "Jake Jones" (
jake; 200 Hz)
+ - "cotter 2014" (
cotter2014; 10 kHz)
+ - "RTS empirical" (
empirical; 40 kHz)
+ - "Alan Levine" (
levine; 40 kHz) - In the
DELAYSkey in HDU 1; and - For each tile in HDU 2. -
- Under "Assets", download one of the
tar.gzfiles starting with + - Under "Assets", download one of the
tar.gzfiles starting withmwa_hyperdrive; - Untar it (e.g.
tar -xvf mwa_hyperdrive*.tar.gz); and - Run the binary (
./hyperdrive). - Under "Assets", download one of the
tar.gzfiles starting with + - Under "Assets", download one of the
tar.gzfiles starting withmwa_hyperdrive; - Untar it (e.g.
tar -xvf mwa_hyperdrive*.tar.gz); and - Run the binary (
./hyperdrive). - The sky model is an accurate reflection of the input data; and @@ -615,10 +650,12 @@
CHANBLOCKS
If any of the frequencies is an NaN, thenhyperdrive will not use the Freq
column.
RESULTS (Calibration results)
-The "RESULTS" HDU is a FITS image with two dimensions -- timeblock and +
The "RESULTS" HDU is a FITS image with two dimensions -- timeblock and chanblock, in that order -- that describe the precision to which a chanblock converged for that timeblock (as double-precision floats). If a chanblock was flagged, NaN is provided for its precision. NaN is also listed for chanblocks that completely failed to calibrate.
These calibration precisions must have the same number of timeblocks and -chanblocks described by the calibration solutions (in the "SOLUTIONS" HDU).
+chanblocks described by the calibration solutions (in the "SOLUTIONS" HDU).BASELINES
-The "BASELINES" HDU is a FITS image with one dimension. The values of the -"image" (let's call it an array) are the double-precision float baseline weights +
The "BASELINES" HDU is a FITS image with one dimension. The values of the +"image" (let's call it an array) are the double-precision float baseline weights used in calibration (controlled by UVW minimum and maximum cutoffs). The length of the array is the total number of baselines (i.e. flagged and unflagged). Flagged baselines have weights of NaN, e.g. baseline 0 is between antennas 0 and @@ -282,10 +283,12 @@
BASELINES
These baseline weights must have a non-NaN value for all tiles in the observation (e.g. if there are 128 tiles in the calibration solutions, then there must be 8128 baseline weights).
-A full example of reading and plotting solutions is @@ -295,20 +298,20 @@
BASELINES
from astropy.io import fits -f = fits.open("hyperdrive_solutions.fits") -sols = f["SOLUTIONS"].data +f = fits.open("hyperdrive_solutions.fits") +sols = f["SOLUTIONS"].data num_timeblocks, num_tiles, num_chanblocks, _ = sols.shape -obsid = f[0].header["OBSID"] -pfb_flavour = f[0].header["PFB"] -start_times = f[0].header["S_TIMES"] +obsid = f[0].header["OBSID"] +pfb_flavour = f[0].header["PFB"] +start_times = f[0].header["S_TIMES"] -tile_names = [tile["TileName"] for tile in f["TILES"].data] -tile_flags = [tile["Flag"] for tile in f["TILES"].data] +tile_names = [tile["TileName"] for tile in f["TILES"].data] +tile_flags = [tile["Flag"] for tile in f["TILES"].data] -freqs = [chan["FREQ"] for chan in f["CHANBLOCKS"].data] +freqs = [chan["FREQ"] for chan in f["CHANBLOCKS"].data] -cal_precisions_for_timeblock_0 = f["RESULTS"].data[0] +cal_precisions_for_timeblock_0 = f["RESULTS"].data[0]
+
hyperdrive solutions-convert /path/to/rts/solutions/ rts-as-hyp-solutions.fits -m /path/to/obs.metafits
@@ -167,10 +170,12 @@
+
I (CHJ) spent a very long time trying to make the writing of RTS solutions
diff --git a/defs/coords.html b/defs/coords.html
index 94c67111..14163012 100644
--- a/defs/coords.html
+++ b/defs/coords.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -152,38 +153,38 @@
ITRF
-frame (internally we refer to this as "geocentric XYZ"). There's also a
-"geodetic XYZ" frame; an example of this is WGS
+frame (internally we refer to this as "geocentric XYZ"). There's also a
+"geodetic XYZ" frame; an example of this is WGS
84 (which we assume
everywhere when converting, as it's the current best ellipsoid). Finally,
-there's also an "East North Height" coordinate system.
+there's also an "East North Height" coordinate system.
To calculate UVW baseline coordinates, geodetic XYZ coordinates are
required1. Therefore, various coordinate conversions are required to obtain
UVWs. The conversion between all of these systems is briefly described below.
The relevant code lives within Marlu.
-ITRF and "geocentric XYZ"
+ITRF and "geocentric XYZ"
As the name implies, this coordinate system uses the centre of the Earth as a
reference. To convert between geocentric and geodetic, an array position is
-required (i.e. the "average" location on the Earth of the instrument collecting
+required (i.e. the "average" location on the Earth of the instrument collecting
visibilities). When all antenna positions are geocentric, the array position is
given by the mean antenna position.
-Measurement sets indicate the usage of ITRF with the "MEASURE_REFERENCE" keyword
-attached to the POSITION column of an ANTENNA table (value "ITRF").
+Measurement sets indicate the usage of ITRF with the "MEASURE_REFERENCE" keyword
+attached to the POSITION column of an ANTENNA table (value "ITRF").
The uvfits
standard states
-that only supported frame is "ITRF", and hyperdrive assumes that only ITRF is
+that only supported frame is "ITRF", and hyperdrive assumes that only ITRF is
used. However, CASA/casacore seem to write out antenna positions incorrectly;
the positions look like what you would find in an equivalent measurement set.
The incorrect behaviour is detected and accounted for.
-"Geodetic XYZ"
+"Geodetic XYZ"
This coordinate system is similar to geocentric, but uses an array position as
its reference.
-Measurement sets support the WGS 84 frame, again with the "MEASURE_REFERENCE"
-keyword attached to the POSITION column of an ANTENNA table (value "WGS84").
+
Measurement sets support the WGS 84 frame, again with the "MEASURE_REFERENCE"
+keyword attached to the POSITION column of an ANTENNA table (value "WGS84").
However, hyperdrive currently does not check if geodetic positions are used;
it instead just assumes geocentric.
-When read literally, the antenna positions in a uvfits file ("STABXYZ" column of
-the "AIPS AN" HDU) should be geodetic, not counting the aforementioned
+
When read literally, the antenna positions in a uvfits file ("STABXYZ" column of
+the "AIPS AN" HDU) should be geodetic, not counting the aforementioned
casacore bug.
East North Height (ENH)
MWA tiles positions are listed in metafits files with
@@ -232,7 +233,7 @@
UVWs
Note that this is a UVW coordinate for an antenna. To get the proper baseline
UVW, a difference between two antennas' UVWs needs to be taken. The order of
-this subtraction is important; hyperdrive uses the "antenna1 - antenna2"
+this subtraction is important; hyperdrive uses the "antenna1 - antenna2"
convention. Software that reads data may need to conjugate visibilities if this
convention is different.
Further reading
diff --git a/defs/dut1.html b/defs/dut1.html
index 0006932b..47c222da 100644
--- a/defs/dut1.html
+++ b/defs/dut1.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -164,7 +165,7 @@ More explan
A lot of good, easy-to-read information is
here.
UTC keeps track with TAI but only through the aid of leap seconds (both are
-"atomic time frames"). UT1 is the "actual time", but the Earth's rate of
+"atomic time frames"). UT1 is the "actual time", but the Earth's rate of
rotation is difficult to measure and predict. DUT1 is not allowed to be more
than -0.9 or 0.9 seconds; a leap second is introduced before that threshold is
reached.
diff --git a/defs/fd_types.html b/defs/fd_types.html
index a5a7ea67..15b68099 100644
--- a/defs/fd_types.html
+++ b/defs/fd_types.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,10 +152,12 @@ Flux-de
This page describes supported flux-density types within hyperdrive. The
following pages detail their usage within sky-model source lists. This
page details how each type is estimated in modelling.
-
+
Most astrophysical sources are modelled as power laws. These are simply
@@ -163,16 +166,18 @@
Flux-de
spectral index \( \alpha \).
Curved power laws are formalised in Section 4.1 of Callingham et al.
2017. These are
-the same as power laws but with an additional "spectral curvature" parameter \(
+the same as power laws but with an additional "spectral curvature" parameter \(
q \).
Both kinds of power law flux-density representations are preferred in
hyperdrive.
-
+
The list type is simply many instances of a Stokes \( \text{I} \), \(
diff --git a/defs/modelling/estimating.html b/defs/modelling/estimating.html
index f60bd4eb..66a9a755 100644
--- a/defs/modelling/estimating.html
+++ b/defs/modelling/estimating.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -155,10 +156,12 @@
+
Both power-law and curved-power-law sources have a spectral index (\( \alpha
@@ -199,13 +202,15 @@
+
-When estimating flux densities from a list, it is feared that the "jagged" shape
+
When estimating flux densities from a list, it is feared that the "jagged" shape
of a component's spectral energy distribution introduces artefacts into an EoR
power spectrum.
It is relatively expensive to estimate flux densities from a list type. For all
diff --git a/defs/modelling/intro.html b/defs/modelling/intro.html
index 7129a089..ca482fa2 100644
--- a/defs/modelling/intro.html
+++ b/defs/modelling/intro.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/defs/modelling/rime.html b/defs/modelling/rime.html
index e2470068..e0799f3d 100644
--- a/defs/modelling/rime.html
+++ b/defs/modelling/rime.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,10 +149,12 @@
mwa_hyperdrive documentation
Measurement equation
-
+
A lot of this content was taken from Jack Line's
diff --git a/defs/mwa/corrections.html b/defs/mwa/corrections.html
index 1f5a7233..2c7bd4ab 100644
--- a/defs/mwa/corrections.html
+++ b/defs/mwa/corrections.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,16 +149,18 @@ mwa_hyperdrive documentation
Raw data corrections
-A number of things can be done to "correct" or "pre-process" raw MWA data before
+
A number of things can be done to "correct" or "pre-process" raw MWA data before
it is ready for calibration (or other analysis). These tasks are handled by
Birli, either as the Birli
executable itself, or internally in hyperdrive.
cotter used to perform these tasks
but it has been superseded by Birli.
-
+
Many MWA observations do not apply a geometric correction despite having a
@@ -168,44 +171,50 @@
Raw
on calibration!
-
+
The poly-phase filter bank used by the MWA affects visibilities before they get
-saved to disk. Over time, a number of "flavours" of these gains have been used:
+saved to disk. Over time, a number of "flavours" of these gains have been used:
-
-When correcting raw data, the "Jake Jones" gains are used by default. For each
+
When correcting raw data, the "Jake Jones" gains are used by default. For each
flavour, the first item in the parentheses (e.g. cotter2014) indicates what
should be supplied to hyperdrive if you want to use those gains instead. There
-is also a none "flavour" if you want to disable PFB gain correction.
+is also a none "flavour" if you want to disable PFB gain correction.
In CHJ's experience, using different flavours have very little effect on
calibration quality.
Some more information on the PFB can be found
here.
-
+
Each tile is connected by a cable, and that cable might have a different length
to others. This correction aims to better align the signals of each tile.
-
+
todo!()
diff --git a/defs/mwa/dead_dipoles.html b/defs/mwa/dead_dipoles.html
index 75e3453b..0c140dff 100644
--- a/defs/mwa/dead_dipoles.html
+++ b/defs/mwa/dead_dipoles.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,16 +149,16 @@ mwa_hyperdrive documentation
Dead dipoles
-Each MWA tile has 16 "bowties", and each bowtie is made up of two dipoles (one
-X, one Y). We refer to a "dead" dipole as one that is not functioning correctly
+
Each MWA tile has 16 "bowties", and each bowtie is made up of two dipoles (one
+X, one Y). We refer to a "dead" dipole as one that is not functioning correctly
(hopefully not receiving any power at all). This information is used in
generating beam responses as part of modelling visibilities. The more accurate
the visibilities, the better that calibration performs, so it is important to
account for dead dipoles if possible.
Beam responses are generated with
hyperbeam and dead dipole
-information is encoded as a "dipole gain" of 1 ("alive") or 0 ("dead"). It is
-possible to supply other values for dipole gains with a "DipAmps" column; see
+information is encoded as a "dipole gain" of 1 ("alive") or 0 ("dead"). It is
+possible to supply other values for dipole gains with a "DipAmps" column; see
the metafits page.
For the relevant functions, dead dipole information can be ignored by supplying
a flag --unity-dipole-gains. This sets all dipole gains to 1.
@@ -166,8 +167,8 @@ Dead dipolesSee this
page for
more info on dipole ordering.
-
In the image below, you can see the 12th Y dipole is dead for "Tile022". All
-other dipoles are "alive".
+In the image below, you can see the 12th Y dipole is dead for "Tile022". All
+other dipoles are "alive".
diff --git a/defs/mwa/delays.html b/defs/mwa/delays.html
index 693c33da..d08c827b 100644
--- a/defs/mwa/delays.html
+++ b/defs/mwa/delays.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,7 +149,7 @@ mwa_hyperdrive documentation
Dipole delays
-A tile's dipole delays control where it is "pointing". Delays are provided as
+
A tile's dipole delays control where it is "pointing". Delays are provided as
numbers, and this controls how long a dipole's response is delayed before its
response correlated with other dipoles. This effectively allows the MWA to be
more sensitive in a particular direction without any physical movement.
@@ -168,8 +169,8 @@ Dipole delays
would correspond to the example above. Note that these user-supplied delays will
override delays that are otherwise provided.
-Dipoles cannot be delayed by more than "31". "32" is code for "dead
-dipole", which means that these dipoles should not be used
+
Dipoles cannot be delayed by more than "31". "32" is code for "dead
+dipole", which means that these dipoles should not be used
when modelling a tile's response.
Ideal dipole delays
Most (all?) MWA observations use a single set of delays for all tiles. Dipole
@@ -178,10 +179,10 @@
Ideal
The delays in HDU 1 are referred to as "ideal" dipole delays. A set of delays
-are not ideal if any are "32" (i.e. dead).
-However, the HDU 1 delays may all be "32". This is an indication from the
-observatory that this observation is "bad" and should not be used. hyperdrive
+
The delays in HDU 1 are referred to as "ideal" dipole delays. A set of delays
+are not ideal if any are "32" (i.e. dead).
+However, the HDU 1 delays may all be "32". This is an indication from the
+observatory that this observation is "bad" and should not be used. hyperdrive
will proceed with such observations but issue a warning. In this case, the ideal
delays are obtained by iterating over all tile delays until each delay is not
32.
diff --git a/defs/mwa/metafits.html b/defs/mwa/metafits.html
index dfda8050..b019910a 100644
--- a/defs/mwa/metafits.html
+++ b/defs/mwa/metafits.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,25 +149,29 @@ mwa_hyperdrive documentation
Metafits files
-The MWA tracks observation metadata with "metafits" files. Often these accompany
-the raw visibilities in a download, but these could be old (such as the "PPD
-metafits" files). hyperdrive does not support PPD metafits files; only new
+The MWA tracks observation metadata with "metafits" files. Often these accompany
+the raw visibilities in a download, but these could be old (such as the "PPD
+metafits" files). hyperdrive does not support PPD metafits files; only new
metafits files should be used.
This command downloads a new metafits file for the specified observation ID:
-
+
-OBSID=1090008640; wget "http://ws.mwatelescope.org/metadata/fits?obs_id=${OBSID}" -O "${OBSID}".metafits
+OBSID=1090008640; wget "http://ws.mwatelescope.org/metadata/fits?obs_id=${OBSID}" -O "${OBSID}".metafits
-
+
Measurement sets and uvfits files do not contain MWA-specific information,
@@ -175,10 +180,12 @@
Metafits files<
uvfits file may also lack dipole delay information.
-
+
The database of MWA metadata can change over time for observations conducted
@@ -191,11 +198,11 @@
Metafits files<
Controlling dipole gains
-If the "TILEDATA" HDU of a metafits contains a "DipAmps" column, each row
+
If the "TILEDATA" HDU of a metafits contains a "DipAmps" column, each row
containing 16 double-precision values for bowties in the M&C order, these are
-used as the dipole gains in beam calculations. If the "DipAmps" column isn't
+used as the dipole gains in beam calculations. If the "DipAmps" column isn't
available, the default behaviour is to use gains of 1.0 for all dipoles, except
-those that have delays of 32 in the "Delays" column (they will have a gain of
+those that have delays of 32 in the "Delays" column (they will have a gain of
0.0, and are considered dead).
diff --git a/defs/mwa/mwaf.html b/defs/mwa/mwaf.html
index 54eb2f70..c3e15aa5 100644
--- a/defs/mwa/mwaf.html
+++ b/defs/mwa/mwaf.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -157,10 +158,12 @@ mwaf flag fil
At the time of writing, hyperdrive only utilises mwaf files when reading
visibilities from raw data.
-
+
cotter-produced mwaf files are unreliable because
diff --git a/defs/mwa/mwalib.html b/defs/mwa/mwalib.html
index ca12b618..ba400ada 100644
--- a/defs/mwa/mwalib.html
+++ b/defs/mwa/mwalib.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,7 +152,7 @@ mwalib
mwalib is the official MWA
raw-data-reading library. hyperdrive users usually don't need to concern
themselves with it, but mwalib errors may arise.
-mwalib can be quite noisy with log messages (particularly at the "trace"
+
mwalib can be quite noisy with log messages (particularly at the "trace"
level); it is possible to suppress these messages by setting an environment
variable:
RUST_LOG=mwalib=error
diff --git a/defs/mwa/picket_fence.html b/defs/mwa/picket_fence.html
index 46b8fc38..619d33b5 100644
--- a/defs/mwa/picket_fence.html
+++ b/defs/mwa/picket_fence.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,8 +149,8 @@ mwa_hyperdrive documentation
Picket fence observations
-A "picket fence" observation contains more than one "spectral window" (or
-"SPW"). That is, not all the frequency channels in an observation are
+
A "picket fence" observation contains more than one "spectral window" (or
+"SPW"). That is, not all the frequency channels in an observation are
continuous; there's at least one gap somewhere.
hyperdrive does not currently support picket fence observations, but it will
eventually support them properly. However, it is possible to calibrate a
diff --git a/defs/pols.html b/defs/pols.html
index f7fc334a..2c72e000 100644
--- a/defs/pols.html
+++ b/defs/pols.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/defs/source_list_ao.html b/defs/source_list_ao.html
index b3d758d6..483e5510 100644
--- a/defs/source_list_ao.html
+++ b/defs/source_list_ao.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -157,20 +158,22 @@
Source names are allowed to have spaces inside them, because the names are
surrounded by quotes. This is fine for reading, but when converting one of these
sources to another format, the spaces need to be translated to underscores.
-
+
skymodel fileformat 1.1
source {
- name "J002549-260211"
+ name "J002549-260211"
component {
type point
position 0h25m49.2s -26d02m13s
@@ -185,7 +188,7 @@
+
@@ -83,7 +84,7 @@
@@ -161,10 +162,12 @@
+
The following are the contents of a valid YAML file. super_sweet_source1 is a
@@ -224,10 +227,12 @@
+
The following are the contents of a valid JSON file. super_sweet_source1 is a
@@ -235,79 +240,79 @@
{
- "super_sweet_source1": [
+ "super_sweet_source1": [
{
- "ra": 10.0,
- "dec": -27.0,
- "comp_type": "point",
- "flux_type": {
- "list": [
+ "ra": 10.0,
+ "dec": -27.0,
+ "comp_type": "point",
+ "flux_type": {
+ "list": [
{
- "freq": 150000000.0,
- "i": 10.0
+ "freq": 150000000.0,
+ "i": 10.0
},
{
- "freq": 170000000.0,
- "i": 5.0,
- "q": 1.0,
- "u": 2.0,
- "v": 3.0
+ "freq": 170000000.0,
+ "i": 5.0,
+ "q": 1.0,
+ "u": 2.0,
+ "v": 3.0
}
]
}
}
],
- "super_sweet_source2": [
+ "super_sweet_source2": [
{
- "ra": 0.0,
- "dec": -35.0,
- "comp_type": {
- "gaussian": {
- "maj": 20.0,
- "min": 10.0,
- "pa": 75.0
+ "ra": 0.0,
+ "dec": -35.0,
+ "comp_type": {
+ "gaussian": {
+ "maj": 20.0,
+ "min": 10.0,
+ "pa": 75.0
}
},
- "flux_type": {
- "power_law": {
- "si": -0.8,
- "fd": {
- "freq": 170000000.0,
- "i": 5.0,
- "q": 1.0,
- "u": 2.0,
- "v": 3.0
+ "flux_type": {
+ "power_law": {
+ "si": -0.8,
+ "fd": {
+ "freq": 170000000.0,
+ "i": 5.0,
+ "q": 1.0,
+ "u": 2.0,
+ "v": 3.0
}
}
}
},
{
- "ra": 155.0,
- "dec": -10.0,
- "comp_type": {
- "shapelet": {
- "maj": 20.0,
- "min": 10.0,
- "pa": 75.0,
- "coeffs": [
+ "ra": 155.0,
+ "dec": -10.0,
+ "comp_type": {
+ "shapelet": {
+ "maj": 20.0,
+ "min": 10.0,
+ "pa": 75.0,
+ "coeffs": [
{
- "n1": 0,
- "n2": 1,
- "value": 0.5
+ "n1": 0,
+ "n2": 1,
+ "value": 0.5
}
]
}
},
- "flux_type": {
- "curved_power_law": {
- "si": -0.6,
- "fd": {
- "freq": 150000000.0,
- "i": 50.0,
- "q": 0.5,
- "u": 0.1
+ "flux_type": {
+ "curved_power_law": {
+ "si": -0.6,
+ "fd": {
+ "freq": 150000000.0,
+ "i": 50.0,
+ "q": 0.5,
+ "u": 0.1
},
- "q": 0.2
+ "q": 0.2
}
}
}
diff --git a/defs/source_list_rts.html b/defs/source_list_rts.html
index b8bf038f..e27111c8 100644
--- a/defs/source_list_rts.html
+++ b/defs/source_list_rts.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -155,16 +156,18 @@
Keywords like SOURCE, COMPONENT, POINT etc. must be at the start of a line
(i.e. no preceding space).
-RTS sources always have a "base source", which can be thought of as a
+
RTS sources always have a "base source", which can be thought of as a
non-optional component or the first component in a collection of components.
-
+
Taken from srclists, file
diff --git a/defs/source_lists.html b/defs/source_lists.html
index e8a7f824..0869d501 100644
--- a/defs/source_lists.html
+++ b/defs/source_lists.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -160,13 +161,15 @@
-hyperdrive can also convert between formats, although in a "lossy" way;
+
hyperdrive can also convert between formats, although in a "lossy" way;
non-hyperdrive formats cannot represent all component and/or flux-density
types.
-
+
-
+
-
+
-
+
Each component in a sky model is represented in one of three ways:
@@ -216,7 +225,7 @@ Point sources are the simplest. Gaussian sources could be considered the same as
point sources, but have details on their structure (major- and minor-axes,
position angle). Finally, shapelets are described the same way as Gaussians but
-additionally have multiple "shapelet components". Examples of each of these
+additionally have multiple "shapelet components". Examples of each of these
components can be found on the following documentation pages and in the examples
directory.
diff --git a/defs/vis_formats_read.html b/defs/vis_formats_read.html
index 58b50cad..4d68cae4 100644
--- a/defs/vis_formats_read.html
+++ b/defs/vis_formats_read.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,13 +149,15 @@ mwa_hyperdrive documentation
Supported visibility formats for reading
-
+
-Raw "legacy" MWA data comes in "gpubox" files. "MWAX" data comes in a similar
+
Raw "legacy" MWA data comes in "gpubox" files. "MWAX" data comes in a similar
format, and *ch???*.fits is a useful glob to identify them. Raw data can be
accessed from the ASVO.
Here are examples of using each of these MWA formats with di-calibrate:
@@ -167,10 +170,12 @@
+
hyperdrive di-calibrate -d *.ms *.metafits -s a_good_sky_model.yaml
@@ -186,10 +191,12 @@ below for more info.
-
+
hyperdrive di-calibrate -d *.uvfits *.metafits -s a_good_sky_model.yaml
@@ -203,10 +210,12 @@ here.
-
+
When using a metafits file with a uvfits/MS, the tile names in the metafits and
diff --git a/defs/vis_formats_write.html b/defs/vis_formats_write.html
index cb03f383..791676b5 100644
--- a/defs/vis_formats_write.html
+++ b/defs/vis_formats_write.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -152,10 +153,12 @@
+
hyperdrive solutions-apply \
@@ -165,10 +168,12 @@
+
hyperdrive solutions-apply \
@@ -180,10 +185,12 @@ here.
-
+
When writing out visibilities, they can be averaged in time and frequency. Units
@@ -210,10 +217,12 @@
+
All aspects of hyperdrive that can write visibilities can write to multiple
diff --git a/dev/ndarray.html b/dev/ndarray.html
index 200f6a88..bd24651f 100644
--- a/dev/ndarray.html
+++ b/dev/ndarray.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/dev/vec1.html b/dev/vec1.html
index 8c4d286f..4d92ab93 100644
--- a/dev/vec1.html
+++ b/dev/vec1.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/index.html b/index.html
index 333d1b6e..7a6cef95 100644
--- a/index.html
+++ b/index.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/installation/from_source.html b/installation/from_source.html
index 50c1b2ce..d3588bef 100644
--- a/installation/from_source.html
+++ b/installation/from_source.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -150,10 +151,12 @@
mwa_hyperdrive documentation
Installing hyperdrive from source code
Dependencies
hyperdrive depends on these C libraries:
-
+
@@ -173,10 +176,12 @@ Dependencies
-
+
@@ -196,10 +201,12 @@ Dependencies
Optional dependencies
-
+
@@ -213,10 +220,12 @@ O
-
+
@@ -233,10 +242,12 @@ O
-
+
@@ -261,10 +272,12 @@ O
Installing Rust
-
+
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
@@ -289,20 +302,24 @@
+
It is possible to compile with more optimisations if you give --profile production to the cargo install command. This may make things a few percent
faster, but compilation will take much longer.
-
+
Do you have a CUDA-capable NVIDIA GPU? Ensure you have installed
@@ -316,8 +333,8 @@
cargo install --path . --locked --features=cuda,gpu-single
-If you're using "datacentre" products (e.g. a V100 available on the
-Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
+
If you're using "datacentre" products (e.g. a V100 available on the
+Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
floats:
cargo install --path . --locked --features=cuda
@@ -329,17 +346,19 @@
+
Do you have a HIP-capable AMD GPU? Ensure you have installed HIP (instructions
are above), and compile with the hip feature (single-precision floats):
cargo install --path . --locked --features=hip,gpu-single
-If you're using "datacentre" products (e.g. the GPUs on the "setonix"
+
If you're using "datacentre" products (e.g. the GPUs on the "setonix"
supercomputer), you probably want double-precision floats:
cargo install --path . --locked --features=hip
@@ -348,10 +367,12 @@
+
The aforementioned C libraries can each be compiled by cargo. all-static
@@ -361,10 +382,12 @@
+
cargo features can be chained in a comma-separated list:
@@ -372,10 +395,12 @@
+
If you're having problems compiling, it's possible you have an older Rust
@@ -390,10 +415,12 @@
+
hyperdrive used to depend on the ERFA C
diff --git a/installation/intro.html b/installation/intro.html
index b0b865d9..a99a3ea0 100644
--- a/installation/intro.html
+++ b/installation/intro.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/installation/post.html b/installation/post.html
index 9189312c..63af0d1c 100644
--- a/installation/post.html
+++ b/installation/post.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,10 +149,12 @@
mwa_hyperdrive documentation
Post installation instructions
-
+
Many hyperdrive functions require the beam code to function. The MWA FEE beam
diff --git a/installation/pre_compiled.html b/installation/pre_compiled.html
index 136226e5..d6f12e5c 100644
--- a/installation/pre_compiled.html
+++ b/installation/pre_compiled.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,30 +152,32 @@
Visit the GitHub releases page. You should see releases like the following:
-
If you intend on running hyperdrive on a desktop GPU, then you probably want
-the "CUDA-single" release. You can still use the double-precision version on a
+the "CUDA-single" release. You can still use the double-precision version on a
desktop GPU, but it will be much slower than single-precision. Instructions to
install CUDA are on the next page.
It is possible to run hyperdrive with HIP (i.e. the AMD equivalent to
NVIDIA's CUDA), but HIP does not appear to offer static libraries, so no static
feature is provided, and users will need to compile hyperdrive themselves with
instructions on the next page.
-
+
The pre-compiled binaries are made by GitHub actions using:
cargo build --release --locked --no-default-features --features=hdf5-static,cfitsio-static
This means they cannot plot calibration solutions.
-"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
+"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
the cuda and gpu-single features. CUDA cannot legally be statically linked
so a local installation of CUDA is required.
diff --git a/mdbook-admonish.css b/mdbook-admonish.css
new file mode 100644
index 00000000..45aeff05
--- /dev/null
+++ b/mdbook-admonish.css
@@ -0,0 +1,348 @@
+@charset "UTF-8";
+:is(.admonition) {
+ display: flow-root;
+ margin: 1.5625em 0;
+ padding: 0 1.2rem;
+ color: var(--fg);
+ page-break-inside: avoid;
+ background-color: var(--bg);
+ border: 0 solid black;
+ border-inline-start-width: 0.4rem;
+ border-radius: 0.2rem;
+ box-shadow: 0 0.2rem 1rem rgba(0, 0, 0, 0.05), 0 0 0.1rem rgba(0, 0, 0, 0.1);
+}
+@media print {
+ :is(.admonition) {
+ box-shadow: none;
+ }
+}
+:is(.admonition) > * {
+ box-sizing: border-box;
+}
+:is(.admonition) :is(.admonition) {
+ margin-top: 1em;
+ margin-bottom: 1em;
+}
+:is(.admonition) > .tabbed-set:only-child {
+ margin-top: 0;
+}
+html :is(.admonition) > :last-child {
+ margin-bottom: 1.2rem;
+}
+
+a.admonition-anchor-link {
+ display: none;
+ position: absolute;
+ left: -1.2rem;
+ padding-right: 1rem;
+}
+a.admonition-anchor-link:link, a.admonition-anchor-link:visited {
+ color: var(--fg);
+}
+a.admonition-anchor-link:link:hover, a.admonition-anchor-link:visited:hover {
+ text-decoration: none;
+}
+a.admonition-anchor-link::before {
+ content: "§";
+}
+
+:is(.admonition-title, summary.admonition-title) {
+ position: relative;
+ min-height: 4rem;
+ margin-block: 0;
+ margin-inline: -1.6rem -1.2rem;
+ padding-block: 0.8rem;
+ padding-inline: 4.4rem 1.2rem;
+ font-weight: 700;
+ background-color: rgba(68, 138, 255, 0.1);
+ print-color-adjust: exact;
+ -webkit-print-color-adjust: exact;
+ display: flex;
+}
+:is(.admonition-title, summary.admonition-title) p {
+ margin: 0;
+}
+html :is(.admonition-title, summary.admonition-title):last-child {
+ margin-bottom: 0;
+}
+:is(.admonition-title, summary.admonition-title)::before {
+ position: absolute;
+ top: 0.625em;
+ inset-inline-start: 1.6rem;
+ width: 2rem;
+ height: 2rem;
+ background-color: #448aff;
+ print-color-adjust: exact;
+ -webkit-print-color-adjust: exact;
+ mask-image: url('data:image/svg+xml;charset=utf-8,');
+ -webkit-mask-image: url('data:image/svg+xml;charset=utf-8,');
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-size: contain;
+ content: "";
+}
+:is(.admonition-title, summary.admonition-title):hover a.admonition-anchor-link {
+ display: initial;
+}
+
+details.admonition > summary.admonition-title::after {
+ position: absolute;
+ top: 0.625em;
+ inset-inline-end: 1.6rem;
+ height: 2rem;
+ width: 2rem;
+ background-color: currentcolor;
+ mask-image: var(--md-details-icon);
+ -webkit-mask-image: var(--md-details-icon);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-size: contain;
+ content: "";
+ transform: rotate(0deg);
+ transition: transform 0.25s;
+}
+details[open].admonition > summary.admonition-title::after {
+ transform: rotate(90deg);
+}
+
+:root {
+ --md-details-icon: url("data:image/svg+xml;charset=utf-8,");
+}
+
+:root {
+ --md-admonition-icon--admonish-note: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-abstract: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-info: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-tip: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-success: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-question: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-warning: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-failure: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-danger: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-bug: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-example: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-quote: url("data:image/svg+xml;charset=utf-8,");
+}
+
+:is(.admonition):is(.admonish-note) {
+ border-color: #448aff;
+}
+
+:is(.admonish-note) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(68, 138, 255, 0.1);
+}
+:is(.admonish-note) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #448aff;
+ mask-image: var(--md-admonition-icon--admonish-note);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-note);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-abstract, .admonish-summary, .admonish-tldr) {
+ border-color: #00b0ff;
+}
+
+:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 176, 255, 0.1);
+}
+:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00b0ff;
+ mask-image: var(--md-admonition-icon--admonish-abstract);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-abstract);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-info, .admonish-todo) {
+ border-color: #00b8d4;
+}
+
+:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 184, 212, 0.1);
+}
+:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00b8d4;
+ mask-image: var(--md-admonition-icon--admonish-info);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-info);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-tip, .admonish-hint, .admonish-important) {
+ border-color: #00bfa5;
+}
+
+:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 191, 165, 0.1);
+}
+:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00bfa5;
+ mask-image: var(--md-admonition-icon--admonish-tip);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-tip);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-success, .admonish-check, .admonish-done) {
+ border-color: #00c853;
+}
+
+:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 200, 83, 0.1);
+}
+:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00c853;
+ mask-image: var(--md-admonition-icon--admonish-success);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-success);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-question, .admonish-help, .admonish-faq) {
+ border-color: #64dd17;
+}
+
+:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(100, 221, 23, 0.1);
+}
+:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #64dd17;
+ mask-image: var(--md-admonition-icon--admonish-question);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-question);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-warning, .admonish-caution, .admonish-attention) {
+ border-color: #ff9100;
+}
+
+:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 145, 0, 0.1);
+}
+:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff9100;
+ mask-image: var(--md-admonition-icon--admonish-warning);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-warning);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-failure, .admonish-fail, .admonish-missing) {
+ border-color: #ff5252;
+}
+
+:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 82, 82, 0.1);
+}
+:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff5252;
+ mask-image: var(--md-admonition-icon--admonish-failure);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-failure);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-danger, .admonish-error) {
+ border-color: #ff1744;
+}
+
+:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 23, 68, 0.1);
+}
+:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff1744;
+ mask-image: var(--md-admonition-icon--admonish-danger);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-danger);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-bug) {
+ border-color: #f50057;
+}
+
+:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(245, 0, 87, 0.1);
+}
+:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #f50057;
+ mask-image: var(--md-admonition-icon--admonish-bug);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-bug);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-example) {
+ border-color: #7c4dff;
+}
+
+:is(.admonish-example) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(124, 77, 255, 0.1);
+}
+:is(.admonish-example) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #7c4dff;
+ mask-image: var(--md-admonition-icon--admonish-example);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-example);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-quote, .admonish-cite) {
+ border-color: #9e9e9e;
+}
+
+:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(158, 158, 158, 0.1);
+}
+:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #9e9e9e;
+ mask-image: var(--md-admonition-icon--admonish-quote);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-quote);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+.navy :is(.admonition) {
+ background-color: var(--sidebar-bg);
+}
+
+.ayu :is(.admonition),
+.coal :is(.admonition) {
+ background-color: var(--theme-hover);
+}
+
+.rust :is(.admonition) {
+ background-color: var(--sidebar-bg);
+ color: var(--sidebar-fg);
+}
+.rust .admonition-anchor-link:link, .rust .admonition-anchor-link:visited {
+ color: var(--sidebar-fg);
+}
diff --git a/print.html b/print.html
index 930def8f..f5e1e13d 100644
--- a/print.html
+++ b/print.html
@@ -31,6 +31,7 @@
+
@@ -84,7 +85,7 @@
@@ -189,30 +190,32 @@ IntroductionVisit the GitHub releases page. You should see releases like the following:
-
If you intend on running hyperdrive on a desktop GPU, then you probably want
-the "CUDA-single" release. You can still use the double-precision version on a
+the "CUDA-single" release. You can still use the double-precision version on a
desktop GPU, but it will be much slower than single-precision. Instructions to
install CUDA are on the next page.
It is possible to run hyperdrive with HIP (i.e. the AMD equivalent to
NVIDIA's CUDA), but HIP does not appear to offer static libraries, so no static
feature is provided, and users will need to compile hyperdrive themselves with
instructions on the next page.
-
+
The pre-compiled binaries are made by GitHub actions using:
cargo build --release --locked --no-default-features --features=hdf5-static,cfitsio-static
This means they cannot plot calibration solutions.
-"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
+"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
the cuda and gpu-single features. CUDA cannot legally be statically linked
so a local installation of CUDA is required.
@@ -220,10 +223,12 @@ Introduction
Installing hyperdrive from source code
Dependencies
hyperdrive depends on these C libraries:
-
+
@@ -243,10 +248,12 @@ Dependencies
-
+
@@ -266,10 +273,12 @@ Dependencies
Optional dependencies
-
+
@@ -283,10 +292,12 @@ O
-
+
@@ -303,10 +314,12 @@ O
-
+
@@ -331,10 +344,12 @@ O
Installing Rust
-
+
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
@@ -359,20 +374,24 @@
+
It is possible to compile with more optimisations if you give --profile production to the cargo install command. This may make things a few percent
faster, but compilation will take much longer.
-
+
Do you have a CUDA-capable NVIDIA GPU? Ensure you have installed
@@ -386,8 +405,8 @@
cargo install --path . --locked --features=cuda,gpu-single
-If you're using "datacentre" products (e.g. a V100 available on the
-Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
+
If you're using "datacentre" products (e.g. a V100 available on the
+Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
floats:
cargo install --path . --locked --features=cuda
@@ -399,17 +418,19 @@
+
Do you have a HIP-capable AMD GPU? Ensure you have installed HIP (instructions
are above), and compile with the hip feature (single-precision floats):
cargo install --path . --locked --features=hip,gpu-single
-If you're using "datacentre" products (e.g. the GPUs on the "setonix"
+
If you're using "datacentre" products (e.g. the GPUs on the "setonix"
supercomputer), you probably want double-precision floats:
cargo install --path . --locked --features=hip
@@ -418,10 +439,12 @@
+
The aforementioned C libraries can each be compiled by cargo. all-static
@@ -431,10 +454,12 @@
+
cargo features can be chained in a comma-separated list:
@@ -442,10 +467,12 @@
+
If you're having problems compiling, it's possible you have an older Rust
@@ -460,10 +487,12 @@
+
hyperdrive used to depend on the ERFA C
@@ -471,10 +500,12 @@
Post installation instructions
-
+
Many hyperdrive functions require the beam code to function. The MWA FEE beam
@@ -512,10 +543,12 @@
+
hyperdrive itself is split into many subcommands. These are simple to list:
@@ -537,7 +570,7 @@ hyperdrive-solutions-plot 0.2.0-alpha.11
-Plot calibration solutions. Only available if compiled with the "plotting" feature.
+Plot calibration solutions. Only available if compiled with the "plotting" feature.
USAGE:
hyperdrive solutions-plot [OPTIONS] [SOLUTIONS_FILES]...
@@ -558,16 +591,18 @@
+
It's possible to save keystrokes when subcommands aren't ambiguous, e.g. use
solutions-p as an alias for solutions-plot:
hyperdrive solutions-p
-<help text for "solutions-plot">
+<help text for "solutions-plot">
This works because there is no other subcommand that solutions-p could refer
to. On the other hand, solutions won't be accepted because both
@@ -577,8 +612,8 @@
DI calibration
-Direction-Independent (DI) calibration "corrects" raw telescope data.
-hyperdrive achieves this with "sky model calibration". This can work very
+
Direction-Independent (DI) calibration "corrects" raw telescope data.
+hyperdrive achieves this with "sky model calibration". This can work very
well, but relies on two key assumptions:
Install hyperdrive if you haven't already.
-
+
Feel free to try your own data, but test data is available in the hyperdrive
@@ -633,10 +670,12 @@
+
It's very important to use a sky model that corresponds to the data you're
@@ -646,10 +685,12 @@
+
We're going to run the di-calibrate subcommand of hyperdrive. If you look at
@@ -659,10 +700,12 @@
+
The above command can be more neatly expressed as:
@@ -675,10 +718,12 @@
+
The command we ran in step 3 should give us information on the input data, the
@@ -700,16 +745,18 @@
+
-A "chanblock" is a frequency unit of calibration;
+
A "chanblock" is a frequency unit of calibration;
it may correspond to one or many channels of the input data.
-Calibration is done iteratively; it iterates until the "stop threshold" is
-reached, or up to a set number of times. The "stop" and "minimum" thresholds
+
Calibration is done iteratively; it iterates until the "stop threshold" is
+reached, or up to a set number of times. The "stop" and "minimum" thresholds
are used during convergence. If the stop threshold is reached before the maximum
number of iterations, we say that the chanblock has converged well enough that
we can stop iterating. However, if we reach the maximum number of iterations,
@@ -725,7 +772,7 @@
@@ -733,10 +780,12 @@
+
hyperdrive solutions-convert /path/to/rts/solutions/ rts-as-hyp-solutions.fits -m /path/to/obs.metafits
@@ -167,10 +170,12 @@
+
I (CHJ) spent a very long time trying to make the writing of RTS solutions
diff --git a/defs/coords.html b/defs/coords.html
index 94c67111..14163012 100644
--- a/defs/coords.html
+++ b/defs/coords.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -152,38 +153,38 @@
ITRF
-frame (internally we refer to this as "geocentric XYZ"). There's also a
-"geodetic XYZ" frame; an example of this is WGS
+frame (internally we refer to this as "geocentric XYZ"). There's also a
+"geodetic XYZ" frame; an example of this is WGS
84 (which we assume
everywhere when converting, as it's the current best ellipsoid). Finally,
-there's also an "East North Height" coordinate system.
+there's also an "East North Height" coordinate system.
To calculate UVW baseline coordinates, geodetic XYZ coordinates are
required1. Therefore, various coordinate conversions are required to obtain
UVWs. The conversion between all of these systems is briefly described below.
The relevant code lives within Marlu.
-ITRF and "geocentric XYZ"
+ITRF and "geocentric XYZ"
As the name implies, this coordinate system uses the centre of the Earth as a
reference. To convert between geocentric and geodetic, an array position is
-required (i.e. the "average" location on the Earth of the instrument collecting
+required (i.e. the "average" location on the Earth of the instrument collecting
visibilities). When all antenna positions are geocentric, the array position is
given by the mean antenna position.
-Measurement sets indicate the usage of ITRF with the "MEASURE_REFERENCE" keyword
-attached to the POSITION column of an ANTENNA table (value "ITRF").
+Measurement sets indicate the usage of ITRF with the "MEASURE_REFERENCE" keyword
+attached to the POSITION column of an ANTENNA table (value "ITRF").
The uvfits
standard states
-that only supported frame is "ITRF", and hyperdrive assumes that only ITRF is
+that only supported frame is "ITRF", and hyperdrive assumes that only ITRF is
used. However, CASA/casacore seem to write out antenna positions incorrectly;
the positions look like what you would find in an equivalent measurement set.
The incorrect behaviour is detected and accounted for.
-"Geodetic XYZ"
+"Geodetic XYZ"
This coordinate system is similar to geocentric, but uses an array position as
its reference.
-Measurement sets support the WGS 84 frame, again with the "MEASURE_REFERENCE"
-keyword attached to the POSITION column of an ANTENNA table (value "WGS84").
+
Measurement sets support the WGS 84 frame, again with the "MEASURE_REFERENCE"
+keyword attached to the POSITION column of an ANTENNA table (value "WGS84").
However, hyperdrive currently does not check if geodetic positions are used;
it instead just assumes geocentric.
-When read literally, the antenna positions in a uvfits file ("STABXYZ" column of
-the "AIPS AN" HDU) should be geodetic, not counting the aforementioned
+
When read literally, the antenna positions in a uvfits file ("STABXYZ" column of
+the "AIPS AN" HDU) should be geodetic, not counting the aforementioned
casacore bug.
East North Height (ENH)
MWA tiles positions are listed in metafits files with
@@ -232,7 +233,7 @@
UVWs
Note that this is a UVW coordinate for an antenna. To get the proper baseline
UVW, a difference between two antennas' UVWs needs to be taken. The order of
-this subtraction is important; hyperdrive uses the "antenna1 - antenna2"
+this subtraction is important; hyperdrive uses the "antenna1 - antenna2"
convention. Software that reads data may need to conjugate visibilities if this
convention is different.
Further reading
diff --git a/defs/dut1.html b/defs/dut1.html
index 0006932b..47c222da 100644
--- a/defs/dut1.html
+++ b/defs/dut1.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -164,7 +165,7 @@ More explan
A lot of good, easy-to-read information is
here.
UTC keeps track with TAI but only through the aid of leap seconds (both are
-"atomic time frames"). UT1 is the "actual time", but the Earth's rate of
+"atomic time frames"). UT1 is the "actual time", but the Earth's rate of
rotation is difficult to measure and predict. DUT1 is not allowed to be more
than -0.9 or 0.9 seconds; a leap second is introduced before that threshold is
reached.
diff --git a/defs/fd_types.html b/defs/fd_types.html
index a5a7ea67..15b68099 100644
--- a/defs/fd_types.html
+++ b/defs/fd_types.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,10 +152,12 @@ Flux-de
This page describes supported flux-density types within hyperdrive. The
following pages detail their usage within sky-model source lists. This
page details how each type is estimated in modelling.
-
+
Most astrophysical sources are modelled as power laws. These are simply
@@ -163,16 +166,18 @@
Flux-de
spectral index \( \alpha \).
Curved power laws are formalised in Section 4.1 of Callingham et al.
2017. These are
-the same as power laws but with an additional "spectral curvature" parameter \(
+the same as power laws but with an additional "spectral curvature" parameter \(
q \).
Both kinds of power law flux-density representations are preferred in
hyperdrive.
-
+
The list type is simply many instances of a Stokes \( \text{I} \), \(
diff --git a/defs/modelling/estimating.html b/defs/modelling/estimating.html
index f60bd4eb..66a9a755 100644
--- a/defs/modelling/estimating.html
+++ b/defs/modelling/estimating.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -155,10 +156,12 @@
+
Both power-law and curved-power-law sources have a spectral index (\( \alpha
@@ -199,13 +202,15 @@
+
-When estimating flux densities from a list, it is feared that the "jagged" shape
+
When estimating flux densities from a list, it is feared that the "jagged" shape
of a component's spectral energy distribution introduces artefacts into an EoR
power spectrum.
It is relatively expensive to estimate flux densities from a list type. For all
diff --git a/defs/modelling/intro.html b/defs/modelling/intro.html
index 7129a089..ca482fa2 100644
--- a/defs/modelling/intro.html
+++ b/defs/modelling/intro.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/defs/modelling/rime.html b/defs/modelling/rime.html
index e2470068..e0799f3d 100644
--- a/defs/modelling/rime.html
+++ b/defs/modelling/rime.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,10 +149,12 @@
mwa_hyperdrive documentation
Measurement equation
-
+
A lot of this content was taken from Jack Line's
diff --git a/defs/mwa/corrections.html b/defs/mwa/corrections.html
index 1f5a7233..2c7bd4ab 100644
--- a/defs/mwa/corrections.html
+++ b/defs/mwa/corrections.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,16 +149,18 @@ mwa_hyperdrive documentation
Raw data corrections
-A number of things can be done to "correct" or "pre-process" raw MWA data before
+
A number of things can be done to "correct" or "pre-process" raw MWA data before
it is ready for calibration (or other analysis). These tasks are handled by
Birli, either as the Birli
executable itself, or internally in hyperdrive.
cotter used to perform these tasks
but it has been superseded by Birli.
-
+
Many MWA observations do not apply a geometric correction despite having a
@@ -168,44 +171,50 @@
Raw
on calibration!
-
+
The poly-phase filter bank used by the MWA affects visibilities before they get
-saved to disk. Over time, a number of "flavours" of these gains have been used:
+saved to disk. Over time, a number of "flavours" of these gains have been used:
-
-When correcting raw data, the "Jake Jones" gains are used by default. For each
+
When correcting raw data, the "Jake Jones" gains are used by default. For each
flavour, the first item in the parentheses (e.g. cotter2014) indicates what
should be supplied to hyperdrive if you want to use those gains instead. There
-is also a none "flavour" if you want to disable PFB gain correction.
+is also a none "flavour" if you want to disable PFB gain correction.
In CHJ's experience, using different flavours have very little effect on
calibration quality.
Some more information on the PFB can be found
here.
-
+
Each tile is connected by a cable, and that cable might have a different length
to others. This correction aims to better align the signals of each tile.
-
+
todo!()
diff --git a/defs/mwa/dead_dipoles.html b/defs/mwa/dead_dipoles.html
index 75e3453b..0c140dff 100644
--- a/defs/mwa/dead_dipoles.html
+++ b/defs/mwa/dead_dipoles.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,16 +149,16 @@ mwa_hyperdrive documentation
Dead dipoles
-Each MWA tile has 16 "bowties", and each bowtie is made up of two dipoles (one
-X, one Y). We refer to a "dead" dipole as one that is not functioning correctly
+
Each MWA tile has 16 "bowties", and each bowtie is made up of two dipoles (one
+X, one Y). We refer to a "dead" dipole as one that is not functioning correctly
(hopefully not receiving any power at all). This information is used in
generating beam responses as part of modelling visibilities. The more accurate
the visibilities, the better that calibration performs, so it is important to
account for dead dipoles if possible.
Beam responses are generated with
hyperbeam and dead dipole
-information is encoded as a "dipole gain" of 1 ("alive") or 0 ("dead"). It is
-possible to supply other values for dipole gains with a "DipAmps" column; see
+information is encoded as a "dipole gain" of 1 ("alive") or 0 ("dead"). It is
+possible to supply other values for dipole gains with a "DipAmps" column; see
the metafits page.
For the relevant functions, dead dipole information can be ignored by supplying
a flag --unity-dipole-gains. This sets all dipole gains to 1.
@@ -166,8 +167,8 @@ Dead dipolesSee this
page for
more info on dipole ordering.
-
In the image below, you can see the 12th Y dipole is dead for "Tile022". All
-other dipoles are "alive".
+In the image below, you can see the 12th Y dipole is dead for "Tile022". All
+other dipoles are "alive".
diff --git a/defs/mwa/delays.html b/defs/mwa/delays.html
index 693c33da..d08c827b 100644
--- a/defs/mwa/delays.html
+++ b/defs/mwa/delays.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,7 +149,7 @@ mwa_hyperdrive documentation
Dipole delays
-A tile's dipole delays control where it is "pointing". Delays are provided as
+
A tile's dipole delays control where it is "pointing". Delays are provided as
numbers, and this controls how long a dipole's response is delayed before its
response correlated with other dipoles. This effectively allows the MWA to be
more sensitive in a particular direction without any physical movement.
@@ -168,8 +169,8 @@ Dipole delays
would correspond to the example above. Note that these user-supplied delays will
override delays that are otherwise provided.
-Dipoles cannot be delayed by more than "31". "32" is code for "dead
-dipole", which means that these dipoles should not be used
+
Dipoles cannot be delayed by more than "31". "32" is code for "dead
+dipole", which means that these dipoles should not be used
when modelling a tile's response.
Ideal dipole delays
Most (all?) MWA observations use a single set of delays for all tiles. Dipole
@@ -178,10 +179,10 @@
Ideal
The delays in HDU 1 are referred to as "ideal" dipole delays. A set of delays
-are not ideal if any are "32" (i.e. dead).
-However, the HDU 1 delays may all be "32". This is an indication from the
-observatory that this observation is "bad" and should not be used. hyperdrive
+
The delays in HDU 1 are referred to as "ideal" dipole delays. A set of delays
+are not ideal if any are "32" (i.e. dead).
+However, the HDU 1 delays may all be "32". This is an indication from the
+observatory that this observation is "bad" and should not be used. hyperdrive
will proceed with such observations but issue a warning. In this case, the ideal
delays are obtained by iterating over all tile delays until each delay is not
32.
diff --git a/defs/mwa/metafits.html b/defs/mwa/metafits.html
index dfda8050..b019910a 100644
--- a/defs/mwa/metafits.html
+++ b/defs/mwa/metafits.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,25 +149,29 @@ mwa_hyperdrive documentation
Metafits files
-The MWA tracks observation metadata with "metafits" files. Often these accompany
-the raw visibilities in a download, but these could be old (such as the "PPD
-metafits" files). hyperdrive does not support PPD metafits files; only new
+The MWA tracks observation metadata with "metafits" files. Often these accompany
+the raw visibilities in a download, but these could be old (such as the "PPD
+metafits" files). hyperdrive does not support PPD metafits files; only new
metafits files should be used.
This command downloads a new metafits file for the specified observation ID:
-
+
-OBSID=1090008640; wget "http://ws.mwatelescope.org/metadata/fits?obs_id=${OBSID}" -O "${OBSID}".metafits
+OBSID=1090008640; wget "http://ws.mwatelescope.org/metadata/fits?obs_id=${OBSID}" -O "${OBSID}".metafits
-
+
Measurement sets and uvfits files do not contain MWA-specific information,
@@ -175,10 +180,12 @@
Metafits files<
uvfits file may also lack dipole delay information.
-
+
The database of MWA metadata can change over time for observations conducted
@@ -191,11 +198,11 @@
Metafits files<
Controlling dipole gains
-If the "TILEDATA" HDU of a metafits contains a "DipAmps" column, each row
+
If the "TILEDATA" HDU of a metafits contains a "DipAmps" column, each row
containing 16 double-precision values for bowties in the M&C order, these are
-used as the dipole gains in beam calculations. If the "DipAmps" column isn't
+used as the dipole gains in beam calculations. If the "DipAmps" column isn't
available, the default behaviour is to use gains of 1.0 for all dipoles, except
-those that have delays of 32 in the "Delays" column (they will have a gain of
+those that have delays of 32 in the "Delays" column (they will have a gain of
0.0, and are considered dead).
diff --git a/defs/mwa/mwaf.html b/defs/mwa/mwaf.html
index 54eb2f70..c3e15aa5 100644
--- a/defs/mwa/mwaf.html
+++ b/defs/mwa/mwaf.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -157,10 +158,12 @@ mwaf flag fil
At the time of writing, hyperdrive only utilises mwaf files when reading
visibilities from raw data.
-
+
cotter-produced mwaf files are unreliable because
diff --git a/defs/mwa/mwalib.html b/defs/mwa/mwalib.html
index ca12b618..ba400ada 100644
--- a/defs/mwa/mwalib.html
+++ b/defs/mwa/mwalib.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,7 +152,7 @@ mwalib
mwalib is the official MWA
raw-data-reading library. hyperdrive users usually don't need to concern
themselves with it, but mwalib errors may arise.
-mwalib can be quite noisy with log messages (particularly at the "trace"
+
mwalib can be quite noisy with log messages (particularly at the "trace"
level); it is possible to suppress these messages by setting an environment
variable:
RUST_LOG=mwalib=error
diff --git a/defs/mwa/picket_fence.html b/defs/mwa/picket_fence.html
index 46b8fc38..619d33b5 100644
--- a/defs/mwa/picket_fence.html
+++ b/defs/mwa/picket_fence.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,8 +149,8 @@ mwa_hyperdrive documentation
Picket fence observations
-A "picket fence" observation contains more than one "spectral window" (or
-"SPW"). That is, not all the frequency channels in an observation are
+
A "picket fence" observation contains more than one "spectral window" (or
+"SPW"). That is, not all the frequency channels in an observation are
continuous; there's at least one gap somewhere.
hyperdrive does not currently support picket fence observations, but it will
eventually support them properly. However, it is possible to calibrate a
diff --git a/defs/pols.html b/defs/pols.html
index f7fc334a..2c72e000 100644
--- a/defs/pols.html
+++ b/defs/pols.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/defs/source_list_ao.html b/defs/source_list_ao.html
index b3d758d6..483e5510 100644
--- a/defs/source_list_ao.html
+++ b/defs/source_list_ao.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -157,20 +158,22 @@
Source names are allowed to have spaces inside them, because the names are
surrounded by quotes. This is fine for reading, but when converting one of these
sources to another format, the spaces need to be translated to underscores.
-
+
skymodel fileformat 1.1
source {
- name "J002549-260211"
+ name "J002549-260211"
component {
type point
position 0h25m49.2s -26d02m13s
@@ -185,7 +188,7 @@
+
@@ -83,7 +84,7 @@
@@ -161,10 +162,12 @@
+
The following are the contents of a valid YAML file. super_sweet_source1 is a
@@ -224,10 +227,12 @@
+
The following are the contents of a valid JSON file. super_sweet_source1 is a
@@ -235,79 +240,79 @@
{
- "super_sweet_source1": [
+ "super_sweet_source1": [
{
- "ra": 10.0,
- "dec": -27.0,
- "comp_type": "point",
- "flux_type": {
- "list": [
+ "ra": 10.0,
+ "dec": -27.0,
+ "comp_type": "point",
+ "flux_type": {
+ "list": [
{
- "freq": 150000000.0,
- "i": 10.0
+ "freq": 150000000.0,
+ "i": 10.0
},
{
- "freq": 170000000.0,
- "i": 5.0,
- "q": 1.0,
- "u": 2.0,
- "v": 3.0
+ "freq": 170000000.0,
+ "i": 5.0,
+ "q": 1.0,
+ "u": 2.0,
+ "v": 3.0
}
]
}
}
],
- "super_sweet_source2": [
+ "super_sweet_source2": [
{
- "ra": 0.0,
- "dec": -35.0,
- "comp_type": {
- "gaussian": {
- "maj": 20.0,
- "min": 10.0,
- "pa": 75.0
+ "ra": 0.0,
+ "dec": -35.0,
+ "comp_type": {
+ "gaussian": {
+ "maj": 20.0,
+ "min": 10.0,
+ "pa": 75.0
}
},
- "flux_type": {
- "power_law": {
- "si": -0.8,
- "fd": {
- "freq": 170000000.0,
- "i": 5.0,
- "q": 1.0,
- "u": 2.0,
- "v": 3.0
+ "flux_type": {
+ "power_law": {
+ "si": -0.8,
+ "fd": {
+ "freq": 170000000.0,
+ "i": 5.0,
+ "q": 1.0,
+ "u": 2.0,
+ "v": 3.0
}
}
}
},
{
- "ra": 155.0,
- "dec": -10.0,
- "comp_type": {
- "shapelet": {
- "maj": 20.0,
- "min": 10.0,
- "pa": 75.0,
- "coeffs": [
+ "ra": 155.0,
+ "dec": -10.0,
+ "comp_type": {
+ "shapelet": {
+ "maj": 20.0,
+ "min": 10.0,
+ "pa": 75.0,
+ "coeffs": [
{
- "n1": 0,
- "n2": 1,
- "value": 0.5
+ "n1": 0,
+ "n2": 1,
+ "value": 0.5
}
]
}
},
- "flux_type": {
- "curved_power_law": {
- "si": -0.6,
- "fd": {
- "freq": 150000000.0,
- "i": 50.0,
- "q": 0.5,
- "u": 0.1
+ "flux_type": {
+ "curved_power_law": {
+ "si": -0.6,
+ "fd": {
+ "freq": 150000000.0,
+ "i": 50.0,
+ "q": 0.5,
+ "u": 0.1
},
- "q": 0.2
+ "q": 0.2
}
}
}
diff --git a/defs/source_list_rts.html b/defs/source_list_rts.html
index b8bf038f..e27111c8 100644
--- a/defs/source_list_rts.html
+++ b/defs/source_list_rts.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -155,16 +156,18 @@
Keywords like SOURCE, COMPONENT, POINT etc. must be at the start of a line
(i.e. no preceding space).
-RTS sources always have a "base source", which can be thought of as a
+
RTS sources always have a "base source", which can be thought of as a
non-optional component or the first component in a collection of components.
-
+
Taken from srclists, file
diff --git a/defs/source_lists.html b/defs/source_lists.html
index e8a7f824..0869d501 100644
--- a/defs/source_lists.html
+++ b/defs/source_lists.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -160,13 +161,15 @@
-hyperdrive can also convert between formats, although in a "lossy" way;
+
hyperdrive can also convert between formats, although in a "lossy" way;
non-hyperdrive formats cannot represent all component and/or flux-density
types.
-
+
-
+
-
+
-
+
Each component in a sky model is represented in one of three ways:
@@ -216,7 +225,7 @@ Point sources are the simplest. Gaussian sources could be considered the same as
point sources, but have details on their structure (major- and minor-axes,
position angle). Finally, shapelets are described the same way as Gaussians but
-additionally have multiple "shapelet components". Examples of each of these
+additionally have multiple "shapelet components". Examples of each of these
components can be found on the following documentation pages and in the examples
directory.
diff --git a/defs/vis_formats_read.html b/defs/vis_formats_read.html
index 58b50cad..4d68cae4 100644
--- a/defs/vis_formats_read.html
+++ b/defs/vis_formats_read.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,13 +149,15 @@ mwa_hyperdrive documentation
Supported visibility formats for reading
-
+
-Raw "legacy" MWA data comes in "gpubox" files. "MWAX" data comes in a similar
+
Raw "legacy" MWA data comes in "gpubox" files. "MWAX" data comes in a similar
format, and *ch???*.fits is a useful glob to identify them. Raw data can be
accessed from the ASVO.
Here are examples of using each of these MWA formats with di-calibrate:
@@ -167,10 +170,12 @@
+
hyperdrive di-calibrate -d *.ms *.metafits -s a_good_sky_model.yaml
@@ -186,10 +191,12 @@ below for more info.
-
+
hyperdrive di-calibrate -d *.uvfits *.metafits -s a_good_sky_model.yaml
@@ -203,10 +210,12 @@ here.
-
+
When using a metafits file with a uvfits/MS, the tile names in the metafits and
diff --git a/defs/vis_formats_write.html b/defs/vis_formats_write.html
index cb03f383..791676b5 100644
--- a/defs/vis_formats_write.html
+++ b/defs/vis_formats_write.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -152,10 +153,12 @@
+
hyperdrive solutions-apply \
@@ -165,10 +168,12 @@
+
hyperdrive solutions-apply \
@@ -180,10 +185,12 @@ here.
-
+
When writing out visibilities, they can be averaged in time and frequency. Units
@@ -210,10 +217,12 @@
+
All aspects of hyperdrive that can write visibilities can write to multiple
diff --git a/dev/ndarray.html b/dev/ndarray.html
index 200f6a88..bd24651f 100644
--- a/dev/ndarray.html
+++ b/dev/ndarray.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/dev/vec1.html b/dev/vec1.html
index 8c4d286f..4d92ab93 100644
--- a/dev/vec1.html
+++ b/dev/vec1.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/index.html b/index.html
index 333d1b6e..7a6cef95 100644
--- a/index.html
+++ b/index.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/installation/from_source.html b/installation/from_source.html
index 50c1b2ce..d3588bef 100644
--- a/installation/from_source.html
+++ b/installation/from_source.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -150,10 +151,12 @@
mwa_hyperdrive documentation
Installing hyperdrive from source code
Dependencies
hyperdrive depends on these C libraries:
-
+
@@ -173,10 +176,12 @@ Dependencies
-
+
@@ -196,10 +201,12 @@ Dependencies
Optional dependencies
-
+
@@ -213,10 +220,12 @@ O
-
+
@@ -233,10 +242,12 @@ O
-
+
@@ -261,10 +272,12 @@ O
Installing Rust
-
+
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
@@ -289,20 +302,24 @@
+
It is possible to compile with more optimisations if you give --profile production to the cargo install command. This may make things a few percent
faster, but compilation will take much longer.
-
+
Do you have a CUDA-capable NVIDIA GPU? Ensure you have installed
@@ -316,8 +333,8 @@
cargo install --path . --locked --features=cuda,gpu-single
-If you're using "datacentre" products (e.g. a V100 available on the
-Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
+
If you're using "datacentre" products (e.g. a V100 available on the
+Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
floats:
cargo install --path . --locked --features=cuda
@@ -329,17 +346,19 @@
+
Do you have a HIP-capable AMD GPU? Ensure you have installed HIP (instructions
are above), and compile with the hip feature (single-precision floats):
cargo install --path . --locked --features=hip,gpu-single
-If you're using "datacentre" products (e.g. the GPUs on the "setonix"
+
If you're using "datacentre" products (e.g. the GPUs on the "setonix"
supercomputer), you probably want double-precision floats:
cargo install --path . --locked --features=hip
@@ -348,10 +367,12 @@
+
The aforementioned C libraries can each be compiled by cargo. all-static
@@ -361,10 +382,12 @@
+
cargo features can be chained in a comma-separated list:
@@ -372,10 +395,12 @@
+
If you're having problems compiling, it's possible you have an older Rust
@@ -390,10 +415,12 @@
+
hyperdrive used to depend on the ERFA C
diff --git a/installation/intro.html b/installation/intro.html
index b0b865d9..a99a3ea0 100644
--- a/installation/intro.html
+++ b/installation/intro.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
diff --git a/installation/post.html b/installation/post.html
index 9189312c..63af0d1c 100644
--- a/installation/post.html
+++ b/installation/post.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -148,10 +149,12 @@
mwa_hyperdrive documentation
Post installation instructions
-
+
Many hyperdrive functions require the beam code to function. The MWA FEE beam
diff --git a/installation/pre_compiled.html b/installation/pre_compiled.html
index 136226e5..d6f12e5c 100644
--- a/installation/pre_compiled.html
+++ b/installation/pre_compiled.html
@@ -30,6 +30,7 @@
+
@@ -83,7 +84,7 @@
@@ -151,30 +152,32 @@
Visit the GitHub releases page. You should see releases like the following:
-
If you intend on running hyperdrive on a desktop GPU, then you probably want
-the "CUDA-single" release. You can still use the double-precision version on a
+the "CUDA-single" release. You can still use the double-precision version on a
desktop GPU, but it will be much slower than single-precision. Instructions to
install CUDA are on the next page.
It is possible to run hyperdrive with HIP (i.e. the AMD equivalent to
NVIDIA's CUDA), but HIP does not appear to offer static libraries, so no static
feature is provided, and users will need to compile hyperdrive themselves with
instructions on the next page.
-
+
The pre-compiled binaries are made by GitHub actions using:
cargo build --release --locked --no-default-features --features=hdf5-static,cfitsio-static
This means they cannot plot calibration solutions.
-"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
+"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
the cuda and gpu-single features. CUDA cannot legally be statically linked
so a local installation of CUDA is required.
diff --git a/mdbook-admonish.css b/mdbook-admonish.css
new file mode 100644
index 00000000..45aeff05
--- /dev/null
+++ b/mdbook-admonish.css
@@ -0,0 +1,348 @@
+@charset "UTF-8";
+:is(.admonition) {
+ display: flow-root;
+ margin: 1.5625em 0;
+ padding: 0 1.2rem;
+ color: var(--fg);
+ page-break-inside: avoid;
+ background-color: var(--bg);
+ border: 0 solid black;
+ border-inline-start-width: 0.4rem;
+ border-radius: 0.2rem;
+ box-shadow: 0 0.2rem 1rem rgba(0, 0, 0, 0.05), 0 0 0.1rem rgba(0, 0, 0, 0.1);
+}
+@media print {
+ :is(.admonition) {
+ box-shadow: none;
+ }
+}
+:is(.admonition) > * {
+ box-sizing: border-box;
+}
+:is(.admonition) :is(.admonition) {
+ margin-top: 1em;
+ margin-bottom: 1em;
+}
+:is(.admonition) > .tabbed-set:only-child {
+ margin-top: 0;
+}
+html :is(.admonition) > :last-child {
+ margin-bottom: 1.2rem;
+}
+
+a.admonition-anchor-link {
+ display: none;
+ position: absolute;
+ left: -1.2rem;
+ padding-right: 1rem;
+}
+a.admonition-anchor-link:link, a.admonition-anchor-link:visited {
+ color: var(--fg);
+}
+a.admonition-anchor-link:link:hover, a.admonition-anchor-link:visited:hover {
+ text-decoration: none;
+}
+a.admonition-anchor-link::before {
+ content: "§";
+}
+
+:is(.admonition-title, summary.admonition-title) {
+ position: relative;
+ min-height: 4rem;
+ margin-block: 0;
+ margin-inline: -1.6rem -1.2rem;
+ padding-block: 0.8rem;
+ padding-inline: 4.4rem 1.2rem;
+ font-weight: 700;
+ background-color: rgba(68, 138, 255, 0.1);
+ print-color-adjust: exact;
+ -webkit-print-color-adjust: exact;
+ display: flex;
+}
+:is(.admonition-title, summary.admonition-title) p {
+ margin: 0;
+}
+html :is(.admonition-title, summary.admonition-title):last-child {
+ margin-bottom: 0;
+}
+:is(.admonition-title, summary.admonition-title)::before {
+ position: absolute;
+ top: 0.625em;
+ inset-inline-start: 1.6rem;
+ width: 2rem;
+ height: 2rem;
+ background-color: #448aff;
+ print-color-adjust: exact;
+ -webkit-print-color-adjust: exact;
+ mask-image: url('data:image/svg+xml;charset=utf-8,');
+ -webkit-mask-image: url('data:image/svg+xml;charset=utf-8,');
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-size: contain;
+ content: "";
+}
+:is(.admonition-title, summary.admonition-title):hover a.admonition-anchor-link {
+ display: initial;
+}
+
+details.admonition > summary.admonition-title::after {
+ position: absolute;
+ top: 0.625em;
+ inset-inline-end: 1.6rem;
+ height: 2rem;
+ width: 2rem;
+ background-color: currentcolor;
+ mask-image: var(--md-details-icon);
+ -webkit-mask-image: var(--md-details-icon);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-size: contain;
+ content: "";
+ transform: rotate(0deg);
+ transition: transform 0.25s;
+}
+details[open].admonition > summary.admonition-title::after {
+ transform: rotate(90deg);
+}
+
+:root {
+ --md-details-icon: url("data:image/svg+xml;charset=utf-8,");
+}
+
+:root {
+ --md-admonition-icon--admonish-note: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-abstract: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-info: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-tip: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-success: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-question: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-warning: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-failure: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-danger: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-bug: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-example: url("data:image/svg+xml;charset=utf-8,");
+ --md-admonition-icon--admonish-quote: url("data:image/svg+xml;charset=utf-8,");
+}
+
+:is(.admonition):is(.admonish-note) {
+ border-color: #448aff;
+}
+
+:is(.admonish-note) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(68, 138, 255, 0.1);
+}
+:is(.admonish-note) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #448aff;
+ mask-image: var(--md-admonition-icon--admonish-note);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-note);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-abstract, .admonish-summary, .admonish-tldr) {
+ border-color: #00b0ff;
+}
+
+:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 176, 255, 0.1);
+}
+:is(.admonish-abstract, .admonish-summary, .admonish-tldr) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00b0ff;
+ mask-image: var(--md-admonition-icon--admonish-abstract);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-abstract);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-info, .admonish-todo) {
+ border-color: #00b8d4;
+}
+
+:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 184, 212, 0.1);
+}
+:is(.admonish-info, .admonish-todo) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00b8d4;
+ mask-image: var(--md-admonition-icon--admonish-info);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-info);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-tip, .admonish-hint, .admonish-important) {
+ border-color: #00bfa5;
+}
+
+:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 191, 165, 0.1);
+}
+:is(.admonish-tip, .admonish-hint, .admonish-important) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00bfa5;
+ mask-image: var(--md-admonition-icon--admonish-tip);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-tip);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-success, .admonish-check, .admonish-done) {
+ border-color: #00c853;
+}
+
+:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(0, 200, 83, 0.1);
+}
+:is(.admonish-success, .admonish-check, .admonish-done) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #00c853;
+ mask-image: var(--md-admonition-icon--admonish-success);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-success);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-question, .admonish-help, .admonish-faq) {
+ border-color: #64dd17;
+}
+
+:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(100, 221, 23, 0.1);
+}
+:is(.admonish-question, .admonish-help, .admonish-faq) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #64dd17;
+ mask-image: var(--md-admonition-icon--admonish-question);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-question);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-warning, .admonish-caution, .admonish-attention) {
+ border-color: #ff9100;
+}
+
+:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 145, 0, 0.1);
+}
+:is(.admonish-warning, .admonish-caution, .admonish-attention) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff9100;
+ mask-image: var(--md-admonition-icon--admonish-warning);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-warning);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-failure, .admonish-fail, .admonish-missing) {
+ border-color: #ff5252;
+}
+
+:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 82, 82, 0.1);
+}
+:is(.admonish-failure, .admonish-fail, .admonish-missing) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff5252;
+ mask-image: var(--md-admonition-icon--admonish-failure);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-failure);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-danger, .admonish-error) {
+ border-color: #ff1744;
+}
+
+:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(255, 23, 68, 0.1);
+}
+:is(.admonish-danger, .admonish-error) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #ff1744;
+ mask-image: var(--md-admonition-icon--admonish-danger);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-danger);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-bug) {
+ border-color: #f50057;
+}
+
+:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(245, 0, 87, 0.1);
+}
+:is(.admonish-bug) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #f50057;
+ mask-image: var(--md-admonition-icon--admonish-bug);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-bug);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-example) {
+ border-color: #7c4dff;
+}
+
+:is(.admonish-example) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(124, 77, 255, 0.1);
+}
+:is(.admonish-example) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #7c4dff;
+ mask-image: var(--md-admonition-icon--admonish-example);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-example);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+:is(.admonition):is(.admonish-quote, .admonish-cite) {
+ border-color: #9e9e9e;
+}
+
+:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title) {
+ background-color: rgba(158, 158, 158, 0.1);
+}
+:is(.admonish-quote, .admonish-cite) > :is(.admonition-title, summary.admonition-title)::before {
+ background-color: #9e9e9e;
+ mask-image: var(--md-admonition-icon--admonish-quote);
+ -webkit-mask-image: var(--md-admonition-icon--admonish-quote);
+ mask-repeat: no-repeat;
+ -webkit-mask-repeat: no-repeat;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+}
+
+.navy :is(.admonition) {
+ background-color: var(--sidebar-bg);
+}
+
+.ayu :is(.admonition),
+.coal :is(.admonition) {
+ background-color: var(--theme-hover);
+}
+
+.rust :is(.admonition) {
+ background-color: var(--sidebar-bg);
+ color: var(--sidebar-fg);
+}
+.rust .admonition-anchor-link:link, .rust .admonition-anchor-link:visited {
+ color: var(--sidebar-fg);
+}
diff --git a/print.html b/print.html
index 930def8f..f5e1e13d 100644
--- a/print.html
+++ b/print.html
@@ -31,6 +31,7 @@
+
@@ -84,7 +85,7 @@
@@ -189,30 +190,32 @@ IntroductionVisit the GitHub releases page. You should see releases like the following:
-
If you intend on running hyperdrive on a desktop GPU, then you probably want
-the "CUDA-single" release. You can still use the double-precision version on a
+the "CUDA-single" release. You can still use the double-precision version on a
desktop GPU, but it will be much slower than single-precision. Instructions to
install CUDA are on the next page.
It is possible to run hyperdrive with HIP (i.e. the AMD equivalent to
NVIDIA's CUDA), but HIP does not appear to offer static libraries, so no static
feature is provided, and users will need to compile hyperdrive themselves with
instructions on the next page.
-
+
The pre-compiled binaries are made by GitHub actions using:
cargo build --release --locked --no-default-features --features=hdf5-static,cfitsio-static
This means they cannot plot calibration solutions.
-"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
+"CUDA-double" binaries have the cuda feature and "CUDA-single" binaries have
the cuda and gpu-single features. CUDA cannot legally be statically linked
so a local installation of CUDA is required.
@@ -220,10 +223,12 @@ Introduction
Installing hyperdrive from source code
Dependencies
hyperdrive depends on these C libraries:
-
+
@@ -243,10 +248,12 @@ Dependencies
-
+
@@ -266,10 +273,12 @@ Dependencies
Optional dependencies
-
+
@@ -283,10 +292,12 @@ O
-
+
@@ -303,10 +314,12 @@ O
-
+
@@ -331,10 +344,12 @@ O
Installing Rust
-
+
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
@@ -359,20 +374,24 @@
+
It is possible to compile with more optimisations if you give --profile production to the cargo install command. This may make things a few percent
faster, but compilation will take much longer.
-
+
Do you have a CUDA-capable NVIDIA GPU? Ensure you have installed
@@ -386,8 +405,8 @@
cargo install --path . --locked --features=cuda,gpu-single
-If you're using "datacentre" products (e.g. a V100 available on the
-Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
+
If you're using "datacentre" products (e.g. a V100 available on the
+Pawsey-hosted supercomputer "garrawarla"), you probably want double-precision
floats:
cargo install --path . --locked --features=cuda
@@ -399,17 +418,19 @@
+
Do you have a HIP-capable AMD GPU? Ensure you have installed HIP (instructions
are above), and compile with the hip feature (single-precision floats):
cargo install --path . --locked --features=hip,gpu-single
-If you're using "datacentre" products (e.g. the GPUs on the "setonix"
+
If you're using "datacentre" products (e.g. the GPUs on the "setonix"
supercomputer), you probably want double-precision floats:
cargo install --path . --locked --features=hip
@@ -418,10 +439,12 @@
+
The aforementioned C libraries can each be compiled by cargo. all-static
@@ -431,10 +454,12 @@
+
cargo features can be chained in a comma-separated list:
@@ -442,10 +467,12 @@
+
If you're having problems compiling, it's possible you have an older Rust
@@ -460,10 +487,12 @@
+
hyperdrive used to depend on the ERFA C
@@ -471,10 +500,12 @@
Post installation instructions
-
+
Many hyperdrive functions require the beam code to function. The MWA FEE beam
@@ -512,10 +543,12 @@
+
hyperdrive itself is split into many subcommands. These are simple to list:
@@ -537,7 +570,7 @@ hyperdrive-solutions-plot 0.2.0-alpha.11
-Plot calibration solutions. Only available if compiled with the "plotting" feature.
+Plot calibration solutions. Only available if compiled with the "plotting" feature.
USAGE:
hyperdrive solutions-plot [OPTIONS] [SOLUTIONS_FILES]...
@@ -558,16 +591,18 @@
+
It's possible to save keystrokes when subcommands aren't ambiguous, e.g. use
solutions-p as an alias for solutions-plot:
hyperdrive solutions-p
-<help text for "solutions-plot">
+<help text for "solutions-plot">
This works because there is no other subcommand that solutions-p could refer
to. On the other hand, solutions won't be accepted because both
@@ -577,8 +612,8 @@
DI calibration
-Direction-Independent (DI) calibration "corrects" raw telescope data.
-hyperdrive achieves this with "sky model calibration". This can work very
+
Direction-Independent (DI) calibration "corrects" raw telescope data.
+hyperdrive achieves this with "sky model calibration". This can work very
well, but relies on two key assumptions:
Install hyperdrive if you haven't already.
-
+
Feel free to try your own data, but test data is available in the hyperdrive
@@ -633,10 +670,12 @@
+
It's very important to use a sky model that corresponds to the data you're
@@ -646,10 +685,12 @@
+
We're going to run the di-calibrate subcommand of hyperdrive. If you look at
@@ -659,10 +700,12 @@
+
The above command can be more neatly expressed as:
@@ -675,10 +718,12 @@
+
The command we ran in step 3 should give us information on the input data, the
@@ -700,16 +745,18 @@
+
-A "chanblock" is a frequency unit of calibration;
+
A "chanblock" is a frequency unit of calibration;
it may correspond to one or many channels of the input data.
-Calibration is done iteratively; it iterates until the "stop threshold" is
-reached, or up to a set number of times. The "stop" and "minimum" thresholds
+
Calibration is done iteratively; it iterates until the "stop threshold" is
+reached, or up to a set number of times. The "stop" and "minimum" thresholds
are used during convergence. If the stop threshold is reached before the maximum
number of iterations, we say that the chanblock has converged well enough that
we can stop iterating. However, if we reach the maximum number of iterations,
@@ -725,7 +772,7 @@
@@ -733,10 +780,12 @@
+