Wed, 01/06/2021 - 07:24
I want to present and recommend the new software, Peranso 3. This is the most complete variable star analysis program and also it's easy to use. I used Peranso 2.6 in the last 3 years, but the last update allows direct ZTF data importing, faster analysis and a lot more. You should download and try the trial version available at https://www.cbabelgium.com/peranso/ . In the future, i can even do a tutorial for people who want to learn it assisted. If you have any questions about it, please ask.
Does anyone have an experience with Peranso 3, specifically with TESS data?
I currently have Peranso 3 (with an expired registration key though, I purchased it slightly more than a year ago, so I cannot ask the support directly; Peranso says, however, that I can continue using it).
The question is about how TESS data is transformed while importing them directly from the Internet.
The manual says that “the time of a TESS observation is expressed in the TESS Barycentric Julian Day (BTJD), this is a Julian day minus 2457000.0 and corrected to the arrival times at the barycenter of the solar system. Upon importing the observations in an ObsWin, Peranso converts the time from BTJD to (Geocentric) Julian Day.”
However, if I compare the times (presumably in JD) of the downloaded TESS light curve with the values that I convert from TESS BJD_TDB into JD using Time Utility of the Ohio State University (https://astroutils.astronomy.osu.edu/time/bjd2utc.html) I see the difference of about 72s.
I also tested the time conversion using AstroImageJ Coordinate converter tool: the results are almost the same as the Time Utility of the Ohio State University gives and again differ from Peranso’s ones.
Can anybody shed light on this?
Another question is about the magnitude. While importing data, Peranso shows the median magnitude of the dataset to be imported. However, after the import, the median magnitude of the dataset differs significantly.
The tests were performed using Kepler-12 variable. Peranso version = 22.214.171.124
P.S. From my point of view, transforming times from BJD_TDB into JD without an option to keep the original values is a bad idea.
I'm no expert but I believe the discrepancy is due to the fact that TESS observation times are in barycentric time--based on Terrestrial Time (TT) whereas the online Time Utility you mentioned requires input times in Barycentric Dynamical Time (BJD_TDB).
The late, great, Dr Bob Nelson told me in an email early last year that "TESS data (which is in barycentric time--based on Terrestrial Time (TT) but with a maximum bc correction of ± maximum 4.6 seconds I think it is). UTC lags TT by 69.184 seconds, so subtract 69 seconds. Ignore the bc correction, as we cannot find that easily (or so I believe) and it doesn't matter, in practical terms." This was in relation to comparing TESS Times of Minima with my own observations of an eclipsing binary. The bc (barycentric correction) may be important for your research.
There are several time systems and it can be difficult to understand how they relate. I hope that helps a little. Cheers,
I've inspected the TESS header of the binary table extension of a TESS FITS and found:
TIMESYS = 'TDB ' / time system is Barycentric Dynamical Time (TDB)
It seems that TESS uses BJD_TDB after all.
P.S. See also this page: https://heasarc.gsfc.nasa.gov/docs/tess/Target-Pixel-File-Tutorial.html
"By default, time is in the TESS Barycentric Julian Day (BTJD), this is a Julian day minus 2457000.0 and corrected to the arrival times at the barycenter of the Solar System. BTJD is the format in which times are recorded in the TESS data products. The time is in the Barycentric Dynamical Time frame (TDB), which is a time system that is not affected by leap seconds, see the TESS Science Data Products Description Document for more details."
sorry for my unintended misdirection, thanks for clearing that up.
Still, your original question remains. So, even though your licence has expired, I would suggest emailing Tony Vanmunster directly. Then please post to this forum what you find out. Cheers,
I just did it via his AAVSO contact. Let's wait for the answer.
I had a look at this in a different way.
I determined the time of mid eclipse (by polynomial fit) from the light curve of the EB CY Hyi in VStar using the TESS plugin. The minimum chosen was the first in the TESS dataset commencing on 25 July 2018.
The BJD_TDB from VStar for the time of mid eclipse was 2458325.35291. I converted this to JD in the utility at:
The result was JD 2458325.350703955
The JD for the time of mid eclipse from Peranso was 2458325.351472.
The Peranso JD was 0.000768 d or 66.4 s later than the time of mid eclipse determined in VStar.
I do this sort of thing all the time. For the precise light curves from TESS, there is no way that two determinations of the time of mid eclipse from VStar and Peranso from a polynomial fit could yield such disparate results.
Note added in edit: for those who want to check part of the above the position of CY Hyi is:
03 06 17.3 -68 12 29.7
Thank you for the comment, Roy. The utility you used (https://astroutils.astronomy.osu.edu/time/bjd2utc.html) is from the same set of online utilities I've mentioned in my post.
As soon as VStar does nothing with times while loading the data (you can easily check it using any FITS viewer that is able to show binary tables, for example, a FITS viewer from NASA), the question about the correctness of the Peranso conversion still remains.
P.S. By the way, my interest in the topic arose from the comparison of the times of the minima in my observations of V405 Dra with TESS ones. When I transformed my data to BJD_TDB, the positions of my minima were in good agreement with TESS ones (in this case, the forms of the light curves in the TESS and V filters are somewhat different, so we must take shape into account)
In my case the uncertainty re Peranso JD times trom TESS data is an annoyance because it puts on hold a project I had in mind for members of my local astromomy club who want to become involved in variable star research but may not wish to become involved in photometry.
Peranso should have been a good tool for the project because it is available to anyone at a modest cost and has a simpe routine for downloading TESS light curves. TESS data can be analysed in VStar, but it is (rightly) only available freely to AAVSO members.
Roy, VStar is free for everybody! Everybody can download the installation (Windows, Linux, MacOS). Moreover, as far as I am responsible for the Windows installer, I can always made a fresh installation of the development version which can be even better than the 'stable' one. The TESS plug-in is also partially my work.
That's good to know. I was sure that I had read somewhere in the past that VStar was available free to AAVSO members. I had assumed the statement implied exclusivity.
I and many others are very grateful to David, you and others who have created VStar.
I'm Max, not Pat :)
You may have been thinking about the APASS and AAVSO plugins that require authentication as a member.
Everything else about VStar is free.
ps - you're welcome, and thanks for the thanks to all of us :)
Not sure exactly how I developed this misapprehension, particularly since I've been with the AAVSO for some years. It's clear in the general information re VStar. I guess when I read I concentrate on the details I need re using VStar, including updating and accessing plugins.
did you receive a response from Tony Vanmunster about the time conversion of TESS observations? Cheers,
I wrote him also directly and got an answer (on Jan 21):
"Thanks for informing about this issue. We will look into it and as soon as there’s more information, we will let you know"
Nothing more unfortunately
I eventually got an answer from Tonny:
>>I have pleasure informing you that Peranso 126.96.36.199 has just been released and now correctly handles leap seconds.
I've tested the new version, and now the discrepancy between Peranso's converter and the online converter https://astroutils.astronomy.osu.edu/time/bjd2utc.html is less than 1 second.
Many thanks for your initiatives in this issue.