Using miniscoPy on Windows/Miniconda

[DenisPolygalov]

Hi, I can confirm that it is possible to install miniscoPy on Windows from within Miniconda environment. There are few differences and issues however. Regarding installation – the pyav package is easier to install than on Linux. In addition some package names are different, so you can use this command:

(miniscoPy) ... > conda install av scipy matplotlib jupyter pandas cython scikit-learn scikit-image h5py opencv tqdm future psutil

Another difference is that yaml is not available in conda (or I couldn’t find right name) so I end up installing PyYAML from pip:

(miniscoPy) ... > pip install PyYAML

The command above need to be executed from within Miniconda’s virtual environment you use for the miniscoPy. The bigger problem however is that resulting environment and miniscoPy code (main_cnmf_e.py) doesn’t work under Windows beyond motion correction part. The cnm.fit(procs) call just hangs after some time consuming 100% CPU time and never returns even after 12 hours. By the way – CaImAn’s code doesn’t work on Windows too, with very similar problem. One possible reason is that code in the main_cnmf_e.py is not guarded by if (__name__ == ‘__main__’): which is essential for parallel processing. Unfortunately fixing that didn’t solve the problem…
I understand that you using Ubuntu as your development environment but different behavior on different platforms is a warning sign of somthing going not so well. Also, I'd like to thank you for stripping down CaImAn which is itself one big mess.

Regards, Denis

[DenisPolygalov]

Seems like this is a bug in numpy and/or interaction between OpenBLAS and numpy: https://github.com/numpy/numpy/issues/11041 https://github.com/numpy/numpy/issues/4813 https://github.com/numpy/numpy/issues/654

but in my case playing with these variables didn't work: os.environ['MKL_NUM_THREADS'] = '1' os.environ['OPENBLAS_NUM_THREADS'] = '1' os.environ['KMP_INIT_AT_FORK'] = 'FALSE' os.environ['MKL_THREADING_LAYER'] = 'TBB'

A general solution here is to start writing test scripts by using Python's builtin unittest module for example... Are you willing to accept pull requests?

[RaphaelLavoie]

I personally installed it on both windows 7 and windows 10, using Anaconda instead of Minisconda. I also installed Visual Studio 2017.

I don't know where it was installed from (prerequisite from another package?) but I do have the yaml package installed in my environments.

To add av, I had to add the conda-forge channel.

Right now main_cnmfe_e.ipynb works with the example video and small list of videos of my own, but I often encounter memory issues when I reach the visualization cell (gonna test the last update today).

[gviejo]

Hello Denis,

Thanks for trying miniscoPy. Keep in mind that I am still testing it. But I appreciate the feedback.

Concerning the yaml package, it is not totally indispensable. You can replace it with a pickle or design your own way of loading the parameter file as a dictionnary.

Concerning OpenBLAS and numpy, it is effectively a problem for parallelism and here is what I have understood :

• there are some linear algebra function in numpy that calls the OpenBLAS library which use all cores by default. That's what you try to correct with os.environ['OPENBLAS_NUM_THREADS'] = '1'.

• if you call in parallel those linear algebra function with a number of threads > 1, you end up in a deadlock with all parallel jobs taking much more time than needed. Each python job is probably competing for the resource of the BLAS library.

-> therefore, I made the trade-off to fit each patch of the movie sequentially. So each call of the numpy linear algebra functions uses as many threads as possible and possibly finish faster than with 1 thread. But of course, each patch is fitted one after the other. Yet, it is likely more simple. Otherwise, the h5py parallel (for storing the output of each patch) would have been needed as well which can be difficult to install and probably even less friendly for windows users.

Now all of this is for linux. I am not sure if it is your problem for windows. But it is probably a bad mixing between multiprocessing and OpenBLAS. Right now, the cnmf_e doesn't do any parallelism except from the one of OpenBLAS. What you can try is replace

c, procs, n_processes = setup_cluster(backend='local', n_processes=8, single_thread=False)

with

#c, procs, n_processes = setup_cluster(backend='local', n_processes=8, single_thread=False)
procs = None

While the motion correction might be slower, it should still work. If the motion correction is really too slow, you can terminate the multiprocessing

procs.terminate()
procs = None

before starting

cnm.fit(procs)

If that doesn't work, I will try it myself on windows to locate the error.

Best Guillaume

[gviejo]

@RaphaelLavoie

Hey Raphael, The memory error should be fixed. Can you keep me updated if it work for you now?

[DenisPolygalov]

The issue of hanging Python code in numpy.linalg.inv() call was caused by simply executing conda upgrade --all Doing that lead to installation openblas which fight with Python. Setting os.environ['OPENBLAS_NUM_THREADS'] = '1'. doesn't help. At least in my case. So I just re-create new environment. Feel free to close this.