I'm currently testing this in a very naive way (see testcoord.py), by specifying some center Ra, Dec and requesting the PFI coordinates for exactly the same Ra, Dec. Unless I'm overlooking some correction, this should result in returned coordinates of (0., 0.), correct?

The unmodified code fails with:

Traceback (most recent call last):
  File "testcoord.py", line 15, in <module>
    testcoord()
  File "testcoord.py", line 10, in testcoord
    res = ctrans(np.array([[ra], [dec]]), 0., "sky_pfi", rotang, np.array([ra_c, dec_c]))
  File "/home/martin/codes/pfs_utils/python/pfs/utils/coordinates/CoordTransp.py", line 62, in CoordinateTransform
    xyin, inr, za1 = convert_in_position(xyin, za, inr, c, cent, time)
  File "/home/martin/codes/pfs_utils/python/pfs/utils/coordinates/CoordTransp.py", line 192, in convert_in_position
    za = za[0]
IndexError: invalid index to scalar variable.

It seems that line 192 is actually not necessary, so I commented it out.

After this change the code runs and returns the coordinates  (0.10197685, -0.05085649), which is fairly close to zero. Is there some coordinate offset I'm missing, or is this compatible with zero within the expected accuracy of the transform?

Another question: is it OK to leave the zenith angle parameter unset in this coordinate conversion mode? I think yes, because the code ovewrites it anyway. If so, I'd like to suggest giving it a default value of {{None }}and mention it in the docstring.

The shape of xyin apparently needs to be{{ (2, N)}}, rather than {{(N,2). }}Not sure whether the code or the documentation should be adjusted.

Performance seems to be roughly 30.000 coordinate transforms per second on my laptop, which might become a slight bottleneck for large source catalogs.

The inr argument doesn't appear to have any influence on the returned values. I would have expected that varying{{ inr}} from 0 to 360 would produce PFI coordinates that describe a circle around (0,0). Am I making an incorrect assumption?

• As for za and offsets at (0, 0), I'll look into it. (Actually (0, 0) in the WFC model don't usually go PFI (0,0), but your number is larger than expected at zenith...)
• Shape of xyin should be  (2,N), so I'll fix the document. I'm really sorry for confusion
• As for performance, to be honest, I don't have any idea about the requirement...
• For sky-to-pfi transformation, inr actually doesn't have any meaning, since (1) inr is calculated via astropy. As you expect, PFI coordinates rotates w.r.t inr, so you'll see stars rotate on PFI coordinates if you change the time... This made me realised that I didn't consider PA ... PA should be taken into account... correct? 

(Actually (0, 0) in the WFC model don't usually go PFI (0,0), but your number is larger than expected at zenith...)

I don't think I'm pointing at the zenith, so the numbers may be fine!

This made me realised that I didn't consider PA ... PA should be taken into account... correct?

Ahh ... thank you for pointing this out! I was looking for something PA-like, and `inr` seemed to be a good match, so I thought they were the same. Sorry for the confusion!

Yes, I think we will need PA support.

Concerning performance, I think we needn't worry about this at the moment. In any case I'll try to keep redundant calls to the absolute minimum.

Sorry to come back to this, but I just realized that I will most likely need the `pfi_sky` direction as well. Without access to this functionality, I'd have to query a region larger than a square degree when looking for guide star candidates, which will result in very large query results and may be rejected by the DB servers.

A rough approximation is currently sufficient for my purposes, so I can try to implement a first-order accurate solution as a workaround. But I'd still be happy of there was an official way to compute these transforms as well.

Is the `pfi_sky` transformation direction currently planned, and if so, what are the (rough) time scales?

Martin Reinecke would you mind discussing `pfi_sky` transformation in another ticket? If you agree, I'll file another.

Oh absolutely! Sorry for mixing up various different issues here.