Division by the zero stride produces ERROR: integer division or modulo by zero

[CACNYC]

Hey Mart,
Wanted to post this tile size issue I encountered when running a quick smoke test on a 1-GPU machine:

Issue:

Received ERROR: integer division or modulo by zero during small-tile smoke test.
The failure happens while calculating tiles, before the first tomogram tile is passed through the neural network.

Currently, easymode segment --help displays:

--tile TILE 
Inference tile size as ZxYxX (default 160x160x160).
Each dim is capped at the volume size.
Decrease if you run out of GPU memory; only affects 3D models.

easymode currently assigns a 48-voxel overlap on every active axis and calculates each stride as: stride = tile_size - 2 × overlap

So, for my small tile --tile 64x96x96:

Z: 64 - 2×48 = -32
Y: 96 - 2×48 =   0
X: 96 - 2×48 =   0

The tiler then calculates the number of boxes using integer division by those strides. Division by the zero Y or X stride produces: ERROR: integer division or modulo by zero

Command:

easymode segment ribosome \
--data "$SMOKE/input" \
--output "$SMOKE/segmented" \
--gpu 0 \
--tta 1 \
--tile 64x96x96 \
--apix 10.371 

Terminal output:

ribosome: using 3D model 
easymode segment feature: ribosome 
data_patterns: ['/home/chris/data/easymode/smoke/input'] 
output_directory: /home/chris/data/easymode/smoke/segmented 
output_format: int8 
gpus: [0] 
tta: 1 
overwrite: False 
batch_size: 1 
tile_size: (64, 96, 96) 
Found 1 tomograms to segment. 

Using model: /home/chris/data/easymode/cache/ribosome.h5, inference at 10.0 Å/px. 
GPU 0 - loading model (/home/chris/data/easymode/cache/ribosome.h5). 
GPU 0 - starting inference. 
1/1 (on GPU 0) - ribosome - TEM_10.37Apx.mrc - **ERROR: integer division or modulo by zero**

Segmentation finished! 
Please note that you can help improve easymode by reporting model failures with 'easymode report'

[mgflast]

Hey Chris,

Oops, that whole --tile thing was a quick and somewhat untested fix over a memory issue another user encountered. Bit of a dumb one, the tile size going negative :)

Fix will be up in a bit. Out of interest, why did you decide to set the tile size so much smaller? You don't need to factor the number of GPUs in to the tile size - workload is distributed over multiple GPUs simply by running multiple single-GPU threads which each process entire tomograms. I believe the default 160x160x160 should be fine on a >16 GB card.

[CACNYC]

Hey Mart,
No worries! I was only able to do some pilot testing one a 1-GPU (16GB) machine with 100GB RAM. And with segment I actually misinterpreted the tile size "directionality" -- I did not realize at the time that smaller tile size means more tiles loaded together, so the RAM went sky high. I wasn't really able to dial it in so that I could avoid either a GPU OOM or a RAM OOM, so I will test segment on another machine. denoise ran nicely though!