Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LVC conversion script questions #3

Open
geoffrey4444 opened this issue Apr 29, 2019 · 3 comments
Open

LVC conversion script questions #3

geoffrey4444 opened this issue Apr 29, 2019 · 3 comments

Comments

@geoffrey4444
Copy link
Collaborator

geoffrey4444 commented Apr 29, 2019

Edit: questions still remaining
• How should the sxs_catalog.json file be maintained, updated? It's currently on the arXiv entry for our paper [Mike will update black-holes.org so this file is available at some known URL?]
• Is the catalog paper always the right reference to cite? Cite catalog paper first, followed by Bibtex keys in our metadata [Harald is updating BibTeX keys]

Edit: questions resolved
• The current script gives roundoff differences vs Patricia's old script for phases, derived horizon quantities. Are these a problem? [Probably fine, since we're using different numerical method to get these quantities]
• Should license be public? [Yes, public waves will be public]
• Should spline tolerances use relative Linf, not abs Linf? [yes]
• Should spline tolerances be set to 1e-6? [yes]
• Should we round eta < 0.2501 to 0.25? [yes]
• Should we use a bogus negative number for eccentricity when we can't measure it? [yes, but use -1]
• There is one extra time at the beginning of each NRtimes vs what I expect...important to track down why? Important to output one NRtimes entry per mode, when they are all the same? [Just output times for the 22 mode]

@SergeiOssokine
Copy link
Contributor

Looking through the script, I noticed a few more things which I wasn't sure about:

  • Currently when computing omega and LN_hat we use forward differences which results in those data sets having 1 less point than say n-hat-vs-time.
  • The function that looks at comparable cases currently only considers the mass ratio and magnitudes of the spins and not their directions (it also does not take into account eccentricity). So a q=5, chi1=(0.9,0.0,0.0) would be considered close to q=5, chi1=(0.0,0.0,0.9).
  • Currently when we call romspline to generate the spline we use the default value for the degree of the spline, which is 5. However, in LALSuite, when the data is being reconstructed the interpolation is done using cubic splines. Should we also just use cubic splines?

@geoffrey4444
Copy link
Collaborator Author

• I vote for sticking with forward differences, which is just what we did before, for consistency
• I agree it's not optimal, but it's not obvious to me how to properly fold in everything you might want to look at. Is eccentricity more or less important than mass ratios and spins for determining accuracy?
• I vote for using the same degree as before, not cubic splines, for consistency.

@aaronbzimmerman
Copy link

Update from May 8 vacuum call:

  • Leave the finite differencing in place for now
  • Eccentricity should probably not be very different for the "similar run" used in error estimates, since an eccentricity 0.1 run isn't really the same as a circular run. Add logic to check that the eccentricity be close enough that only quasi-circular runs are used to estimate errors for quasi-circular runs (maybe check that the difference in eccentricity is less than say 0.01 or 0.05?)
  • Discussion of spline tabled for now while Geoffrey thinks about it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants