file_number reset

[lyang11973]

line 434, set_and_wait(self.file_number, 0), under FileStorePluginBase.stage(), should be removed.

In some scans the same file name are used for multiple "passes". If the file_number is set to 0 every time, the resulting file will be over-written on the next pass. Resetting this number to 0 should be done explicitly. Or perhaps the file plugin could be configured to either reset the number or not when it is staged?

[mrakitin]

On each stage, the file name is generated from scratch: https://github.com/bluesky/ophyd/blob/82053af306815a4980aa4689a31d717f3234bd43/ophyd/areadetector/filestore_mixins.py#L424

That's where is generated: https://github.com/bluesky/ophyd/blob/82053af306815a4980aa4689a31d717f3234bd43/ophyd/areadetector/filestore_mixins.py#L416

and eventually comes from here: https://github.com/bluesky/ophyd/blob/82053af306815a4980aa4689a31d717f3234bd43/ophyd/areadetector/filestore_mixins.py#L44-L46

Then, that new file name is set, and the file number is reset for that new file name: https://github.com/bluesky/ophyd/blob/82053af306815a4980aa4689a31d717f3234bd43/ophyd/areadetector/filestore_mixins.py#L433-L434

I think the logic is correct here.

[lyang11973]

The assumption here is that the file name is re-generated every time the file plugin is staged. My application is a fly scan, in which the plugin, and its parent detector, is staged for each line in the fly scan. I would rather keep the file name the same. After all, that is why the file number is needed. In my opinion, the user should have the option to control how the plugin behaves, especially since this option is already provided by EPICS.

On Wed, May 12, 2021 at 2:58 PM Maksim Rakitin @.***> wrote:

On each stage, the file name is generated from scratch:

https://github.com/bluesky/ophyd/blob/82053af306815a4980aa4689a31d717f3234bd43/ophyd/areadetector/filestore_mixins.py#L424

That's where is generated:

https://github.com/bluesky/ophyd/blob/82053af306815a4980aa4689a31d717f3234bd43/ophyd/areadetector/filestore_mixins.py#L416

and eventually comes from here:

https://github.com/bluesky/ophyd/blob/82053af306815a4980aa4689a31d717f3234bd43/ophyd/areadetector/filestore_mixins.py#L44-L46

Then, that new file name is set, and the file number is reset for that new file name:

https://github.com/bluesky/ophyd/blob/82053af306815a4980aa4689a31d717f3234bd43/ophyd/areadetector/filestore_mixins.py#L433-L434

I think the logic is correct here.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bluesky/ophyd/issues/987#issuecomment-840022976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNJXDZQJYSINTSNSCCU25TTNLFVTANCNFSM44Y6RPJA .

[tacaswell]

The assumption here is that the file name is re-generated every time the file plugin is staged.

Correct. This is done exactly for the reason that you state to ensure that we never accidentally over-write data.

I would rather keep the file name the same.

If you want to have a common base, then override def make_filename. You will have to invent some mechanism for telling the detector it when it should pick a new base name and for making sure that you never produce duplicates. These filenames are not user facing anyway so I do not understand why it matters.

My application is a fly scan, in which the plugin, and its parent detector, is staged for each line in the fly scan.

It may also be worth investigating if we can only stage/unstage the detectors once as it can be an expensive process.

I am in favor of closing this with no action here and following up with @lyang11973 in his beamline profile.

[lyang11973]

If you want to have a common base, then override def make_filename.

I did do that. But now I have to override the entire base plugin to get around the file number issue.

It may also be worth investigating if we can only stage/unstage the detectors once as it can be an expensive process.

I certainly agree. The downside is that if something happens to the flyer, it may be more time-consuming to recover the detector.