-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
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 |
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. 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. |
As an example (and the motivating case when we wrote this 😉 ) see which is an IOC that running on a windows machine so the paths look wildly different. |
We're looking at having IOCs running in containers on Kubernetes, with as little of the file system mounted as possible. Staging sets root = "/%visit/" Which we write as links into our output files as ./%experiment/file |
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. |
Pending bluesky/ophyd#1147 |
Deprecated by use of ophyd-async and its DirectoryProvider, recent re-thinkings of StreamResource model. |
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?
The text was updated successfully, but these errors were encountered: