QU-fitting Stokes I model failing for many double-component RM models (m11 and m4)

[arieljedimaster]

Quick Summary:

• I’m using qufit to run a bunch of models on ~60 polarized spectra.
• For the majority of my sources, the Stokes I model generated by qufit seems to be failing, with the model coefficients being defined as the following in the output files:
  • Imodel=0.0,0.0,0.0,0.0,0.0,1.0
• For the exact same sources, this doesn’t occur when running any of the single-component models.
• The result of this is we have a fractional polarization fit that is extremely low and doesn’t represent the source well, but the shape seems reasonable, and the fit polarization angle modelling the data seems to describe the data pretty well.

More details:

• I double-checked that I was inputting the exact same text file to RM tools for the single component models, and the component models and I still get this weird issue with the Stokes I model.
• For these models where the Stokes I model seems to fail, we get something reasonable for a reduced chi^2, indicating a good fit.
• I re-ran the double component models, and the same error occurred the second time around.
• I’m attaching here plots of a source where we modelled m1 and m11, and their output model files, where we are seeing this issue (but note that we are seeing this for most sources). I can provide other examples if necessary.

  • I see this issue with m11 and m4, whereas m1 and m2 both look okay, but I'm attaching the simpler m11 and m1 models here since it might be easier to figure out what's going on with the simpler case.

0345-5036.m11.nestle.txt 0345-5036.m1.nestle.txt

[AlecThomson]

Hey @arieljedimaster - would you be able to provide a minimal reproducible example for us to investigate? If you'd be willing to share, it'd be great to have a spectrum that produces this behaviour, along with either the command-line arguments or the python script you used to get the issue. Thanks!

[Cameron-Van-Eck]

Closing this, since Ariel told me she discovered this was user error rather than a program problem, and I haven't heard anything since.

[arieljedimaster]

Agh, so sorry guys! I forgot to mark this as closed! It was definitely a user error.

I have found that for the multi-component models (m11 and m4) I’ve not been able to get many of my sources to converge for these models using “nestle” (and it takes a VERY long time to run), so I’ve had to switch back to using pymultinest which seems to converge for my sources. Is this something that other people are finding as well for the double-component models in RM-Tools?

All the best,

Ariel

Ariel Amaral PhD Candidate University of Toronto David A. Dunlap Department of Astronomy & Astrophysics Dunlap Instiutute of Astronomy & Astrophysics @.**@.>

On Apr 2, 2023, at 9:18 PM, Alec Thomson @.**@.>> wrote:

You don't often get email from @.**@.>. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification

Hey @arieljedimasterhttps://github.com/arieljedimaster - would you be able to provide a minimal reproducible example for us to investigate? If you'd be willing to share, it'd be great to have a spectrum that produces this behaviour, along with either the command-line arguments or the python script you used to get the issue. Thanks!

— Reply to this email directly, view it on GitHubhttps://github.com/CIRADA-Tools/RM-Tools/issues/81#issuecomment-1493503395, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE2LDYTNDRSSQ5553YIWAOLW7IQMZANCNFSM6AAAAAAWO54TGA. You are receiving this because you were mentioned.Message ID: @.***>

[Sebokolodi]

Hi Ariel,

Yes, during the POSSUM week this year January 2023, Yik Ki (Jackie) Ma encountered this issue. I believe it is still under investigation.