AD_Acquire, clarify the meaning of the path kwarg

[prjemian]

In AD_Acquire there is a path kwarg that is used to set the path the detector uses to write image files and also the path that bluesky will write the DM workflow file. Can't do that since the Lambda2M does not have the same filesystems as the bluesky workstation. Execution fails here: https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L295-L297 with a permissions error. Suggest refactoring with pathlib and consider det.hdf1.read_path_template and det.hdf1.write_path_template. Also, clarify the meaning of the path kwarg (IOC or Bluesky sense).

Originally posted by @prjemian in https://github.com/aps-8id-dys/ipython-8idiuser/issues/292#issuecomment-1164977581

[prjemian]

@qzhang234 which branch should I use?

[qzhang234]

@prjemian I just pushed today's change to 150-Lambda2M

[qzhang234]

Also I'm very confused about det.hdf1.read_path_template, det.hdf1.write_path_template, LAMBDA2M_FILES_ROOT and BLUESKY_FILES_ROOT. What are these for and why do we need all four of them?

Currently LAMBDA2M_FILES_ROOT and BLUESKY_FILES_ROOT are hard-coded, which is fine for testing but will for sure cause problems if we start to operate like this

[prjemian]

The read_path_template and write_path_template are from ophyd's area detector support and describe configurations for databroker and the area detector IOC, respectively, to coordinate the directory containing image files. Particularly:

    ``write_path_template`` must always be provided, only provide
    ``read_path_template`` if the writer and reader will not have the
    same mount point.

We satisfy this requirement: https://github.com/aps-8id-dys/ipython-8idiuser/blob/62b18cebf8a27efe25934bd65493c0ca9b4c2612/profile_bluesky/startup/instrument/devices/ad_lambda2M.py#L239-L240

Since that use is located in the middle of the very long python file, and that use is very important to the instrument team to understand, these definitions are made near the top of the file: https://github.com/aps-8id-dys/ipython-8idiuser/blob/62b18cebf8a27efe25934bd65493c0ca9b4c2612/profile_bluesky/startup/instrument/devices/ad_lambda2M.py#L27-L30

[prjemian]

In https://github.com/aps-8id-dys/ipython-8idiuser/issues/292#issuecomment-1164978334,

I think we want path in AD_Acquire to be consistent with Bluesky sense (/home/8ididata/2022-2/****)

[prjemian]

This use: https://github.com/aps-8id-dys/ipython-8idiuser/blob/62b18cebf8a27efe25934bd65493c0ca9b4c2612/profile_bluesky/startup/instrument/devices/ad_lambda2M.py#L239-L240 is an initial configuration of the detector.

Later (in the AD_Acquire plan) https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L26

we use the same file_path term (derived from the path kwarg) to define the detector's write path https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L90-L91

and the DM workflow path: https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L123-L130

Note the code that adjusts the path for the DM workflow: https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L125-L126

But we have not anticipated the area detector write path would begin with /extdisk/. That's the root cause of the problem we saw yesterday.

[prjemian]

My analysis: this code could will be easier to manage if the file paths were made more obvious to their functions.