Collaboration diagram for SFTfileIO:
|
Files | |
| file | SFTutils.h |
|
| |
| file | SFTutils.c |
|
| |
| file | SFTfileIO.h |
| |
| file | SFTfileIO.c |
|
| |
| file | SFTfileIOTest.c |
|
| |
Prix, B. Machenschalk, A.M. Sintes, B. Krishnan
The basic operation of reading SFTs from files proceeds in two simple steps:
Note 1: currently supported SFT file-formats are (merged or single) SFT-v1 and SFT-v2 files. This might be extended in the future to support further file-formats (frames?). None of the following API depends on the details of the underlying file-format. This will ensure that codes using the following functions will NOT have to be changed irrespective of SFT file-format used.
Note 2: irrespective of the underlying SFT file-format, the returned SFTs (SFTVector) will ALWAYS be normalized according the the LAL-specification for frequency-series (LIGO-T010095-00), that is the pure DFT of the time-series
is multiplied by the time-step
:
LALSFTdataFind(LALStatus *, SFTCatalog **catalog, const CHAR *file_pattern, SFTConstraints *constraints);
This function returns an SFTCatalog of matching SFTs for a given file-pattern (e.g. "SFT.*", "SFT.000", "/some/path/some_files_[0-9]?.sft", etc ) and additional, optional SFTConstraints.
The optional constraints are:
Note 1: Any constraint can be specified as NULL, all given constraints will be combined by logical AND.
Note 2: if a timestamps-list is given, *ALL* timestamps within [startTime, endTime] MUST be found!]
Note 3: LALSFTdataFind() will refuse to return any SFTs without their detector-name properly set. This applies only to v1-SFTs, for which you have to use constraints->detector, so that the detector-name gets properly set.
Note 4: One special constraint->detector is "??", which acts as if constraints->detector==NULL, except that it allows v1-SFTs to be returned with detector-name set to "??"'.
The returned SFTCatalog is a vector of 'SFTDescriptor's describing one SFT, with the fields
locator: an opaque data-type describing where to read this SFT from.header: the SFts headercomment: the comment-string found in the SFT, if anynumBins: the number of frequency-bins in the SFTversion: version-number of SFT file-formatcrc64: the crc64 checksum reported by this SFTOne can use the following catalog-handling API functions:
NOTE: The SFTs in the returned catalogue are guaranteed to
LALLoadSFTs ( LALStatus *, SFTVector **sfts, const SFTCatalog *catalog, REAL8 fMin, REAL8 fMax);
This function takes an SFTCatalog and reads the smallest frequency-band containing [fMin, fMax] from the SFTs, returning the resulting SFTVector. Note that this function will return an error if the SFTCatalog contains SFTs from different detectors, for which LALLoadMultiSFTs() must be used.
The frequency-bounds are optional and -1 can be used to specify an 'open bound', i.e.
[-1, fMax]: read from first frequency-bin in the SFT up to fMax.
[fMin, -1]: read from fMin up to last frequency-bin in the SFTS
[-1, -1]: read ALL frequency-bins from SFT.
LALLoadMultiSFTs ( LALStatus *, MultiSFTVector **sfts, const SFTCatalog *catalog, REAL8 fMin, REAL8 fMax);
This function is similar to the above, except that it accepts an SFTCatalog with different detectors, and returns corresponding multi-IFO vector of SFTVectors.
For writing SFTs there are two functions, depending on the desired output-format (v1 or v2 SFTs):
LIGO-T040164-01-Z).
Note: in addition to these two function which take properly normalized SFTs as input, there is a DEPRECATED legacy-function, LALWriteSFTfile(), which writes an v1-SFT file, but *without* changing the data-normalization, i.e. this will only be correct for v1-normalized data (i.e. data = DFT)
1.5.2