This is regarding the CSV file available at GWTC on the GWOSC events portal. We are doing an analysis which requires the geocentric GPS time to a higher decimal place. However, the CSV file seems to store the values only till the first decimal place. Is there a way to access t_gps of all the events to higher precision from the catalog available at GWOSC? Or, can the t_gps values stored in the CSV updated to a higher precision?
Thanks!
Hi Devesh,
The events’ GPS times that come out of the analysis pipelines are usually reported with about that precision, and that’s why you see only 1 decimal place after the second. GWOSC doesn’t remove any digits, only presents the reported times in the corresponding papers.
The individual parameter estimation outputs for different runs seem to store geocent_time to a higher accuracy. However, this parameter seems to be missing in the IGWN-GWTC5p0-29ebe06b7_25-PESummaryTable.hdf5 (PE summary file) and it seems that the only way to access this particular parameter is to download the PE outputs of all the individual events. Please let me know if there is a cleaner way. Thanks!
I see what you mean. No, there’s no easier way to extract those values that I know of. Bear in mind, that those files will contain IEEE doubles or floats, which represent numbers with many digits, but that does not mean all those digits are significant, nor does it mean that any parameter will be accurate to all those digits.
Thanks for the clraification, Martin. It sounds like I’ll have to extract the geocent_time values from the individual PE files for each event.
I also understand your point that the additional digits stored in the PE outputs should not be interpreted as physically significant beyond the statistical uncertainty. My interest is specifically for ringdown analyses, where the start time is often specified as (t_0 + \mathcal{O}(10M)). For stellar-mass black holes, (10M) corresponds to a timescale of order 10^-5 to 10^-3 seconds, so I would expect the inferred merger time itself to be determined with at least sub-millisecond precision for many events, even if not all stored digits are statistically meaningful. That’s why I was looking for a higher-precision catalog value. Thanks again for the clarification!