Skip to content
This repository has been archived by the owner on Dec 16, 2022. It is now read-only.

AD_Acquire, clarify the meaning of the path kwarg #293

Open
prjemian opened this issue Jun 23, 2022 · 7 comments
Open

AD_Acquire, clarify the meaning of the path kwarg #293

prjemian opened this issue Jun 23, 2022 · 7 comments
Assignees

Comments

@prjemian
Copy link
Collaborator

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:

yield from update_metadata_postscan()
hdf_with_fullpath = make_hdf5_workflow_filename()
print(f"HDF5 workflow file name: {hdf_with_fullpath}")
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 #292 (comment)

@prjemian prjemian self-assigned this Jun 23, 2022
@prjemian
Copy link
Collaborator Author

@qzhang234 which branch should I use?

@qzhang234
Copy link
Collaborator

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

@qzhang234
Copy link
Collaborator

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
Copy link
Collaborator Author

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:

write_path_template=str(LAMBDA2M_FILES_ROOT / IMAGE_DIR),
read_path_template=str(BLUESKY_FILES_ROOT / IMAGE_DIR),

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:

LAMBDA2M_FILES_ROOT = PurePath("/extdisk/2022-2/bluesky202205/")
BLUESKY_FILES_ROOT = PurePath("/home/8ididata/2022-2/bluesky202205/")
# IMAGE_DIR = "%Y/%m/%d/"
IMAGE_DIR = ""

@prjemian
Copy link
Collaborator Author

In #292 (comment),

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

@prjemian
Copy link
Collaborator Author

This use:

write_path_template=str(LAMBDA2M_FILES_ROOT / IMAGE_DIR),
read_path_template=str(BLUESKY_FILES_ROOT / IMAGE_DIR),
is an initial configuration of the detector.

Later (in the AD_Acquire plan)

we use the same file_path term (derived from the path kwarg) to define the detector's write path

areadet.staging_setup_DM(file_path, file_name,
num_images, acquire_time, acquire_period)

and the DM workflow path:

def make_hdf5_workflow_filename():
path = file_path
if path.startswith("/data"):
path = os.path.join("/", "home", "8ididata", *path.split("/")[2:])
logger.debug(f"modified path: {path}")
if not os.path.exists(path):
os.makedirs(path)
logger.debug(f"created path: {path}")

Note the code that adjusts the path for the DM workflow:

if path.startswith("/data"):
path = os.path.join("/", "home", "8ididata", *path.split("/")[2:])

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
Copy link
Collaborator Author

prjemian commented Jun 24, 2022

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants