Very loosely deterministic chunk shape

[vigji]

The exact same settings can result in a very broad range of chunk sizes (one order of magnitude). Two subsequent acquisitions produced:

"shape_full": [18000, 12, 248, 552], "shape_block": [20, 12, 248, 552]

and

"shape_full": [18000, 12, 248, 552], "shape_block": [143, 12, 248, 552]

It is not a problem per se but the first option produces way more files than I would expect to be required for these settings

[diegoasua]

Ok so this might be a bug seeing that both rois are equally big. I'll check this

[diegoasua]

So I now partially understand what happened. The default chunk_size is 20. For some reason in the first recording it didn't update the chunk size.I was tempted to say that it did not receive from Stytra the duration but then the actual number of volumes is right so that can't be.

Which of the two run first? The correct one is 143 volumes per file (~450 MB in RAM per chunk)

[vigji]

Almost all my stacks (8/10) have 20, 2 have the correct value of 143; they where all acquired consecutively in the same way without closing the program

[diegoasua]

After some research I noticed this happens for one of the two reasons #52 is failing as well. The single-button start has caused this problem by not letting some time for the software to get the duration from stytra, calculate the file size and start saving. The reason why the duration does not fail as well is that it is not used to calculate the chunk size, just to know when to stop saving so it can arrive later on. Introducing a timeout of 500 milliseconds between experiment preparation and experiment toggling as suggested in that same thread solves the issue. I will just add this line https://github.com/portugueslab/lightsheet_take_two/issues/52#issuecomment-659406695 and this should resolve both issues for now.

[diegoasua]

I am closing this issue as this has been resolved