I fear this is due to my insufficient knowledge how the position angle is defined. My expectation is that its definition can be deduced by the transformation between the reference frame of the PFS and the telescope itself.
I'd be grateful for a pointer to any related documents!

I will find out documents (if they exist...). For my reference, could you point out where you calculate the angle in the code please? (Sorry, I'm not a good C programmer...)

Sure!
All the code relevant to this problem is in ets_demo.cc itself. The position angle variables typically have "posang" in their names. (Throughout the code, angles are always stored in radians instead of degrees, since this is what the trigonometric functions expect.)
The function that transforms target coordinates from alt/az to a position on the PFI plane is targetToPFI(). Inside this function the position angle is called "psi" (I wrote that before I was familiar with the terminology ...)
My idea was that for a PA of 0, the "y" axis of the PFI coordinate is as close to the zenith direction as possible for the given telescope pointing. Of course this reasoning fails when the telescope is aiming directly at the zenith, so a more robust definition is certainly welcome.
If there are already some examples for PFI coordinates and their corresponding locations on the sky (given a PA and telescope pointing), that would be fantastic, since it would allow me to test the correctness of my implementation.

OK, I will check that in details.

Yes, it is true that y axis should point north if PA is 0, but the result does not seem to be so, if I plot the output RA and Dec...

I found that Maximilian may also know something. We should contact people in Subaru but he can directly ask to someone (for example Eric Jeschke-san).

Dear Yabe san, dear Martin,

reading the last two comment carefully, it seems that there is a misunderstanding.

Martin: PA = 0 is indeed straight North. Was that clear? The orientation of the angle is a bit less clear, but positive angle going east of North tends to be the standard. Note, this is the Position Angle. So, PA = 0 does not point to Zenith but Polaris (more or less).

This can be confused with the Parallactic angle. To avoid confusion people do *notP usually abbreviate the latter with "PA" but with "parang" or so.

Maximilian

Thank you for your inputs. I will try and digest the explanation over the weekend.

I think I got it... associating "PA=0" with "y axis points toward the zenith" was of course a naive conclusion. The celestial Pole makes a lot more sense.
It should not be very hard to adjust the code accordingly. With a bit of luck I'll get this done early next week.
Thanks again for all your inputs!

I have pushed a change that determines the PA relative to the celestial pole now. Tests indicate that the shape of the output FoV no longer depends on time and also appears to have the correct orientation.
The direction in which the PA is measured is still not clear to me. But if the current implementation turns out to be incorrect, this can be adjusted with only a minimal change.

Thank you, Martin. It seems that PFI X and Y coordinates change if we set the same position center and position angle but a different time (probably it depends on ALT). Did you take into consideration the atmospheric differential refraction? or the conversion between RA-Dec and X-Y depends on ALT now?

Yes, differential refraction is taken into account (as well as nutation and aberration). Is this sufficient to explain the shifts you see?
For the moment I do not model the elevation-dependent distortion of the image, which is described on the "conversion formula" slides. I just use some average, elevation-independent values to go from angles to x,y-coordinates.

I just verified that by switching refraction off (in the source code), the time-dependent shifts in x and y positions become much smaller. So it appears that differential refraction indeed causes most of the differences.
The remaining shifts are on the order of 1e-5 mm for two observations with two hours time difference. I cannot identify their origin at the moment, but they appear to be small enough to be ignored.

OK, thank you. Then, I think we are ready now for the distribution with this version.