Skip to content
Snippets Groups Projects

Add underground Rayleigh NN calculation to newtonian.gravg_rayleigh

Merged Evan Hall requested to merge evan.hall/pygwinc:rayleigh-underground into master
3 unresolved threads

This follows the equations in Amann et al. (2020) RSI 91(9) 094504. The functionality for above-ground detectors should not be affected.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
119 120 zeta = sqrt(qzP / qzS)
120 121
121 122 gnu = k * (1 - zeta) / (qzP - k * zeta)
123
124 if h >= 0:
125 # Harms LRR
126 n = (2 * pi * const.G * rho * exp(-h * k) * gnu)**2 * ground**2 / w**4
122 127
123 n = (2 * pi * const.G * rho * exp(-h * k) * gnu)**2 * ground**2 / w**4
128 else:
129 # Amann et al., eqs. 2-6 (note h is there defined as depth)
130 # The "gamma" cancellation factor is assumed to be 1
131 r0 = k * (1 - zeta)
132 sh = -k * (1 + zeta) * exp(h * k)
133 bh = (2 / 3) * (2 * k * exp(h * qzP) + zeta * qzS * exp(h * qzS))
  • In the paper the sh and bh terms have negative exponents. Is h defined differently in the paper or something?

  • Author Maintainer

    Yes, the paper defines positive h to mean below ground. We define positive h to mean above ground. That's the point of the comment on the Amann paper. However h is defined, Rayleigh waves decay exponentially, so the displacement noise should go to zero away from the surface.

  • Please register or sign in to reply
  • Jameson Rollins approved this merge request

    approved this merge request

  • Evan Hall added 1 commit

    added 1 commit

    • f6cdec3e - Density cancellation for underground Rayleigh

    Compare with previous version

  • Jameson Rollins approved this merge request

    approved this merge request

    • I note that we're not actually testing this new code path. Seems like it would be prudent to add some additional (potentially fictional) IFOs to our test suite to tickle these extra bits. I guess if we can ever get an ET canonical IFO included it will be tested there. I don't think we should block this MR on that though.

    • Isn't this the point of having actual unit tests, as addressed in !126 (merged)? There are several code paths that are not tested by the canonical IFOs.

    • Good point. Does someone want to take a stab at writing a unit test for this?

    • I can try to write some unit tests for !121 (merged) following the example of !129 (closed) and then come back here if someone else hasn't done it already. I've been thinking that !121 (merged) needs them anyway and have local tests. I would be fine merging !121 (merged) and !135 (merged) now without them though and adding the tests in separate commits. The quantum code really needs them (in fact I'm not confident that the current code would pass all unit tests that should exist) but !129 (closed) already has them. I think there are code paths in almost all of the other noises that are not tested by the canonical IFOs (or which would not change the noise in the canonical IFOs and therefore would not currently be caught) which should also have tests.

    • I don't think we need to block this on having unit tests, if we want to go ahead and push this through. But if we're going to have unit tests then we should start writing them for the existing functionality, and start requiring them for new code.

    • Author Maintainer

      I would like to push this through before the summer school, though I agree unit tests are good in general.

    • I approved. Anyone else can hit the merge button.

    • Please register or sign in to reply
  • merged

  • Kevin Kuns mentioned in commit da7375a3

    mentioned in commit da7375a3

  • Please register or sign in to reply
    Loading