Sign convention for detector distance

[apeck12]

Has the convention of what’s considered a positive versus negative detector distance changed? A PnCCD detector initialized from the current example .geom file (amo86615/PNCCD::CalibV1/Camp.0:pnCCD.1/geometry/0-end.data) has a negative distance:

detector = ps.PnccdDetector(geom = geom_file, beam = beam)
print(f"Detector distance is: {detector.distance:.2f} m")
Detector distance is: -0.58 m

Looking through example scripts, it looks like this detector distance was used previously. However, when computing the intensity field using detector.get_intensity_field, it seems that a positive detector distance yields the correct diffraction pattern (centrosymmetric, with intensity decreasing at high q) while the negative distance does not. @fredericpoitevin mentioned that orientation conventions in psana might have changed recently (thanks for the tip!). I find similar results for the PnCCDDetector class and a non-psana style SimpleSquareDetector, but I'm not sure if psana could affect conventions elsewhere in the code.

On the other hand, it seems like this is reversed for the calculated Compton scattering (calculate_compton in diffraction.py). In this case, a negative detector distance results in decreasing intensity as a function of q:

In addition, it looks like computing the intensity field using either calculate_molecular_form_factor_square in diffraction.py or detector.get_intensity_field (which calls the gpu code) yields different results, as shown below. In this case the patterns were calculated with a positive detector distance.

For completeness, here are the results using a negative detector distance:

[chuckie82]

Unfortunately, new detector distance definition has been introduced. There's psana frame and lab frame definitions.

I think this is causing psgeom to fail as well. I haven't had much time to look into this today.

[apeck12]

To follow up on this, loading the geometry file using the lab rather than the default psana coordinate frame doesn’t consistently resolve the issue. For the CsPad, forcing the detector distance to be positive seems to correct this, though I’m not sure if that unintentionally changes the coordinate system from right to left-handed.

@chuckie82, regarding the IP convention, what should be done when the geometry file has an IP z distance that is negative or zero? Should the detector distance be multiplied by -1, or does this need to be loaded using the psana coordinate frame to maintain handedness? In the case of the CsPad example above, the IP z-distance is 0 and the detector distance is negative. The other geometry files assessed for the above plot have positive IP z-distances. (Mikhail's email indicated that sign flipping was performed while loading constants as needed, so my interpretation is that in GeometryAccess that's performed upstream of defining the system's handedness. So, merely flipping the sign of the detector distance in pysingfel, which is downstream of GeometryAccess, might unintentionally switch the handedness.)