Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate use of write_path_template and read_path_template for mapping file systems between detector and filewriting mounts #290

Closed
DiamondJoseph opened this issue Aug 4, 2023 · 7 comments

Comments

@DiamondJoseph
Copy link
Collaborator

If read_path_template is set, this is validated by Ophyd and write_path_template is not.

Which is used to write the ResourceDocument? Can we use a non-matching pair to have the detector write to /data/foo and the filewriter write to /dls/data/foo?

@DiamondJoseph
Copy link
Collaborator Author

From talking with Eva, it is the Read Path that is used in the ResourceDocuments.

Although, this is not as helpful as I had wanted, as the root is still consistent between (with the assumption that root can be changed later so long as the non-root resource path is consistent).

TODO: Mapping between filewriting, detector mounts.

See also bluesky/ophyd#1143

@tacaswell
Copy link

The ReadPath and the root have to be consistent and are what go into the resource document. If you provide both, then write path is not validated.

https://github.com/bluesky/ophyd/blob/5c413cc0848ef035b9839de328064d6af47b589b/ophyd/areadetector/filestore_mixins.py#L115-L127

In retrospect it would have been clearer to require read path (and always validate it) and make write path the optional one if you have the same file system mounted differently in two places.

@tacaswell
Copy link

As an example (and the motivating case when we wrote this 😉 ) see

https://github.com/NSLS-II-PDF/profile_collection/blob/a9fe5d6987c39b0385d6c3e4429e31a7abfd20cc/startup/80-areadetector.py#L153-L163

which is an IOC that running on a windows machine so the paths look wildly different.

@DiamondJoseph
Copy link
Collaborator Author

We're looking at having IOCs running in containers on Kubernetes, with as little of the file system mounted as possible.
And a service for consuming documents and writing Nexus files, again on Kubernetes and mounting as little of the file system as possible.
But writing those files such that they are visible from the entire file system and portable.
I think eventually we're going to want something like

Staging sets root = "/%visit/"
write_path_template = "/data/%year/%month/%day"
read_path_template = "%experiment/"

Which we write as links into our output files as ./%experiment/file

@tacaswell
Copy link

read_path needs to be where the written file is visible to the consumer of the documents.

It is unrelated to where that downstream consumer is going eventually write derived output.

@callumforrester
Copy link
Collaborator

Pending bluesky/ophyd#1147

@DiamondJoseph
Copy link
Collaborator Author

Deprecated by use of ophyd-async and its DirectoryProvider, recent re-thinkings of StreamResource model.

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

No branches or pull requests

3 participants