![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F651278%2F970175570a252e08679b56e80ccfc330%2FScreenshot%202025-07-06%20at%208.34.49PM.png?generation=1751848571988419&alt=media\")
Looking at the physics of a planetary transit, it seems that the transit time should be approximately
\n2*R_star/(2*pi*R_orbit)*orbit_period
\nbecause this is the fraction of the time that the planet could be in front of the star (assuming a planet small in comparison to the star and the observer far away). It could be less than this if the orbital plane is tilted such that the planet transits closer to an edge of the star, but this is a good starting point.
\nLooking at one planet_id:
.\n .\n .\n .\n .\n .\n .\n .\n: , dtype: float64\nI compute a transit time of 0.17 days or 14,688 sec.
\nThe transit graph looks like this, with a transit time of roughly 25/287*7.5 = 0.65 sec where the entire AIRS-CH0 scan is 7.5 seconds (from axis_info). I'm off by almost 24,000x.
\nAre the units in the axis_info file not in seconds?
\nThe introduction to the competition says the FGS1 channel time is .1s per time step, but the axis_info file says .00011 per time step, so perhaps the units are confused somewhere?
Looking at the physics of a planetary transit, it seems that the transit time should be approximately
\n2*R_star/(2*pi*R_orbit)*orbit_period
\nbecause this is the fraction of the time that the planet could be in front of the star (assuming a planet small in comparison to the star and the observer far away). It could be less than this if the orbital plane is tilted such that the planet transits closer to an edge of the star, but this is a good starting point.
\nLooking at one planet_id:
.\n .\n .\n .\n .\n .\n .\n .\n: , dtype: float64\nI compute a transit time of 0.17 days or 14,688 sec.
\nThe transit graph looks like this, with a transit time of roughly 25/287*7.5 = 0.65 sec where the entire AIRS-CH0 scan is 7.5 seconds (from axis_info). I'm off by almost 24,000x.
\nAre the units in the axis_info file not in seconds?
\nThe introduction to the competition says the FGS1 channel time is .1s per time step, but the axis_info file says .00011 per time step, so perhaps the units are confused somewhere?
Has anyone been able to confirm this for the new train data?
\nI tried but failed, so I'm doubting there's a bug in my code.
negative,
\nI always find planets where it doesn't fit the formula. There is also no fixed scaling or offset, so I am wondering as well what may be causing this.
\n\nWe have been looking into the dataset, and found the same peculiarity in the data. (measured transit duration not consistent with the computed duration)
\n
But maybe just this, and some values in the dataset are just wrong.
", "rawMarkdown": "negative, \nI always find planets where it doesn't fit the formula. There is also no fixed scaling or offset, so I am wondering as well what may be causing this.\n\n> We have been looking into the dataset, and found the same peculiarity in the data. (measured transit duration not consistent with the computed duration)\n\nBut maybe just this, and some values in the dataset are just wrong. ", "replies": [ { "id": 3252323, "postDate": "2025-07-22T13:08:41.717Z", "content": "Same, provided values don't match estimated time span from data.
\nI hope we are not headed to a third version of the dataset.
", "rawMarkdown": "Same, provided values don't match estimated time span from data.\n\nI hope we are not headed to a third version of the dataset.", "votes": 1 }, { "id": 3252324, "postDate": "2025-07-22T13:18:08.800Z", "content": "Hi all, thank you for the question , to clarify, the provided quantities in the train_star_info.csv table contains noise hence it should not match the observed duration (if we are talking about the transit duration), but it should not be too far off, treat that as an approximation rather than the ground truth though!
", "rawMarkdown": "Hi all, thank you for the question , to clarify, the provided quantities in the train_star_info.csv table contains noise hence it should not match the observed duration (if we are talking about the transit duration), but it should not be too far off, treat that as an approximation rather than the ground truth though!", "votes": 5 }, { "id": 3252328, "postDate": "2025-07-22T13:21:45.780Z", "content": "@gordonyip Thanks for the confirmation.
\nIt would be good to have the std error for the values in the table. You ask us to provide std errors, but you don't do it yourself :D
", "rawMarkdown": "@gordonyip Thanks for the confirmation. \n\nIt would be good to have the std error for the values in the table. You ask us to provide std errors, but you don't do it yourself :D", "votes": 1 }, { "id": 3252352, "postDate": "2025-07-22T14:13:02.047Z", "content": "@gordonyip Thank you very much for your confirmation. That's why I gave up using star info to detect transit
", "rawMarkdown": "@gordonyip Thank you very much for your confirmation. That's why I gave up using star info to detect transit" }, { "id": 3252368, "postDate": "2025-07-22T14:50:24.437Z", "content": "Okay, I now understand that there is a noise added to the star_info.csv parameters.
\nHowever, I'm still having trouble matching the transit duration calculated with AIRS-CH0 and FGS1 observations.
\nAre they supposed to match, except for the difference in planet radius?
\nMy analysis code says that for some planets the transit lengths do not match, even when taking the planet radius error into account..
The formula you’re using provides an upper bound for transit duration assuming a circular orbit with an inclination of 90 degrees. However, in reality, the orbital inclination can be less than 90°, meaning the planet may only graze the edge of the star, resulting in a much shorter transit. Additionally, if the orbit is elliptical, the actual transit duration can be either longer or shorter than predicted by the circular model, depending on the orbital eccentricity and the orientation of the ellipse.
\nAlso, in your calculations you seem to ignore 30x binning which is applied by default and which averages 30 consequite frames for AIRS and 30*12 for FGS.
\nHope this helps.
have you accounted for the geometric effect ? if so, the formula should be…
\nt_14 = (period / (pi * a_in_stellar_radii)) * sqrt((1 + planet_radius/stellar_radius)^2 - impact_parameter^2)
Since we don't know the exact value of planet_radius / stellar_radius, I estimated it using sqrt(dip)
\nUsing the formula:
\n$$
\nt_{14} = \\frac{\\text{period}}{\\pi \\cdot a/R_s} \\cdot \\sqrt{(1 + R_p/R_s)^2 - b^2}
\n$$
I approximate the impact parameterb as:
$$
\nb = \\text{sma}_\\text{Rs} \\cdot \\cos(i)
\n$$
i is the orbital inclination in degrees.
My analysis results are approximately as follows:
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F11676771%2Ffa9162905ffe45c4e7e5a54c09e97b7d%2F2af92a6ed5272e242dbba169d980b144.png?generation=1753201022145370&alt=media\")
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F11676771%2F9f2fc9f612074ea5d5e88fd8936ee111%2F75a1526f79df629a03ef59be1169c990.png?generation=1753201030824329&alt=media\")
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F11676771%2F84518be2f4c69dbbc17c68ee3f9abb08%2F451f7cae-ed33-4d37-8c0a-8acded17fd50.png?generation=1753201285364436&alt=media\")
I'm not sure if my analysis is correct, but there are indeed quite a few deviations?
\nWhat about the analyses of others?
\n@gordonyip Do you think this looks normal?
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F11676771%2F073acc720210af04ce4a7727a66b3444%2Fdownload.png?generation=1753250819079127&alt=media\")
Also, for comparison, this is the case using 2*R_star/(2*pi*R_orbit)*orbit_period. I think the degree of deviations is greater?
For what it's worth, I have very close figures, esp the one before last.
", "rawMarkdown": "For what it's worth, I have very close figures, esp the one before last." }, { "id": 3264379, "postDate": "2025-08-06T14:40:36.337Z", "content": "Hi, your analysis is very insightful! May I ask if you could describe in more detail how a and b are calculated?
", "rawMarkdown": "Hi, your analysis is very insightful! May I ask if you could describe in more detail how a and b are calculated?\n" }, { "id": 3264606, "postDate": "2025-08-06T18:49:00.727Z", "content": "I have similar results, that is, that the duration of the transit corresponds approximately with the expected duration from provided P and sma values. However, after realizing that transit depth is approx (Rp/Rs)**2, you can compute a density of the planet given the provided Mp (Mass of planet in earth masses).
\nUsing
= * \n = e8 \n = math.sqrt(row.delta) \n = /*pi*(Rp_delta*Rs*Rsolar)** \n = Mp*e24/V \nFor the first planet, delta=.019, Rp=sqrt(delta)=.138 and
\ncomputed density = 0.711
\nEarth's density is 5515 kg/m3 - Are planets 7700x less dense than Earth?
\nThe other planets have similar densities in the range of .12 to 2 kg/m^3
\nIs the Mp provided way off, or perhaps in different units than Earth mass?
Thanks for catching this! There is an error in the data description, it should be in Jupiter mass unit! I will get it changed shortly.
", "rawMarkdown": "Thanks for catching this! There is an error in the data description, it should be in Jupiter mass unit! I will get it changed shortly. ", "votes": 4 }, { "id": 3264746, "postDate": "2025-08-06T21:20:51.973Z", "content": "Wow Jupiter>>Earth!
", "rawMarkdown": "Wow Jupiter>>Earth!" }, { "id": 3266354, "postDate": "2025-08-08T21:02:52.460Z", "content": "Maybe you should change the symbol next to the Jupiter Mass to M♃ 😃
", "rawMarkdown": "Maybe you should change the symbol next to the Jupiter Mass to M♃ 😃" }, { "id": 3266357, "postDate": "2025-08-08T21:17:54.537Z", "content": "Indeed! Will do that
", "rawMarkdown": "Indeed! Will do that ", "votes": 1 }, { "id": 3276841, "postDate": "2025-08-26T23:55:00.947Z", "content": "What is \"a_in_stellar_radii\" here?
\nedit: nvm figured it out, its sma
Hi everyone,
\nthank you for bringing up this issue. We have been looking into the dataset, and found the same peculiarity in the data. (measured transit duration not consistent with the computed duration), we are currently looking into the issue. Thanks for the great discussion. Please keep it up!
it should not affect the game as the goal is to get the transit depth, which is not dependent on the duration.
", "rawMarkdown": "Hi everyone, \nthank you for bringing up this issue. We have been looking into the dataset, and found the same peculiarity in the data. (measured transit duration not consistent with the computed duration), we are currently looking into the issue. Thanks for the great discussion. Please keep it up! \n\nit should not affect the game as the goal is to get the transit depth, which is not dependent on the duration.", "votes": 4, "replies": [ { "id": 3245634, "postDate": "2025-07-09T15:56:45.277Z", "content": "Thanks for confirming!
\nA follow-up question: for the exoplanet systems that Ariel will study, do you expect that there will be independent estimates of orbital parameters based on other measurements? I ask because some models might benefit from external constraints like a predicted value for the transit duration (or even a signal parameterization in terms of one or two missing orbital parameters)…but if the parameters needed for such constraints aren't likely to be available, then that sort of approach is impractical.
", "rawMarkdown": "Thanks for confirming! \n\nA follow-up question: for the exoplanet systems that Ariel will study, do you expect that there will be independent estimates of orbital parameters based on other measurements? I ask because some models might benefit from external constraints like a predicted value for the transit duration (or even a signal parameterization in terms of one or two missing orbital parameters)...but if the parameters needed for such constraints aren't likely to be available, then that sort of approach is impractical.", "replies": [ { "id": 3252327, "postDate": "2025-07-22T13:21:45.190Z", "content": "Hi sorry for the late reply here - yes for some parameters Ariel will have independent estimates of them, most of them are provided in train_star_info.csv, they are independent estimates of the system but contains noise, so they are not 100% accuracy, this move is to simulate the real life scenario where we will not have exact measurement of the system
", "rawMarkdown": "Hi sorry for the late reply here - yes for some parameters Ariel will have independent estimates of them, most of them are provided in train_star_info.csv, they are independent estimates of the system but contains noise, so they are not 100% accuracy, this move is to simulate the real life scenario where we will not have exact measurement of the system ", "votes": 1 }, { "id": 3252928, "postDate": "2025-07-23T17:34:01.673Z", "content": "Great to know -- thank you!
", "rawMarkdown": "Great to know -- thank you!" } ] } ] }, { "id": 3245582, "postDate": "2025-07-09T15:07:02.940Z", "content": "btw you might want to check your lightcurve above - it doesnt look normal
Does this look better?
\n![\"corrected](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F651278%2Fd9491fdfa81f7311fa1d9d3a42683582%2FScreenshot%202025-07-08%20at%207.23.30AM.png?generation=1752074749301887&alt=media\")
yes it does!
", "rawMarkdown": "yes it does!\n", "votes": 1 } ] } ] }, { "id": 3244176, "postDate": "2025-07-07T22:38:07.960Z", "content": "I'm under the impression that the axis_info.parquet file has the time in units of seconds, but I think maybe you've grabbed the wrong column by accident? My understanding is that the AIRS-ch0 sensor captures 11250 frames, with alternating collection times of 0.1s and 4.5s. Assuming no pause in between each 0.1s+4.5s pair, that's something like 0.3 days for the full scan. That time scale makes sense if a typical transit is of the same order of magnitude as the 0.17 days you compute.
\nAnother possible contribution to the difference you see: I think the formula you've used to estimate that 0.17 days may be assuming zero impact parameter, whereas the example you're looking at has an inclination of about 87 degrees. So the actual transit is probably shorter than 0.17 days because it has a nonzero impact parameter, i.e. the path of the planet is only a chord on the circle of the star, rather than a diameter. If I'm reading Winn's paper right, eq.7 can give you an estimate of the impact parameter. If we knew the radius of the planet (or if we assume it's negligible), we could probably plug that into eqs. 14 or 15 (also eq 16, for cases with nonzero eccentricity) to get an estimate of the transit time.
\nIf I plug numbers into eqs. 7 and 14, I get an impact parameter of about 0.7 and a transit duration of ~0.12 days, or about 10k seconds. This is still off by a factor of ~4 from (25/287)*(5626 frame pairs)*(4.6s per frame pair). Not sure I understand that 25/287, though. To my eye, the full width of the dip in your plot looks to be closer to 40 or 50 units of x-axis, and the x-axis only goes up to about 180 or so. Is 287 maybe a typo, where you meant to say 187?
", "rawMarkdown": "I'm under the impression that the axis_info.parquet file has the time in units of seconds, but I think maybe you've grabbed the wrong column by accident? My understanding is that the AIRS-ch0 sensor captures 11250 frames, with alternating collection times of 0.1s and 4.5s. Assuming no pause in between each 0.1s+4.5s pair, that's something like 0.3 days for the full scan. That time scale makes sense if a typical transit is of the same order of magnitude as the 0.17 days you compute.\n \nAnother possible contribution to the difference you see: I think the formula you've used to estimate that 0.17 days may be assuming zero impact parameter, whereas the example you're looking at has an inclination of about 87 degrees. So the actual transit is probably shorter than 0.17 days because it has a nonzero impact parameter, i.e. the path of the planet is only a chord on the circle of the star, rather than a diameter. If I'm reading [Winn's paper](https://arxiv.org/pdf/1001.2010v5) right, eq.7 can give you an estimate of the impact parameter. If we knew the radius of the planet (or if we assume it's negligible), we could probably plug that into eqs. 14 or 15 (also eq 16, for cases with nonzero eccentricity) to get an estimate of the transit time.\n\nIf I plug numbers into eqs. 7 and 14, I get an impact parameter of about 0.7 and a transit duration of ~0.12 days, or about 10k seconds. This is still off by a factor of ~4 from (25/287)\\*(5626 frame pairs)\\*(4.6s per frame pair). Not sure I understand that 25/287, though. To my eye, the full width of the dip in your plot looks to be closer to 40 or 50 units of x-axis, and the x-axis only goes up to about 180 or so. Is 287 maybe a typo, where you meant to say 187? ", "votes": 2, "replies": [ { "id": 3244204, "postDate": "2025-07-08T00:16:36.417Z", "content": "Yes, sorry that should have been 25/187, and yes, 40 or 50 units wide is probably more accurate.
\nI was looking at this statement from the Data page:
\nEach file contains 11,250 rows of images captured at constant time steps noted in axis_info.parquet
\nNow that I see the column AIRS-CH0-integration_time, what you say makes perfect sense. I was looking at AIRS-CH0-axis0-h, thinking that was the time of each readout (they increase monotonically). So I wonder what the 2 axis0-h columns are?
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F651278%2F85e7391c3fbd473a4da2b72eb077da25%2FScreenshot%202025-07-07%20at%208.08.49PM.png?generation=1751933914404779&alt=media\")
\nAnd if you take the 135,000 FGS1 readings x 0.2s, you get .30 days, matching the AIRS-CH0 sensor. The Data page says 0.1 s time steps, so there is still something confusing me there.
Thanks for clearing things up.
", "rawMarkdown": "Yes, sorry that should have been 25/187, and yes, 40 or 50 units wide is probably more accurate.\nI was looking at this statement from the Data page:\n`Each file contains 11,250 rows of images captured at constant time steps noted in axis_info.parquet `\nNow that I see the column AIRS-CH0-integration_time, what you say makes perfect sense. I was looking at AIRS-CH0-axis0-h, thinking that was the time of each readout (they increase monotonically). So I wonder what the 2 axis0-h columns are?\n\nAnd if you take the 135,000 FGS1 readings x 0.2s, you get .30 days, matching the AIRS-CH0 sensor. The Data page says 0.1 s time steps, so there is still something confusing me there.\n\nThanks for clearing things up.", "replies": [ { "id": 3244208, "postDate": "2025-07-08T00:24:36.590Z", "content": "<Realize col2 is units of um>
\n<hit head on table>
\nThat first column ** is** the sample time, and units are hours (-h!). The time between row 4 and 2 (due to double sampling) is 4.7988 sec, so there is a little extra than the .1+4.5.
and 7.5 hours is .31 days, the length of the full time series. FGS1 has the same 7.5 hour total time as well. Phew
", "rawMarkdown": "and 7.5 hours is .31 days, the length of the full time series. FGS1 has the same 7.5 hour total time as well. Phew", "votes": 2 }, { "id": 3244525, "postDate": "2025-07-08T08:08:58.493Z", "content": "Sorry for my late reply but yes you are exactly right. The total duration is 7.5 hours for both AIRS and FGS1. It seems to me that the lightcurve is a bit off - best to check that one out.
", "rawMarkdown": "Sorry for my late reply but yes you are exactly right. The total duration is 7.5 hours for both AIRS and FGS1. It seems to me that the lightcurve is a bit off - best to check that one out. ", "votes": 3 }, { "id": 3244660, "postDate": "2025-07-08T11:15:57.153Z", "content": "What do you mean by a little bit off? I used your provided calibration code (Calibrating and Binning Ariel Data), and summed the peak position channel: signal[:,:,16].sum(axis=1). It is binned in time the default amount (30?).
Hmm, this looks better when I use all the position channels
\n![\"image\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F651278%2Fef2a15a8c05594e14da0b86a0c92590e%2FScreenshot%202025-07-08%20at%207.23.30AM.png?generation=1751973886291907&alt=media\")
Lol, I had been reading that \"-h\" as \"height\" -- the fact that it's hours and the insight that there's apparently almost 0.2 seconds of idle time between each pair of AIRS reads clears up a question that I had about the alignment between the AIRS and FGS reads. Thanks!
", "rawMarkdown": "Lol, I had been reading that \"-h\" as \"height\" -- the fact that it's hours and the insight that there's apparently almost 0.2 seconds of idle time between each pair of AIRS reads clears up a question that I had about the alignment between the AIRS and FGS reads. Thanks!" }, { "id": 3262597, "postDate": "2025-08-04T00:19:48.770Z", "content": "Thanks for sharing this realization about the hour unit! I could not figure out what was going on.
", "rawMarkdown": "Thanks for sharing this realization about the hour unit! I could not figure out what was going on." }, { "id": 3294024, "postDate": "2025-09-25T08:07:42.487Z", "content": "@gordonyip Coming back to this discussion. My private score started to be 0.000 when I switched to time units in days instead of time indices (to be aligned with time units of stellar parameters). I'm rerunning my notebook with indices to cross-check. But maybe you could already confirm that on private dataset the observation time is still 7.5 hours as in train and public data? Or it is different? I used in particular the orbital period P as a prior in my approach
", "rawMarkdown": "@gordonyip Coming back to this discussion. My private score started to be 0.000 when I switched to time units in days instead of time indices (to be aligned with time units of stellar parameters). I'm rerunning my notebook with indices to cross-check. But maybe you could already confirm that on private dataset the observation time is still 7.5 hours as in train and public data? Or it is different? I used in particular the orbital period P as a prior in my approach" }, { "id": 3294028, "postDate": "2025-09-25T08:17:12.333Z", "content": "I also used the 7.5 hours, but as some of my submissions are still good, I believe this isn't different in test. Also, hosts confirmed multiple times that there is no intentional difference between public and private test set.
\nI think just a single or a few very badly fitted samples (and too high confidence on them) for both of us.
", "rawMarkdown": "I also used the 7.5 hours, but as some of my submissions are still good, I believe this isn't different in test. Also, hosts confirmed multiple times that there is no intentional difference between public and private test set. \n\nI think just a single or a few very badly fitted samples (and too high confidence on them) for both of us.", "votes": 1 }, { "id": 3294040, "postDate": "2025-09-25T08:46:24.653Z", "content": "Ah, @ilu000 , sorry to hear you also have a big drop on the private LB :(
", "rawMarkdown": "Ah, @ilu000 , sorry to hear you also have a big drop on the private LB :(" } ] }, { "id": 3244730, "postDate": "2025-07-08T13:29:56.860Z", "content": "If I take the transit duration you computed t~0.12 days and compare it with a visual estimation (40 / 187) * (7.5 / 24) ~ 0.067 days, there is a factor 2 error. Do you know how to explain it ?
", "rawMarkdown": "If I take the transit duration you computed t~0.12 days and compare it with a visual estimation (40 / 187) * (7.5 / 24) ~ 0.067 days, there is a factor 2 error. Do you know how to explain it ? ", "isDeleted": true, "replies": [ { "id": 3244812, "postDate": "2025-07-08T15:57:35.510Z", "content": "I still consider this an open question. Could be as simple as fat finger error in my calculation of t~0.12 days. Could be I'm using the wrong formula or neglecting a factor that I shouldn't. Could be something I am misinterpreting about the units of the stellar parameters. Could be something we don't understand about the light curve.
\nMy t~0.12 days estimate assumes that the planet's radius is negligibly small compared to the star. It's worth revisiting because, if that assumption is violated, the bottom of the transit dip would be narrower than the top. If I'm doing the math right, a huge planet with radius Rp~0.2*Rs would make the bottom of the dip (T_{full} in Winn's notation) on the order of the 40 time bins you estimate. But this would also mean that the top of the dip, T_{tot}, would be like 90-ish time bins and the sides would have a much softer slope…I have a hard time seeing that in the plot no matter how hard I squint, so right now it's hard for me to make a case that this explains the missing factor of two.
", "rawMarkdown": "I still consider this an open question. Could be as simple as fat finger error in my calculation of t~0.12 days. Could be I'm using the wrong formula or neglecting a factor that I shouldn't. Could be something I am misinterpreting about the units of the stellar parameters. Could be something we don't understand about the light curve.\n\nMy t~0.12 days estimate assumes that the planet's radius is negligibly small compared to the star. It's worth revisiting because, if that assumption is violated, the bottom of the transit dip would be narrower than the top. If I'm doing the math right, a huge planet with radius Rp~0.2*Rs would make the bottom of the dip (T_{full} in Winn's notation) on the order of the 40 time bins you estimate. But this would also mean that the top of the dip, T_{tot}, would be like 90-ish time bins and the sides would have a much softer slope...I have a hard time seeing that in the plot no matter how hard I squint, so right now it's hard for me to make a case that this explains the missing factor of two." }, { "id": 3245010, "postDate": "2025-07-08T18:27:44.630Z", "content": "Gotta add another maybe to the list: I notice that all the values for eccentricity in train_star_info.csv are 0. Does anyone know if the data were actually all simulated with circular orbits? Because I get the sense that if the planet in this example were on a very highly eccentric orbit, that could explain the difference between the prediction and the transit duration we're eyeballing from the plot.
", "rawMarkdown": "Gotta add another maybe to the list: I notice that all the values for eccentricity in train_star_info.csv are 0. Does anyone know if the data were actually all simulated with circular orbits? Because I get the sense that if the planet in this example were on a very highly eccentric orbit, that could explain the difference between the prediction and the transit duration we're eyeballing from the plot.", "votes": 3 } ] } ] } ], "comments": [ { "id": 3252201, "author_name": "c-number", "author_url": "", "post_date": "2025-07-22T07:41:12.533000", "content": "Has anyone been able to confirm this for the new train data?
\nI tried but failed, so I'm doubting there's a bug in my code.
negative,
\nI always find planets where it doesn't fit the formula. There is also no fixed scaling or offset, so I am wondering as well what may be causing this.
\n\nWe have been looking into the dataset, and found the same peculiarity in the data. (measured transit duration not consistent with the computed duration)
\n
But maybe just this, and some values in the dataset are just wrong.
", "votes": 0, "replies": [ { "id": 3252323, "author_name": "CPMP", "author_url": "", "post_date": "2025-07-22T13:08:41.717000", "content": "Same, provided values don't match estimated time span from data.
\nI hope we are not headed to a third version of the dataset.
", "votes": 1, "replies": [] }, { "id": 3252324, "author_name": "Gordon Yip", "author_url": "", "post_date": "2025-07-22T13:18:08.800000", "content": "Hi all, thank you for the question , to clarify, the provided quantities in the train_star_info.csv table contains noise hence it should not match the observed duration (if we are talking about the transit duration), but it should not be too far off, treat that as an approximation rather than the ground truth though!
", "votes": 5, "replies": [] }, { "id": 3252328, "author_name": "CPMP", "author_url": "", "post_date": "2025-07-22T13:21:45.780000", "content": "@gordonyip Thanks for the confirmation.
\nIt would be good to have the std error for the values in the table. You ask us to provide std errors, but you don't do it yourself :D
", "votes": 1, "replies": [] }, { "id": 3252352, "author_name": "Horikita Saku", "author_url": "", "post_date": "2025-07-22T14:13:02.047000", "content": "@gordonyip Thank you very much for your confirmation. That's why I gave up using star info to detect transit
", "votes": 0, "replies": [] }, { "id": 3252368, "author_name": "c-number", "author_url": "", "post_date": "2025-07-22T14:50:24.437000", "content": "Okay, I now understand that there is a noise added to the star_info.csv parameters.
\nHowever, I'm still having trouble matching the transit duration calculated with AIRS-CH0 and FGS1 observations.
\nAre they supposed to match, except for the difference in planet radius?
\nMy analysis code says that for some planets the transit lengths do not match, even when taking the planet radius error into account..
The formula you’re using provides an upper bound for transit duration assuming a circular orbit with an inclination of 90 degrees. However, in reality, the orbital inclination can be less than 90°, meaning the planet may only graze the edge of the star, resulting in a much shorter transit. Additionally, if the orbit is elliptical, the actual transit duration can be either longer or shorter than predicted by the circular model, depending on the orbital eccentricity and the orientation of the ellipse.
\nAlso, in your calculations you seem to ignore 30x binning which is applied by default and which averages 30 consequite frames for AIRS and 30*12 for FGS.
\nHope this helps.
have you accounted for the geometric effect ? if so, the formula should be…
\nt_14 = (period / (pi * a_in_stellar_radii)) * sqrt((1 + planet_radius/stellar_radius)^2 - impact_parameter^2)
Since we don't know the exact value of planet_radius / stellar_radius, I estimated it using sqrt(dip)
\nUsing the formula:
\n$$
\nt_{14} = \\frac{\\text{period}}{\\pi \\cdot a/R_s} \\cdot \\sqrt{(1 + R_p/R_s)^2 - b^2}
\n$$
I approximate the impact parameterb as:
$$
\nb = \\text{sma}_\\text{Rs} \\cdot \\cos(i)
\n$$
i is the orbital inclination in degrees.
My analysis results are approximately as follows:
\n
I'm not sure if my analysis is correct, but there are indeed quite a few deviations?
\nWhat about the analyses of others?
\n@gordonyip Do you think this looks normal?
Also, for comparison, this is the case using 2*R_star/(2*pi*R_orbit)*orbit_period. I think the degree of deviations is greater?
For what it's worth, I have very close figures, esp the one before last.
", "votes": 0, "replies": [] }, { "id": 3264379, "author_name": "CKL", "author_url": "", "post_date": "2025-08-06T14:40:36.337000", "content": "Hi, your analysis is very insightful! May I ask if you could describe in more detail how a and b are calculated?
", "votes": 0, "replies": [] }, { "id": 3264606, "author_name": "SolverWorld", "author_url": "", "post_date": "2025-08-06T18:49:00.727000", "content": "I have similar results, that is, that the duration of the transit corresponds approximately with the expected duration from provided P and sma values. However, after realizing that transit depth is approx (Rp/Rs)**2, you can compute a density of the planet given the provided Mp (Mass of planet in earth masses).
\nUsing
= * \n = e8 \n = math.sqrt(row.delta) \n = /*pi*(Rp_delta*Rs*Rsolar)** \n = Mp*e24/V \nFor the first planet, delta=.019, Rp=sqrt(delta)=.138 and
\ncomputed density = 0.711
\nEarth's density is 5515 kg/m3 - Are planets 7700x less dense than Earth?
\nThe other planets have similar densities in the range of .12 to 2 kg/m^3
\nIs the Mp provided way off, or perhaps in different units than Earth mass?
Thanks for catching this! There is an error in the data description, it should be in Jupiter mass unit! I will get it changed shortly.
", "votes": 4, "replies": [] }, { "id": 3264746, "author_name": "SolverWorld", "author_url": "", "post_date": "2025-08-06T21:20:51.973000", "content": "Wow Jupiter>>Earth!
", "votes": 0, "replies": [] }, { "id": 3266354, "author_name": "SolverWorld", "author_url": "", "post_date": "2025-08-08T21:02:52.460000", "content": "Maybe you should change the symbol next to the Jupiter Mass to M♃ 😃
", "votes": 0, "replies": [] }, { "id": 3266357, "author_name": "Gordon Yip", "author_url": "", "post_date": "2025-08-08T21:17:54.537000", "content": "Indeed! Will do that
", "votes": 1, "replies": [] }, { "id": 3276841, "author_name": "sroger", "author_url": "", "post_date": "2025-08-26T23:55:00.947000", "content": "What is \"a_in_stellar_radii\" here?
\nedit: nvm figured it out, its sma
Hi everyone,
\nthank you for bringing up this issue. We have been looking into the dataset, and found the same peculiarity in the data. (measured transit duration not consistent with the computed duration), we are currently looking into the issue. Thanks for the great discussion. Please keep it up!
it should not affect the game as the goal is to get the transit depth, which is not dependent on the duration.
", "votes": 4, "replies": [ { "id": 3245634, "author_name": "particlebbq", "author_url": "", "post_date": "2025-07-09T15:56:45.277000", "content": "Thanks for confirming!
\nA follow-up question: for the exoplanet systems that Ariel will study, do you expect that there will be independent estimates of orbital parameters based on other measurements? I ask because some models might benefit from external constraints like a predicted value for the transit duration (or even a signal parameterization in terms of one or two missing orbital parameters)…but if the parameters needed for such constraints aren't likely to be available, then that sort of approach is impractical.
", "votes": 0, "replies": [ { "id": 3252327, "author_name": "Gordon Yip", "author_url": "", "post_date": "2025-07-22T13:21:45.190000", "content": "Hi sorry for the late reply here - yes for some parameters Ariel will have independent estimates of them, most of them are provided in train_star_info.csv, they are independent estimates of the system but contains noise, so they are not 100% accuracy, this move is to simulate the real life scenario where we will not have exact measurement of the system
", "votes": 1, "replies": [] }, { "id": 3252928, "author_name": "particlebbq", "author_url": "", "post_date": "2025-07-23T17:34:01.673000", "content": "Great to know -- thank you!
", "votes": 0, "replies": [] } ] } ] }, { "id": 3245582, "author_name": "Gordon Yip", "author_url": "", "post_date": "2025-07-09T15:07:02.940000", "content": "btw you might want to check your lightcurve above - it doesnt look normal
Does this look better?
\n
yes it does!
", "votes": 1, "replies": [] } ] } ] }, { "id": 3244176, "author_name": "particlebbq", "author_url": "", "post_date": "2025-07-07T22:38:07.960000", "content": "I'm under the impression that the axis_info.parquet file has the time in units of seconds, but I think maybe you've grabbed the wrong column by accident? My understanding is that the AIRS-ch0 sensor captures 11250 frames, with alternating collection times of 0.1s and 4.5s. Assuming no pause in between each 0.1s+4.5s pair, that's something like 0.3 days for the full scan. That time scale makes sense if a typical transit is of the same order of magnitude as the 0.17 days you compute.
\nAnother possible contribution to the difference you see: I think the formula you've used to estimate that 0.17 days may be assuming zero impact parameter, whereas the example you're looking at has an inclination of about 87 degrees. So the actual transit is probably shorter than 0.17 days because it has a nonzero impact parameter, i.e. the path of the planet is only a chord on the circle of the star, rather than a diameter. If I'm reading Winn's paper right, eq.7 can give you an estimate of the impact parameter. If we knew the radius of the planet (or if we assume it's negligible), we could probably plug that into eqs. 14 or 15 (also eq 16, for cases with nonzero eccentricity) to get an estimate of the transit time.
\nIf I plug numbers into eqs. 7 and 14, I get an impact parameter of about 0.7 and a transit duration of ~0.12 days, or about 10k seconds. This is still off by a factor of ~4 from (25/287)*(5626 frame pairs)*(4.6s per frame pair). Not sure I understand that 25/287, though. To my eye, the full width of the dip in your plot looks to be closer to 40 or 50 units of x-axis, and the x-axis only goes up to about 180 or so. Is 287 maybe a typo, where you meant to say 187?
", "votes": 2, "replies": [ { "id": 3244204, "author_name": "SolverWorld", "author_url": "", "post_date": "2025-07-08T00:16:36.417000", "content": "Yes, sorry that should have been 25/187, and yes, 40 or 50 units wide is probably more accurate.
\nI was looking at this statement from the Data page:
\nEach file contains 11,250 rows of images captured at constant time steps noted in axis_info.parquet
\nNow that I see the column AIRS-CH0-integration_time, what you say makes perfect sense. I was looking at AIRS-CH0-axis0-h, thinking that was the time of each readout (they increase monotonically). So I wonder what the 2 axis0-h columns are?
\n
\nAnd if you take the 135,000 FGS1 readings x 0.2s, you get .30 days, matching the AIRS-CH0 sensor. The Data page says 0.1 s time steps, so there is still something confusing me there.
Thanks for clearing things up.
", "votes": 0, "replies": [ { "id": 3244208, "author_name": "SolverWorld", "author_url": "", "post_date": "2025-07-08T00:24:36.590000", "content": "<Realize col2 is units of um>
\n<hit head on table>
\nThat first column ** is** the sample time, and units are hours (-h!). The time between row 4 and 2 (due to double sampling) is 4.7988 sec, so there is a little extra than the .1+4.5.
and 7.5 hours is .31 days, the length of the full time series. FGS1 has the same 7.5 hour total time as well. Phew
", "votes": 2, "replies": [] }, { "id": 3244525, "author_name": "Gordon Yip", "author_url": "", "post_date": "2025-07-08T08:08:58.493000", "content": "Sorry for my late reply but yes you are exactly right. The total duration is 7.5 hours for both AIRS and FGS1. It seems to me that the lightcurve is a bit off - best to check that one out.
", "votes": 3, "replies": [] }, { "id": 3244660, "author_name": "SolverWorld", "author_url": "", "post_date": "2025-07-08T11:15:57.153000", "content": "What do you mean by a little bit off? I used your provided calibration code (Calibrating and Binning Ariel Data), and summed the peak position channel: signal[:,:,16].sum(axis=1). It is binned in time the default amount (30?).
Hmm, this looks better when I use all the position channels
\n
Lol, I had been reading that \"-h\" as \"height\" -- the fact that it's hours and the insight that there's apparently almost 0.2 seconds of idle time between each pair of AIRS reads clears up a question that I had about the alignment between the AIRS and FGS reads. Thanks!
", "votes": 0, "replies": [] }, { "id": 3262597, "author_name": "Lucas Corcodilos", "author_url": "", "post_date": "2025-08-04T00:19:48.770000", "content": "Thanks for sharing this realization about the hour unit! I could not figure out what was going on.
", "votes": 0, "replies": [] }, { "id": 3294024, "author_name": "Oleh Kivernyk", "author_url": "", "post_date": "2025-09-25T08:07:42.487000", "content": "@gordonyip Coming back to this discussion. My private score started to be 0.000 when I switched to time units in days instead of time indices (to be aligned with time units of stellar parameters). I'm rerunning my notebook with indices to cross-check. But maybe you could already confirm that on private dataset the observation time is still 7.5 hours as in train and public data? Or it is different? I used in particular the orbital period P as a prior in my approach
", "votes": 0, "replies": [] }, { "id": 3294028, "author_name": "Pascal Pfeiffer", "author_url": "", "post_date": "2025-09-25T08:17:12.333000", "content": "I also used the 7.5 hours, but as some of my submissions are still good, I believe this isn't different in test. Also, hosts confirmed multiple times that there is no intentional difference between public and private test set.
\nI think just a single or a few very badly fitted samples (and too high confidence on them) for both of us.
", "votes": 1, "replies": [] }, { "id": 3294040, "author_name": "Oleh Kivernyk", "author_url": "", "post_date": "2025-09-25T08:46:24.653000", "content": "Ah, @ilu000 , sorry to hear you also have a big drop on the private LB :(
", "votes": 0, "replies": [] } ] }, { "id": 3244730, "author_name": "", "author_url": "", "post_date": "2025-07-08T13:29:56.860000", "content": "If I take the transit duration you computed t~0.12 days and compare it with a visual estimation (40 / 187) * (7.5 / 24) ~ 0.067 days, there is a factor 2 error. Do you know how to explain it ?
", "votes": 0, "replies": [ { "id": 3244812, "author_name": "particlebbq", "author_url": "", "post_date": "2025-07-08T15:57:35.510000", "content": "I still consider this an open question. Could be as simple as fat finger error in my calculation of t~0.12 days. Could be I'm using the wrong formula or neglecting a factor that I shouldn't. Could be something I am misinterpreting about the units of the stellar parameters. Could be something we don't understand about the light curve.
\nMy t~0.12 days estimate assumes that the planet's radius is negligibly small compared to the star. It's worth revisiting because, if that assumption is violated, the bottom of the transit dip would be narrower than the top. If I'm doing the math right, a huge planet with radius Rp~0.2*Rs would make the bottom of the dip (T_{full} in Winn's notation) on the order of the 40 time bins you estimate. But this would also mean that the top of the dip, T_{tot}, would be like 90-ish time bins and the sides would have a much softer slope…I have a hard time seeing that in the plot no matter how hard I squint, so right now it's hard for me to make a case that this explains the missing factor of two.
", "votes": 0, "replies": [] }, { "id": 3245010, "author_name": "particlebbq", "author_url": "", "post_date": "2025-07-08T18:27:44.630000", "content": "Gotta add another maybe to the list: I notice that all the values for eccentricity in train_star_info.csv are 0. Does anyone know if the data were actually all simulated with circular orbits? Because I get the sense that if the planet in this example were on a very highly eccentric orbit, that could explain the difference between the prediction and the transit duration we're eyeballing from the plot.
", "votes": 3, "replies": [] } ] } ] } ], "raw_markdown_by_id": { "3243269": "Looking at the physics of a planetary transit, it seems that the transit time should be approximately\n`2*R_star/(2*pi*R_orbit)*orbit_period`\nbecause this is the fraction of the time that the planet could be in front of the star (assuming a planet small in comparison to the star and the observer far away). It could be less than this if the orbital plane is tilted such that the planet transits closer to an edge of the star, but this is a good starting point.\nLooking at one planet_id:\n```\nRs 1.250623\nMs 1.162019\nTs 6023.702622\nMp 2.262107\ne 0.000000\nP 7.541019\nsma 14.144310\ni 87.178007\nName: 8456603, dtype: float64\n```\nI compute a transit time of 0.17 days or 14,688 sec.\nThe transit graph looks like this, with a transit time of roughly 25/287*7.5 = 0.65 sec where the entire AIRS-CH0 scan is 7.5 seconds (from axis_info). I'm off by almost 24,000x.\nAre the units in the axis_info file not in seconds? \nThe introduction to the competition says the FGS1 channel time is .1s per time step, but the axis_info file says .00011 per time step, so perhaps the units are confused somewhere?\n\n\n", "3252201": "Has anyone been able to confirm this for the new train data?\nI tried but failed, so I'm doubting there's a bug in my code.", "3245573": "Hi everyone, \nthank you for bringing up this issue. We have been looking into the dataset, and found the same peculiarity in the data. (measured transit duration not consistent with the computed duration), we are currently looking into the issue. Thanks for the great discussion. Please keep it up! \n\nit should not affect the game as the goal is to get the transit depth, which is not dependent on the duration.", "3245582": "btw you might want to check your lightcurve above - it doesnt look `normal`", "3244176": "I'm under the impression that the axis_info.parquet file has the time in units of seconds, but I think maybe you've grabbed the wrong column by accident? My understanding is that the AIRS-ch0 sensor captures 11250 frames, with alternating collection times of 0.1s and 4.5s. Assuming no pause in between each 0.1s+4.5s pair, that's something like 0.3 days for the full scan. That time scale makes sense if a typical transit is of the same order of magnitude as the 0.17 days you compute.\n \nAnother possible contribution to the difference you see: I think the formula you've used to estimate that 0.17 days may be assuming zero impact parameter, whereas the example you're looking at has an inclination of about 87 degrees. So the actual transit is probably shorter than 0.17 days because it has a nonzero impact parameter, i.e. the path of the planet is only a chord on the circle of the star, rather than a diameter. If I'm reading [Winn's paper](https://arxiv.org/pdf/1001.2010v5) right, eq.7 can give you an estimate of the impact parameter. If we knew the radius of the planet (or if we assume it's negligible), we could probably plug that into eqs. 14 or 15 (also eq 16, for cases with nonzero eccentricity) to get an estimate of the transit time.\n\nIf I plug numbers into eqs. 7 and 14, I get an impact parameter of about 0.7 and a transit duration of ~0.12 days, or about 10k seconds. This is still off by a factor of ~4 from (25/287)\\*(5626 frame pairs)\\*(4.6s per frame pair). Not sure I understand that 25/287, though. To my eye, the full width of the dip in your plot looks to be closer to 40 or 50 units of x-axis, and the x-axis only goes up to about 180 or so. Is 287 maybe a typo, where you meant to say 187? " } }