2
$\begingroup$

I'm following this and downloading & displaying the TESS image file in matplotlib. That works great.

Now I'm trying to write myself a wrapper that allows me to specify in some config files what I want to get from that repo, & process them iteratively. In order to build a sensible/flexible structure, I need to better understand the syntax/naming convention. For instance, let's consider the first curl url for the calibrated FFIs for sector 43:

If I break down the naming:

  • tess2021259224859: datetime in format yyyyddmhhmmss ?
  • -s0043: sector in format sXXXXX
  • -2: camera number?
  • -2: ccd number?
  • -0214: ??
  • -s_ffic: s? ffic = full frame image calibrated?

I'd like to better understand this in order to be able to parametrize the query urls in my application.

$\endgroup$
0

1 Answer 1

3
$\begingroup$

The TESS file format is described in Section 2.1 of the TESS Science Data Products Description Document (data at the major archives such as MAST, IPAC/NEXSci or PDS should always have one of these data product documents that describe the data format, contents and issues or gotchas and so they are well worth hunting down first). That section breaks down and explains the format for all the TESS data products, not just the Full Frame Images. For the _ffic files, which you correctly guessed are calibrated fullframe images, we have (quotes from the document in quotation marks):

tess<yyyydddhhmmss>-s<sctr>-<cam>-<ccd>-<scid>-<cr>_ffic.fits.gz where:

  • <yyyydddhhmmss> is an UTC timestamp which Section 2.4.1 says "is usually the start of the spacecraft pointing time".
  • <sctr> is indeed the sector number (with a s prefix), which "is a 4 digit zero-padded integer indicating the sector in which the data were collected"
  • <cam> is a single digit that camera number which can be "1", "2", "3", or "4".
  • <ccd>, is a single digit that identifies CCD chip and can also be one of "1", "2", "3", or "4".
  • <scid> "is a four digit zero padded identifier of the spacecraft configuration map used to process this data." (I wouldn't worry about this one, it probably only means something to the engineers...)
  • <cr>, refers to the cosmic ray mitigation performed. Quoting "The value of this file name parameter will be 'x' if no mitigation at the SPOC (Science Processing Operations Center) was performed, 's' when mitigation was performed on the spacecraft, the value will be 'a' to indicate that a SPOC mitigation algorithm was used, and 'b' to indicate that both the SPOC algorithm and the the spacecraft algorithm was used."

The other possible data types such as the target pixel data, light curves etc are also described in the Table 1. The document then goes onto to describe each product in more detail, starting with Full Frame Images in Section 3.

$\endgroup$
2
  • $\begingroup$ Ah yes those documents seems to be the thing indeed. I'm really more of a CS background, seems like the way docs/references as organized/presented differ between the 2 worlds. Didn'ht happen onto those (or missed their role/significance). Thanks. $\endgroup$
    – Francky_V
    Commented Dec 16, 2021 at 16:58
  • $\begingroup$ I think both worlds hate doing documentation, just the ones with the publicly-funded mission data don't get to skip completing the docs... ;-) $\endgroup$ Commented Dec 16, 2021 at 17:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .