Closed loftusa closed 10 months ago
You might be running out of RAM, try reducing n_processes
when you create the dview
. This reduces RAM usage as well because fewer patches will run simultaneously.
@kushalkolar I tried reducing to 32, and then 16 processes on a system with 72 CPUs and 100GB of RAM, using CNMF. Still hangs just as much.
one weird thing I'm noticing is we have p
twice in our params. This is bad. It's in temporal
and preprocessing
, and in your temporal
(which is more the canonical field) it is currently set to 0.
This is asking for trouble though (on our part not yours, but by association now yours :smile:)
I would test it first with both P's set to the same value, and set p_patch
to 0 because that's a p most people don't mess with.
Then set p
to 0 and p_patch
to positive val and see what happens.
If it still hangs after all this (and I'd do all this with a short demo movie because I assume you have some megamovie), then I'd set dview
to None
and run with logging level set to DEBUG
and see what's going on in the various permutations that work, and don't work, to find where the one(s) that don't work go awry.
Note I will try to reproduce this today and edit this reply with result.
Edit: I wasn't able to reproduce the problem. IN the demo notebook, I had temporal.p
and proprocess.p
set to 2. I also tried with the first set to 0 and second to 2, and my code ran.
For debugging, I recommend following the steps I suggested above (starting with a small demo movie to see if this is a memory issue). How big is your movie (how much memory, and dims?). Does it run on this movie when you use default params?
Hi @EricThomson !
So, yesterday I did some time-profiling to get to the bottom of this.
Using your demo pipeline, p=0, with your demo data, runtime was the following:
Using your demo pipeline, p=1:
For p=2:
Then I switched to my own data (657x657, 601 frames). When I used only the demo pipeline, with no other settings changed, and only swapped in my own data, we ran -- albeit slowly.
Each of our full TIF stacks is actually 3005 frames, but they include five recording periods. So I think the original problem was that, trying to run on the entire 3005 at once, it took so long that it seemed like it was hanging.
The actual pipeline we are developing includes running separately on each of the five recording periods individually, then using multisession_registration
to combine them. Here are runtimes when I split the full 3005 frames into 5x601 frames, and then just ran the full pipeline with a for-loop on each 601-length movie. This is with n_processes=64
and ssub, tsub both set to 2 (so I was downsampling this time):
You can see that the first two movies each took 232 seconds and 163 seconds respectively (which I think is very reasonable), but then we had the third, fourth and fifth movies take 1,315, 2,241, and 10,705 seconds respectively (roughly 3 hours).
Each of the movies should be exactly the same: 601 frames at 657x657 resolution.
Here are the parameters I was using for the last pipeline:
# CHANGED VALUES
# dataset dependent parameters
fr = 10 # imaging rate in frames per second
decay_time = 1.8 # length of a typical transient in seconds
# motion correction parameters
strides = (48, 48) # start a new patch for pw-rigid motion correction every x pixels
overlaps = (24, 24) # overlap between pathes (size of patch strides+overlaps)
max_shifts = (5, 5) # maximum allowed rigid shifts (in pixels)
max_deviation_rigid = 3 # maximum shifts deviation allowed for patch with respect to rigid shifts
pw_rigid = False # flag for performing non-rigid motion correction
# parameters for source extraction and deconvolution
p = 2 # order of the autoregressive system
gnb = 1 # number of global background components
merge_thr = 0.85 # merging threshold, max correlation allowed
rf = 30 # half-size of the patches in pixels. e.g., if rf=25, patches are 50x50
stride_cnmf = 12 # amount of overlap between the patches in pixels
K = 10 # number of components per patch
gSig = [4, 4] # expected half size of neurons in pixels
gSiz = tuple(4*np.array(gSig)+1)
method_init = 'greedy_roi' # initialization method (if analyzing dendritic data using 'sparse_nmf')
ssub = 2 # spatial subsampling during initialization
tsub = 2 # temporal subsampling during intialization
# parameters for component evaluation
min_SNR = 2.0 # signal to noise ratio for accepting a component
rval_thr = 0.85 # space correlation threshold for accepting a component
cnn_thr = 0.99 # threshold for CNN based classifier
cnn_lowest = 0.1 # neurons with cnn probability lower than this value are rejected
min_size = np.pi*(gSig[0]/1.5)**2
max_size = np.pi*(gSig[0]*1.5)**2
# parameters for multiprocessing
n_processes = 71
Oh, lastly, I also tried my own data with the for-loop, with p=0 (deconvolution turned off). I had a fairly reasonable 18 minute runtime (values are in units of seconds)
@loftusa is this issue still a problem, or are things ok? I figured it was clearly a memory problem, not sure how you fixed it if you did! 😄
Closing due to inactivity.
Hi all,
I ran through the demo pipeline here with a few changed parameters.
I am running on a remote system with 32 cores and 100GB of memory and a GPU. When I run
and deconvolution was turned on instead (e.g., set
p=2
), the run hung for about 3 hours before I killed it. If this is intentional, there should likely be an error message preventing the pipeline to run at this point.I tried messing around with
p_patch
as well, but that was withp=2
still.Here is my
opts
: