Simplify interface, allow for PSRFITS, easier RMextract install?

[dlakaplan]

Hi, Cameron. Bryan Gaensler pointed me to this module. Thanks for fixing the doc build.

I am trying to get some RM prediction software working. Probably a smaller/simpler use case than what you are doing since it will be applying it to PSRFITS files rather than CASA ms files, so all of that is handled internally. I just want the prediction.

There are 3 broad issues that I am looking into:

1. RMextract is proving difficult to install on my M1 Mac. I know many compiled modules are difficult. I think it's due to building the various C/Fortran sub-modules. As far as I can tell, the only one I need is the EMM/WMM, but even that is taking hours. There is a newer (almost) pure python WMM library: https://github.com/space-physics/wmm2020 I suggested it to the RMextract people to see if they have the time to replace what is in their module. Not sure if this is a priority for them or not. I likely don't have time to do that (verify geometry/signs/...) but if you do or find any luck with simplifying the installation, I would be interested to know.

I also have been making some tweaks to RMextract to remove print statements and use a single logging interface. Still not done but it works better.

2. I wanted a very simple interface that would use more astropy for coordinates, sites, times, etc. Some of that is there in your module but it's a little variable. So I'm working on: https://github.com/dlakaplan/simpleRM as a separate module. Still not ready, but if it's of interest I'd be happy to somehow move some of this simpler functionality to your module.

3. Instead of basing things on CASA files, this is for the pulsar case with PSRFITS. I'm using: https://github.com/mtlam/PyPulse for that interface. Again, still not done, but if it's of interest that could also go into your module.

I realize that this is 3+ issues and a log submission, but I thought it was the easiest way to start a conversation. Thanks.

[Cameron-Van-Eck]

Hi David:

Thanks for getting in touch, and sorry about the previous problems with the docs.

In terms of the RM-extract install, I can sympathize; I've also struggled with it off-and-on, although my problems have been more on the casacore aspect rather than the WMM side, for whatever reason. The unfortunate consequence of writing a wrapper around someone else's package is that I have limited ability to work around problems in with that package.

I'm certainly happy to make FRion more Astropy-aware/compatible. Seeing your use of EarthLocation.of_site(args.site) in your simpleRM example has left me slightly embarrassed that I didn't think to use that myself. I'm also happy to incorporate/add a function to output RM vs time into a text file. Adding functionality to read observation parameters from a PSRFITS file also appears straightforward enough, given the example you've given. Applying a correction to data in a PSRFITS file I'm less comfortable with, given my limited knowledge of PSRFITS and that I'm currently a little over-saturated with POSSUM tasks. But I'd be happy to accept a pull request or incorporate example code if you or someone else develops that functionality.

Making those changes should be fairly straightforward, and I should have some time soon (i.e., the next week or two) to work on that. Are you OK with me direct raiding your simpleRM code to incorporate those features?

Cheers, Cameron

[dlakaplan]

Thanks, Cameron. Definitely sympathize with casacore: I used to have to get that working over and over again, and for the moment I am happy to avoid it.

Feel free to raid what I wrote if it's helpful. Let me know if you have any questions.

No need to add PSRFITS correction code: that's handed internally within psrchive. The main thing is to get the numbers.

[dlakaplan]

P.S. Some obvious radio telescopes aren't in the astropy sites library. Parkes, MeerKAT, LOFAR, maybe others. I know MWA is, so maybe that's enough for ASKAP for this purpose. but I think we could also do some PRs to astropy to fix this.

[Cameron-Van-Eck]

You read my mind, I was thinking of doing exactly that (I was thinking mostly about ASKAP, but if you happen to have coordinates handy for the others, it would save me time looking then up if I do them all in one go).

[dlakaplan]

I'm dumping a bunch from PINT as I type (on a boring call...)

[dlakaplan]

https://github.com/astropy/astropy-data/pull/125

[Cameron-Van-Eck]

Hi David:

I've gone ahead and implemented some updates to the predict module:

• all the inputs should now be compatible with appropriate Astropy quantities (times, angles, etc.)
• PSRFITS files now supported for determining input parameters (as best as I can tell; I have only a few examples to test with).
• New functions to generate and save RM vs time.

It's also now released on PyPi for easy install with pip.

Whenever you have time to check it out, let me know what you think and if there's anything else that you think would be useful.

Cheers, Cameron

[dlakaplan]

Thanks, Cameron. I'll check it out when I have a minute.

I recently also added support for another type of pulsar observation. This one (unfortunately) is a lot less documented. I basically had to copy the C header file and use it to parse the binary input. Not sure if you want to go that far but if you do let me know.

[Cameron-Van-Eck]

Hi David:

I think that's getting far enough from the core/unique purpose of FRion (the time-averaged ionosphere corrections) that I can't really justify putting more time into it in the short term. I'd be happy to incorporate support for PSARCHIVE/Timer files, but someone else would have to put together a pull request to add that.

Cheers, Cameron

[dlakaplan]

Yes, that makes sense. I was just telling you what I was up to.