Check coupling of GWs

We currently couple the GWs (expected in fractional frequency deviations) in carriers and sidebands using self.central_freq,

logger.debug("Propagating carrier fluctuations to distant MOSAs")
self.distant_carrier_fluctuations = ForEachMOSA(lambda mosa:
    self.central_freq * self.gws[mosa] + (1 - self.d_pprs[mosa]) * \
    self.interpolate(self.local_carrier_fluctuations[ForEachMOSA.distant(mosa)],
        -self.pprs[mosa] * self.physics_fs)
)

logger.debug("Propagating upper sideband fluctuations to distant MOSAs")
self.distant_usb_fluctuations = ForEachMOSA(lambda mosa:
    self.central_freq * self.gws[mosa] + (1 - self.d_pprs[mosa]) * \
    self.interpolate(self.local_usb_fluctuations[ForEachMOSA.distant(mosa)],
        - self.pprs[mosa] * self.physics_fs)
)

I'm not sure those are the correctly coupling factors (see #17 (closed)). To be checked with experts.

changed milestone to %v1.0

Also, @ohartwig pointed out that GW files are computed using the LTTs in GW Response, while we propagate signals using the PPRs in LISA Instrument. We should certainly make sure that the whole chain is consistent.

changed milestone to %v1.1

Hey @ohartwig! Do you wanna talk about this for an hour one of these days, to get it out of the way (or fix things if need be)? It seems to be that it's important for the simulators, now that people are actually injecting GW signals and using realistic orbits.

Sure, that sounds interesting! Maybe already tomorrow afternoon? Or next week.

I can tomorrow at 6:30 PM CET, for an hour. Would that work?

That's a bit late, I have something in the evening. Next week, then?

changed milestone to %v1.0.1

The few conclusions from our discussion

• Change the coupling factor from central_freq to central_freq + offset, as other noises (see !28 (merged))
• There should be a "-" sign
• Need to "resample" the GW response (as a ffd) from TCB to TPS, either in LISA Instrument or LISA GW Response, using the tps/t dataset of the orbit file
• No need to rescale the coupling to account for the change of coordinates (no Doppler factor), because it is very small, see discussions around Eq. (71) of attached document

Todo:

• Change the coupling factor from central_freq to central_freq + offset
• Add a minus sign
• Decide where to resample GW responses (either directly in LISA GW Response and have a dedicated dataset in GW files for responses in the respective TPSs, or resample things in LISA Instrument), and implement
  • To spare redundant computations, we should have this in the GW file (because LISA GW Response has all the information it needs from the orbit file)
  • But both TCB and TPS responses should be saved, as LISA Instrument have an option to ignore relativity (assume TPS = TCB), so it makes for larger GW files
  • LISA Instrument can very easily interpolate using orbit file and GW file, but redundant computation for each simulation with the same GW file and orbits

LISA_modeling__1_.pdf

About this point:

No need to rescale the coupling to account for the change of coordinates (no Doppler factor), because it is very small, see discussions around Eq. (71) of attached document

I think the same argument holds for the coupling factor, since offset/central_freq = 20MHz/282THz ~= 1e-8, which is the same order of magnitude which is given in the linked pdf for the rescaling from TCB to TPS. I would probably still change it for consistency with other pathlength noises, though.

For the question where to do the conversion, I think we had the same discussion for LISAOrbits, and decided in the end to keep it out of the instrument simulation. So I would do it in LISA GW Response to be consistent between those tools. This also saves us from implementing the same feature in multiple simulators (e.g. LISANode).

I think the same argument holds for the coupling factor, since offset/central_freq = 20MHz/282THz ~= 1e-8, which is the same order of magnitude which is given in the linked pdf for the rescaling from TCB to TPS. I would probably still change it for consistency with other pathlength noises, though.

You're right, but that's only valid for the carriers. The ratio is 3 orders of magnitude higher for sidebands, and that's why we decided to include the frequency offsets for the other path length noises.

For the question where to do the conversion, I think we had the same discussion for LISAOrbits, and decided in the end to keep it out of the instrument simulation. So I would do it in LISA GW Response to be consistent between those tools. This also saves us from implementing the same feature in multiple simulators (e.g. LISANode).

I would tend to agree with you here.

I'm just a little concern for long simulations, as it can be expensive to resample and write another dataset of the same size. We basically multiply the runtime by around 2, and the size of the file strictly by 2. But I guess there's no real way around that…

Ah, good point on the sidebands you're right!

For the second point, I'm not sure I follow; are you concerned about the runtime of the GW Response tool? I guess depending on the use case, writing both data sets could be optional there, since contrary to orbits, people probably want to experiment a lot with their own GW signals.

Yeah, I'm concerned about the runtime and the size of the resulting file.

But I guess you're right. Similarly to LISA Instrument, where we can opt in and out for intermediary datasets, we could have the option to not resample and not write the responses as a function of the TPSs.

Ok, I think we have a pretty clear view of what we need to do. I will open an issue on LISA GW Response for this, and will implement what we need here. We need to handle the case where users will use a previous version of LISA GW Response with a recent version of LISA Instrument and enable relativity: we should probably issue a warning and still use the responses on the TCB to mimic the current (old) behavior.

• New issue in LISA GW Response: gw-response#16 (closed)
• New issue for LISA Instrument, once the previous feature is implemented in GW files: #56 (closed)

assigned to @j2b.bayle

added bug label

created merge request !82 (merged) to address this issue

mentioned in merge request !82 (merged)

mentioned in issue gw-response#16 (closed)

mentioned in issue #56 (closed)

marked this issue as related to #56 (closed)

marked this issue as related to gw-response#16 (closed)

mentioned in commit f762df93

closed with merge request !82 (merged)