feat: add power-law solar wind gp as a noise component #1854
Conversation
jeremy-baier
changed the title
|
Does this model treat NE_SW as a Fourier Gaussian process? |
|
And is this the same model Sai Chaitanya presented in the IPTA meeting? |
It models solar wind delay using a Fourier basis which is like a DM Fourier basis but multiplied by a geometric factor which encodes information about the pulsar line of sight with respect to the sun.
Yes, this is the power-law model which Sai presented at the 2024 IPTA meeting and is described in this paper. I have been testing this model with the priors and Fourier basis described in the paper. |
|
There is not any physical justification for a power law specifically so I am hoping to code in a free spec here as well at some point. |
|
The failing test is |
| Fmat = create_fourier_design_matrix(t, nf) | ||
| # then get the solar wind chromatic part to multiply by |
There was a problem hiding this comment.
I see that this Fmat only includes the sin and cos components with fundamental frequency 1/Tspan. This will not fit the data well if there is a linear or quadratic variation in NE_SW. I will create a new PR adding this.
There was a problem hiding this comment.
These two things are independent code-wise.
There was a problem hiding this comment.
thanks for coding this in!!
i will try to get all of the tests passing on this PR so that we can get these both merged at the next git-flowers meeting
There was a problem hiding this comment.
i have thought about this more as well. it is great to have these polynomial fits in PINT, however, there are 2 reasons that i think they will not always be required with this model.
- the spectra will not always be very “red”. infact, i think Sai found that they are often blue. so I think the low frequency power is less important.
- DM1 and DM2 will probably absorb much of this since the solar wind is very covariant w DM at low frequencies. i think Caterina shows this in one of her papers.
There was a problem hiding this comment.
Ok... In any case I have implemented the NE_SW derivatives in another PR which is already merged. The user can use them if needed, but are not necessary.
| self.add_param( | ||
| floatParameter( | ||
| name="TNSWAMP", | ||
| units="", | ||
| aliases=[], | ||
| description="Amplitude of power-law SW DM noise in tempo2 format", | ||
| convert_tcb2tdb=False, | ||
| ) | ||
| ) | ||
| self.add_param( | ||
| floatParameter( | ||
| name="TNSWGAM", | ||
| units="", | ||
| aliases=[], | ||
| description="Spectral index of power-law " | ||
| "SW DM noise in tempo2 format", | ||
| convert_tcb2tdb=False, | ||
| ) | ||
| ) | ||
| self.add_param( | ||
| floatParameter( | ||
| name="TNSWC", | ||
| units="", | ||
| aliases=[], | ||
| description="Number of SW DM noise frequencies.", | ||
| convert_tcb2tdb=False, | ||
| ) | ||
| ) |
There was a problem hiding this comment.
I presume this only supports the inverse-squared radial variation of the solar wind. This corresponds to SWP=2 and SWM=1.
If this is correct, please add a validation step somewhere (I suggest in get_noise_basis or get_noise_weights) to ensure that this condition is met. If not, this component will be inconsistent with SolarWindDispersion.
There was a problem hiding this comment.
hi @abhisrkckl ,
i am trying to follow up with all of my open PRs since my term just ended. 😄
i don’t think this necessarily requires inverse-square solar wind variations, but i agree that we need some way to ensure the same SWP used in the noise run is being plugged into the timing model. i’m not entirely sure how to do this, but i will keep looking into it.
There was a problem hiding this comment.
One possibility is to check the SWM and SWP parameters and use them to determine how this mode will behave. Or if all of the SWM and SWP values are supported you can throw an error if the condition is not met. The main point is to avoid inconsistency between models.
No description provided.