From gael.varoquaux at normalesup.org Thu Dec 1 00:59:42 2016 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 1 Dec 2016 06:59:42 +0100 Subject: [Neuroimaging] Python 3 statement In-Reply-To: References: Message-ID: <20161201055942.GA3589337@phare.normalesup.org> I think that this is taking the problem by the wrong end. It's using the stick rather than the carrot. If people have no other arguments to convince to move to Python 3 than the fact that support is going to end, users are not going to think much of us. No, the right way is to convince the ecosystem, mainly Afni and FSL that they should be using Python 3. I tried for FSL. I don't know if I was successful. What would be important is to outline the great things that can be done with Python 3, to convince people writing code that they would be more productive in Python 3. Possibly, if a feature is much easier to be implemented in Python 3 than Python 2, than you should code that feature only for 3. Think in terms of users, not developers. It really defeats me than no argument on that page is about how great Python 3 is. This looks like planned obsolescence. Why should users rewrite code if their life is not getting better? The risk, by the way, is simply that they will stick with old versions of the projects for quite a while. Ga?l PS: I am all in favor of Python, and all my code is Python-3 compatible. On Wed, Nov 30, 2016 at 06:58:48PM -0800, Ariel Rokem wrote: > Hello everyone,? > I just learned about this statement this morning: > http://www.python3statement.org/ > What do folks here think about this? Should we sign on to this?? > Cheers,? > Ariel > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -- Gael Varoquaux Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.info http://twitter.com/GaelVaroquaux From pi at berkeley.edu Thu Dec 1 12:49:34 2016 From: pi at berkeley.edu (Paul Ivanov) Date: Thu, 1 Dec 2016 09:49:34 -0800 Subject: [Neuroimaging] Python 3 statement In-Reply-To: <20161201055942.GA3589337@phare.normalesup.org> References: <20161201055942.GA3589337@phare.normalesup.org> Message-ID: I don't recall who it was, but I read someone else equating that statement site to the stick approach, and offering https://python-3-for-scientists.readthedocs.io/en/latest/ as the corresponding carrot. Much love to all of you, ? On Wed, Nov 30, 2016 at 9:59 PM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > I think that this is taking the problem by the wrong end. It's using the > stick rather than the carrot. If people have no other arguments to > convince to move to Python 3 than the fact that support is going to end, > users are not going to think much of us. > > No, the right way is to convince the ecosystem, mainly Afni and FSL that > they should be using Python 3. I tried for FSL. I don't know if I was > successful. > > What would be important is to outline the great things that can be done > with Python 3, to convince people writing code that they would be more > productive in Python 3. Possibly, if a feature is much easier to be > implemented in Python 3 than Python 2, than you should code that feature > only for 3. > > Think in terms of users, not developers. It really defeats me than no > argument on that page is about how great Python 3 is. > > This looks like planned obsolescence. Why should users rewrite code if > their life is not getting better? > > The risk, by the way, is simply that they will stick with old versions of > the projects for quite a while. > > Ga?l > > PS: I am all in favor of Python, and all my code is Python-3 compatible. > > On Wed, Nov 30, 2016 at 06:58:48PM -0800, Ariel Rokem wrote: > > Hello everyone, > > > I just learned about this statement this morning: > > > http://www.python3statement.org/ > > > What do folks here think about this? Should we sign on to this? > > > Cheers, > > > Ariel > > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > > -- > Gael Varoquaux > Researcher, INRIA Parietal > NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France > Phone: ++ 33-1-69-08-79-68 > http://gael-varoquaux.info http://twitter.com/GaelVaroquaux > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -- _ / \ A* \^ - ,./ _.`\\ / \ / ,--.S \/ \ / `"~,_ \ \ __o ? _ \<,_ /:\ --(_)/-(_)----.../ | \ --------------.......J Paul Ivanov http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Dec 1 12:54:44 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 1 Dec 2016 09:54:44 -0800 Subject: [Neuroimaging] Python 3 statement In-Reply-To: References: <20161201055942.GA3589337@phare.normalesup.org> Message-ID: Yo, On Thu, Dec 1, 2016 at 9:49 AM, Paul Ivanov wrote: > I don't recall who it was, but I read someone else equating that statement > site to the stick approach, and offering > https://python-3-for-scientists.readthedocs.io/en/latest/ as the > corresponding carrot. But - I agree with Gael, I think it breaks our contract with our users to use a stick on them, carrot or no. Cheers, Matthew From elef at indiana.edu Thu Dec 1 13:10:34 2016 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Thu, 01 Dec 2016 18:10:34 +0000 Subject: [Neuroimaging] Python 3 statement In-Reply-To: References: <20161201055942.GA3589337@phare.normalesup.org> Message-ID: Nice link. Thanks Paul. Also, to say here that DIPY is Python 3 compatible too. We are just waiting for VTK 7+ (which supports Python 3) which is already released to be forwarded to the most common packaging systems (e.g. Anaconda, Debian etc.) and then we can suggest to people to start moving to Python 3 safely. That should happen relatively soon for Anaconda I hope. Maybe it will take a bit more time for Debian. Finally, I think the link posted by Ariel all is trying to do is help inform the distributors and developers to move forward with the change. I am +1 to include DIPY in this list. Cheers, Eleftherios On Thu, Dec 1, 2016 at 12:50 PM Paul Ivanov wrote: I don't recall who it was, but I read someone else equating that statement site to the stick approach, and offering https://python-3-for-scientists.readthedocs.io/en/latest/ as the corresponding carrot. Much love to all of you, ? On Wed, Nov 30, 2016 at 9:59 PM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: I think that this is taking the problem by the wrong end. It's using the stick rather than the carrot. If people have no other arguments to convince to move to Python 3 than the fact that support is going to end, users are not going to think much of us. No, the right way is to convince the ecosystem, mainly Afni and FSL that they should be using Python 3. I tried for FSL. I don't know if I was successful. What would be important is to outline the great things that can be done with Python 3, to convince people writing code that they would be more productive in Python 3. Possibly, if a feature is much easier to be implemented in Python 3 than Python 2, than you should code that feature only for 3. Think in terms of users, not developers. It really defeats me than no argument on that page is about how great Python 3 is. This looks like planned obsolescence. Why should users rewrite code if their life is not getting better? The risk, by the way, is simply that they will stick with old versions of the projects for quite a while. Ga?l PS: I am all in favor of Python, and all my code is Python-3 compatible. On Wed, Nov 30, 2016 at 06:58:48PM -0800, Ariel Rokem wrote: > Hello everyone, > I just learned about this statement this morning: > http://www.python3statement.org/ > What do folks here think about this? Should we sign on to this? > Cheers, > Ariel > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -- Gael Varoquaux Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.info http://twitter.com/GaelVaroquaux _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -- _ / \ A* \^ - ,./ _.`\\ / \ / ,--.S \/ \ / `"~,_ \ \ __o ? _ \<,_ /:\ --(_)/-(_)----.../ | \ --------------.......J Paul Ivanov http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at onerussian.com Thu Dec 1 14:02:15 2016 From: lists at onerussian.com (Yaroslav Halchenko) Date: Thu, 1 Dec 2016 14:02:15 -0500 Subject: [Neuroimaging] Python 3 statement In-Reply-To: <20161201055942.GA3589337@phare.normalesup.org> References: <20161201055942.GA3589337@phare.normalesup.org> Message-ID: <20161201190215.coi3wwwkho4rhuli@hopa.kiewit.dartmouth.edu> On Thu, 01 Dec 2016, Gael Varoquaux wrote: > I think that this is taking the problem by the wrong end. It's using the > stick rather than the carrot. If people have no other arguments to > convince to move to Python 3 than the fact that support is going to end, > users are not going to think much of us. > No, the right way is to convince the ecosystem, mainly Afni and FSL that > they should be using Python 3. I tried for FSL. I don't know if I was > successful. > What would be important is to outline the great things that can be done > with Python 3, to convince people writing code that they would be more > productive in Python 3. Possibly, if a feature is much easier to be > implemented in Python 3 than Python 2, than you should code that feature > only for 3. > Think in terms of users, not developers. It really defeats me than no > argument on that page is about how great Python 3 is. > This looks like planned obsolescence. Why should users rewrite code if > their life is not getting better? > The risk, by the way, is simply that they will stick with old versions of > the projects for quite a while. > Ga?l > PS: I am all in favor of Python, and all my code is Python-3 compatible. FWIW -- I fully agree with Gael ( finally! ;) ) moreover -- if "everyone switch to Python 3!" would be the banner to go with -- what should be the minimal 3.x version, and how fast should we drop it in favor of some fancy new features of 3.x+1 ? I would say I switch whenever I see that current feature set and codebase stable enough so I could reasonably well maintain it without major effort through a few more years, while indeed providing some new features exclusively for python 3 users. I think I would try to avoid switching entire project to python 3 (i.e. placing previous version completely into maintenance mode), but rather add more carrots to it to enjoy if using with Python 3. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From njvack at wisc.edu Thu Dec 1 14:47:15 2016 From: njvack at wisc.edu (Nate Vack) Date: Thu, 01 Dec 2016 19:47:15 +0000 Subject: [Neuroimaging] nipy visualization documentation? Message-ID: Hi all, I'm working with someone planning to make some figures for a paper. She's trying MCIcrogl but it's proving balky to get running and ultimately she'll need to code in Pascal to get it to do things, which is well, um, Pascal. My brain tells me there are some pretty sharp vis tools included in nipy, but I can't find much at all in the way of documentation for it. Any pointers as to where we might get started? Thanks! -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Thu Dec 1 16:04:36 2016 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Thu, 01 Dec 2016 21:04:36 +0000 Subject: [Neuroimaging] nipy visualization documentation? In-Reply-To: References: Message-ID: Hi Nate, Pysurfer and DIPY.VIZ do have a lot of visualization capabilities. In DIPY we are very interested in porting some of the shaders from MRICroGL to DIPY.VIZ (this is a recurring discussion with Chris Rorden). Especially now that there is more support for shaders in VTK 7.0. I am not familiar with Pysurfer myself (there are others who can help) but for DIPY.VIZ you can have a look at these tutorials http://nipy.org/dipy/examples_index.html#visualization-new and we have many upcoming PRs adding new exciting capabilities. For example, see this PR which adds capabilities for integrated UIs directly in OpenGL without the need of external GUIs. https://github.com/nipy/dipy/pull/1140 You can read more about the upcoming PRs here http://ranveeraggarwal.com/subblogs/gsoc-16/gsoc-2016-summary I hope this was helpful. Best regards, Eleftherios On Thu, Dec 1, 2016 at 3:47 PM Nate Vack wrote: > Hi all, > > I'm working with someone planning to make some figures for a paper. She's > trying MCIcrogl but it's proving balky to get running and ultimately she'll > need to code in Pascal to get it to do things, which is well, um, Pascal. > > My brain tells me there are some pretty sharp vis tools included in nipy, > but I can't find much at all in the way of documentation for it. Any > pointers as to where we might get started? > > Thanks! > -Nate > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From RPEREACAMARGO at mgh.harvard.edu Thu Dec 1 19:23:07 2016 From: RPEREACAMARGO at mgh.harvard.edu (Perea Camargo, Rodrigo Dennis) Date: Fri, 2 Dec 2016 00:23:07 +0000 Subject: [Neuroimaging] Using RESTORE in a dti_model fit Message-ID: Hi all, I am trying to reconstruct a diffusion tensor model while correcting for outliers using RESTORE. In the Dipy documentation I found this helpful link: http://nipy.org/dipy/examples_built/restore_dti.html and I follow some instructions creating a script that I copied shown below. The problem is that 1) I am new at Python and 2) new to Dipy. Apparently the link provides a comparison example for introduced noisy data but it is not very specific for running RESTORE. Could anybody provide me more advice? My goal is to apply RESTORE to my DWIs and extract/save the FA (and other ) diffusivity maps, but I got stuck at the end?.. Thanks in advance, Rodrigo HERE IS MY SCRIPT (check below for my questions, if not clearer): #!/bin/pyton #import modules import numpy as np import nibabel as nib from os.path import expanduser, join #data initialization dname=?' fdwi=join(dname,?.nii.gz') print(fdwi) fbval=join(dname,'.bvals') fbvec=join(dname,'.bvecs') print(fbval,fbvec) #loading nii img=nib.load(fdwi) data = img.get_data() #loading bvecs/bvals from dipy.io import read_bvals_bvecs bvals, bvecs = read_bvals_bvecs(fbval, fbvec) #Creating the gradient table from dipy.core.gradients import gradient_table gtab = gradient_table(bvals, bvecs) #Reconstructing a model dti_wls = dti.TensorModel(gtab) #Estimate noise (or sigma) for restore import dipy.denoise.noise_estimate as ne sigma = ne.estimate_sigma(data) dti_restore = dti.TensorModel(gtab,fit_method='RESTORE', sigma=sigma) #Now how do I get my tensor outputs?? #I believe I haven?t even apply the tensor fit?. not sure what else to do. --- Rodrigo Dennis Perea Research Fellow Department of Radiology Athinoula A. Martinos Center Massachusetts General Hospital Harvard Medical School rpereacamargo at mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrbago at gmail.com Fri Dec 2 15:15:25 2016 From: mrbago at gmail.com (Bago) Date: Fri, 02 Dec 2016 20:15:25 +0000 Subject: [Neuroimaging] Using RESTORE in a dti_model fit In-Reply-To: References: Message-ID: Hi Rodrigo, I believe dipy provides a command line utility that does what you want, dipy_reconst_dti_restore. If you want to learn more about how to write dipy scripts take a look at https://github.com/nipy/dipy/blob/master/dipy/workflows/reconst.py. You simply need to pass your data to the model and to get a fit, then you can get metrics by using the fit's attributes, eg `tensor_fit.fa` or ` tensor_fit.md`. Those are arrays that can be saved as images using nibabel. These scripts are implemented as "Workflow" classes, but you don't really need to worry about that part. Just review the run method, witch you could emulate to write your own scripts. The workflow classes just give us a little more flexibility, for example the classes can be wrapped to make nipype interfaces. Bago On Thu, Dec 1, 2016 at 6:37 PM Perea Camargo, Rodrigo Dennis < RPEREACAMARGO at mgh.harvard.edu> wrote: > Hi all, > I am trying to reconstruct a diffusion tensor model while correcting for > outliers using RESTORE. In the Dipy documentation I found this helpful > link: > http://nipy.org/dipy/examples_built/restore_dti.html > and I follow some instructions creating a script that I copied shown below. > > > The problem is that 1) I am new at Python and 2) new to Dipy. Apparently > the link provides a comparison example for introduced noisy data but it is > not very specific for running RESTORE. Could anybody provide me more > advice? My goal is to apply RESTORE to my DWIs and extract/save the FA (and > other ) diffusivity maps, but I got stuck at the end?.. > > > Thanks in advance, > Rodrigo > > > > HERE IS MY SCRIPT (check below for my questions, if not clearer): > > #!/bin/pyton > > #import modules > import numpy as np > import nibabel as nib > from os.path import expanduser, join > > #data initialization > dname=?' > fdwi=join(dname,?.nii.gz') > print(fdwi) > fbval=join(dname,'.bvals') > fbvec=join(dname,'.bvecs') > print(fbval,fbvec) > > #loading nii > img=nib.load(fdwi) > data = img.get_data() > > #loading bvecs/bvals > from dipy.io import read_bvals_bvecs > bvals, bvecs = read_bvals_bvecs(fbval, fbvec) > > #Creating the gradient table > from dipy.core.gradients import gradient_table > gtab = gradient_table(bvals, bvecs) > > #Reconstructing a model > dti_wls = dti.TensorModel(gtab) > > #Estimate noise (or sigma) for restore > import dipy.denoise.noise_estimate as ne > sigma = ne.estimate_sigma(data) > > dti_restore = dti.TensorModel(gtab,fit_method='RESTORE', sigma=sigma) > > #Now how do I get my tensor outputs?? > #I believe I haven?t even apply the tensor fit?. not sure what else to do. > > --- > Rodrigo Dennis Perea > Research Fellow > Department of Radiology > Athinoula A. Martinos Center > Massachusetts General Hospital > Harvard Medical School > rpereacamargo at mgh.harvard.edu > > > > > > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From panyiyuan at qq.com Mon Dec 5 05:46:12 2016 From: panyiyuan at qq.com (=?gb18030?B?zt7Tx6ShxP3Lqg==?=) Date: Mon, 5 Dec 2016 18:46:12 +0800 Subject: [Neuroimaging] (no subject) Message-ID: Use HCP separation of the data packet affine suggested wrong, then we use the original HCP affine, but still being given, please help solve the problem,thanks a lot. ValueError: The affine provided seems to contain shearing, data must be acquired or interpolated on a regular grid to be used with 'LocalTracking'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Mon Dec 5 13:38:21 2016 From: arokem at gmail.com (Ariel Rokem) Date: Mon, 5 Dec 2016 10:38:21 -0800 Subject: [Neuroimaging] (no subject) In-Reply-To: References: Message-ID: On Mon, Dec 5, 2016 at 2:46 AM, ????? wrote: > Use HCP separation of the data packet affine suggested wrong, then we use > the original HCP affine, but still being given, please help solve the > problem,thanks a lot. > ValueError: The affine provided seems to contain shearing, data must be > acquired or interpolated on a regular grid to be used with 'LocalTracking'. > > Thank you for your message. This error should be resolved once the following fix is merged into the master branch: https://github.com/nipy/dipy/pull/1159 > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Tue Dec 6 14:49:22 2016 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Tue, 06 Dec 2016 19:49:22 +0000 Subject: [Neuroimaging] Hiring software developer to work for DIPY Message-ID: Hello all, A new software engineer/developer position is available in my lab at Indiana University to work exclusively for DIPY development. Details with more information and how to apply can be found here. https://iujobs.peopleadmin.com/postings/30541 Be happy to send me directly any questions concerning the job. However, you can only apply through the link above. Best regards, Eleftherios p.s. This is a dream job for people who like python and open source development. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe at pallier.org Mon Dec 12 04:45:23 2016 From: christophe at pallier.org (Christophe Pallier) Date: Mon, 12 Dec 2016 10:45:23 +0100 Subject: [Neuroimaging] temporal filtering and confounds when loading with nilearn niftimasker Message-ID: Hello all, I was wondering if the confounds passed to Niftimasker were detrented and temporally filtered by the masker. Looking at the code of nilearn.signal.clean, I see that there are detrended but not filtered. Would it not be useful to also filter them before projecting the signal of the orthogonal of the confounds spaces? While writing this, I realize that, maybe, this would have strickly no effect (for example if filtering and projection operation commute; sorry if this is obvious...) (real life case: I extracted timecourse from CSF to include as a confound before running a func. connectivity analysis, and there are some low freq in the signal that will probably not be cleaned by detrending, but differ from voxels in grey matter) -- Christophe Pallier http://www.unicog.org http://ww.pallier.org Tel: +33 (0) 1 69 08 79 34 From olivetti at fbk.eu Mon Dec 12 11:07:47 2016 From: olivetti at fbk.eu (Emanuele Olivetti) Date: Mon, 12 Dec 2016 17:07:47 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? Message-ID: Hi, I usually compute the distance matrix between two lists of streamlines using bundle_distances_mam() or bundle_distances_mdf(). When the lists are large, it is convenient and easy to exploit the multiple cores of the CPU because such computation is intrinsically (embarassingly) parallel. At the moment I'm doing it through the multiprocessing or the joblib modules, because I cannot find a way directly from DiPy, at least according to what I see in dipy/tracking/distances.pyx . But consider that I am not proficient in cython.parallel. Is there a preferable way to perform such parallel computation? I plan to prepare a pull request in future and I'd like to be on the right track. Best, Emanuele -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Mon Dec 12 17:34:49 2016 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 12 Dec 2016 23:34:49 +0100 Subject: [Neuroimaging] temporal filtering and confounds when loading with nilearn niftimasker In-Reply-To: References: Message-ID: <20161212223449.GE673653@phare.normalesup.org> That's a tricky problem, because the question is more: what do people expect is done? The way nilearn currently does it is to first remove the confounds, and then filter the resulting signal. I cannot really see a drawback of doing it that way. To take the case that you are describing below, the low-frequency of the CSF would be removed from the final signal. Now, IMHO, the right way to do things would be to express the frequency filter in a cosine basis and concatenate the confounds. AFAIK this is how SPM does it. We'd like to do it this way, and have an issue to do it: https://github.com/nilearn/nilearn/issues/1011 However we haven't found time so far. If you write the equations (they are a bit horrible), the way we do things, the way you propose to do things, and the way I think that they should be done all vary slightly. I cannot put an intuition on what the differences are, though. Of course if the frequency filter and the confounds are orthogonal (the confounds have no energy in the filtered frequencies bands), they are equivalent. Do you want to do a PR to solve issue 1011 (filtering based on a cosine base)? That would move us toward the right way to do things. Cheers, Ga?l On Mon, Dec 12, 2016 at 10:45:23AM +0100, Christophe Pallier wrote: > Hello all, > I was wondering if the confounds passed to Niftimasker were detrented > and temporally filtered by the masker. > Looking at the code of nilearn.signal.clean, I see that there are > detrended but not filtered. > Would it not be useful to also filter them before projecting the > signal of the orthogonal of the confounds spaces? > While writing this, I realize that, maybe, this would have strickly > no effect (for example if filtering and projection operation commute; > sorry if this is obvious...) > (real life case: I extracted timecourse from CSF to include as a > confound before running a func. connectivity analysis, and there are > some low freq in the signal that will probably not be cleaned by > detrending, but differ from voxels in grey matter) From bertrand.thirion at inria.fr Mon Dec 12 17:54:58 2016 From: bertrand.thirion at inria.fr (bthirion) Date: Mon, 12 Dec 2016 23:54:58 +0100 Subject: [Neuroimaging] temporal filtering and confounds when loading with nilearn niftimasker In-Reply-To: <20161212223449.GE673653@phare.normalesup.org> References: <20161212223449.GE673653@phare.normalesup.org> Message-ID: <7f699e2a-8394-1dee-6a36-573bf8d27455@inria.fr> On 12/12/2016 23:34, Gael Varoquaux wrote: > That's a tricky problem, because the question is more: what do people > expect is done? > > The way nilearn currently does it is to first remove the confounds, and > then filter the resulting signal. I cannot really see a drawback of doing > it that way. To take the case that you are describing below, the > low-frequency of the CSF would be removed from the final signal. > > Now, IMHO, the right way to do things would be to express the frequency > filter in a cosine basis and concatenate the confounds. AFAIK this is how > SPM does it. We'd like to do it this way, and have an issue to do it: > https://github.com/nilearn/nilearn/issues/1011 > However we haven't found time so far. > > If you write the equations (they are a bit horrible), the way we do > things, the way you propose to do things, and the way I think that they > should be done all vary slightly. I cannot put an intuition on what the > differences are, though. Of course if the frequency filter and the > confounds are orthogonal (the confounds have no energy in the filtered > frequencies bands), they are equivalent. > I think that we should do either (simultaneous regression) or (band-pass then regression on band-passed confounds). B From elef at indiana.edu Tue Dec 13 17:17:24 2016 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Tue, 13 Dec 2016 22:17:24 +0000 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Hi Emanuele, Here is an example of how we calculated the distance matrix in parallel (for the MDF) using OpenMP https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx You can just add another function that does the same using mam. It should be really easy to implement as we have already done it for the MDF for speeding up SLR. Then we need to update the bundle_distances* functions to use the parallel versions. I'll be happy to help you with this. Let's try to schedule some time to look at this together. Best regards, Eleftherios On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti wrote: > Hi, > > I usually compute the distance matrix between two lists of streamlines > using bundle_distances_mam() or bundle_distances_mdf(). When the lists are > large, it is convenient and easy to exploit the multiple cores of the CPU > because such computation is intrinsically (embarassingly) parallel. At the > moment I'm doing it through the multiprocessing or the joblib modules, > because I cannot find a way directly from DiPy, at least according to what > I see in dipy/tracking/distances.pyx . But consider that I am not > proficient in cython.parallel. > > Is there a preferable way to perform such parallel computation? I plan to > prepare a pull request in future and I'd like to be on the right track. > > Best, > > Emanuele > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivetti at fbk.eu Wed Dec 14 06:28:59 2016 From: olivetti at fbk.eu (Emanuele Olivetti) Date: Wed, 14 Dec 2016 12:28:59 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Hi Eleftherios, Thank you for pointing me to the MDF example. From what I see the Cython syntax is not complex, which is good. My only concern is the availability of OpenMP in the systems where DiPy is used. On a reasonably recent GNU/Linux machine it seems straightforward to have libgomp and the proper version of gcc. On other systems - say OSX - the situation is less clear to me. According to what I read here http://nipy.org/dipy/installation.html#openmp-with-osx the OSX installation steps are not meant for standard end users. Are those instructions updated? As a test of that, we've just tried to skip the steps described above and instead to install gcc with conda on OSX ("conda install gcc"). In the process, conda installed the recent gcc-4.8 with libgomp, which seems good news. Unfortunately, when we tried to compile a simple example of Cython code using parallelization (see below), the process failed (fatal error: limits.h : no such file or directory)... For the reasons above, I am wondering whether the very simple solution of using the "multiprocessing" module, available from the standard Python library, may be an acceptable first step towards the more efficient multithreading of Cython/libgomp. With "multiprocessing", there is no extra dependency on libgomp, or recent gcc or else. Moreover, multiprocessing does not require to have Cython code, because it works on plain Python too. Best, Emanuele ---- test.pyx ---- from cython import parallel from libc.stdio cimport printf def test_func(): cdef int thread_id = -1 with nogil, parallel.parallel(num_threads=10): thread_id = parallel.threadid() printf("Thread ID: %d\n", thread_id) ----- ----- setup.py ----- from distutils.core import setup, Extension from Cython.Build import cythonize extensions = [Extension( "test", sources=["test.pyx"], extra_compile_args=["-fopenmp"], extra_link_args=["-fopenmp"] )] setup( ext_modules = cythonize(extensions) ) ---- python setup.py build_ext --inplace On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis wrote: > Hi Emanuele, > > Here is an example of how we calculated the distance matrix in parallel > (for the MDF) using OpenMP > https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx > > You can just add another function that does the same using mam. It should > be really easy to implement as we have > already done it for the MDF for speeding up SLR. > > Then we need to update the bundle_distances* functions to use the parallel > versions. > > I'll be happy to help you with this. Let's try to schedule some time to > look at this together. > > Best regards, > Eleftherios > > > On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti > wrote: > >> Hi, >> >> I usually compute the distance matrix between two lists of streamlines >> using bundle_distances_mam() or bundle_distances_mdf(). When the lists are >> large, it is convenient and easy to exploit the multiple cores of the CPU >> because such computation is intrinsically (embarassingly) parallel. At the >> moment I'm doing it through the multiprocessing or the joblib modules, >> because I cannot find a way directly from DiPy, at least according to what >> I see in dipy/tracking/distances.pyx . But consider that I am not >> proficient in cython.parallel. >> >> Is there a preferable way to perform such parallel computation? I plan to >> prepare a pull request in future and I'd like to be on the right track. >> >> Best, >> >> Emanuele >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Wed Dec 14 10:51:30 2016 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Wed, 14 Dec 2016 15:51:30 +0000 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Hi Emanuele, My understanding is that openmp was only temporarily not available when clang replaced gcc in osx. So, I would suggest to go ahead with openmp. Any current installation issues are only temporarily for osx. Openmp gives us a lot of capability to play with shared memory and it is a standard that will be around for very long time. Also, the great integration in cython makes the algorithms really easy to read. So, especially for this project my recommendation is to use openmp rather than multiprocessing. All the way! :) I am CC'ing Stephan who wrote the instructions for osx. I am sure he can help you with this. I would also suggest to check if xcode provides any new guis for enabling openmp. I remember there was something for that. Laterz! Eleftherios On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti wrote: > Hi Eleftherios, > > Thank you for pointing me to the MDF example. From what I see the Cython > syntax is not complex, which is good. > > My only concern is the availability of OpenMP in the systems where DiPy is > used. On a reasonably recent GNU/Linux machine it seems straightforward to > have libgomp and the proper version of gcc. On other systems - say OSX - > the situation is less clear to me. According to what I read here > http://nipy.org/dipy/installation.html#openmp-with-osx > the OSX installation steps are not meant for standard end users. Are those > instructions updated? > As a test of that, we've just tried to skip the steps described above and > instead to install gcc with conda on OSX ("conda install gcc"). In the > process, conda installed the recent gcc-4.8 with libgomp, which seems good > news. Unfortunately, when we tried to compile a simple example of Cython > code using parallelization (see below), the process failed (fatal error: > limits.h : no such file or directory)... > > For the reasons above, I am wondering whether the very simple solution of > using the "multiprocessing" module, available from the standard Python > library, may be an acceptable first step towards the more efficient > multithreading of Cython/libgomp. With "multiprocessing", there is no extra > dependency on libgomp, or recent gcc or else. Moreover, multiprocessing > does not require to have Cython code, because it works on plain Python too. > > Best, > > Emanuele > > ---- test.pyx ---- > from cython import parallel > from libc.stdio cimport printf > > def test_func(): > cdef int thread_id = -1 > with nogil, parallel.parallel(num_threads=10): > thread_id = parallel.threadid() > printf("Thread ID: %d\n", thread_id) > ----- > > ----- setup.py ----- > from distutils.core import setup, Extension > from Cython.Build import cythonize > > extensions = [Extension( > "test", > sources=["test.pyx"], > extra_compile_args=["-fopenmp"], > extra_link_args=["-fopenmp"] > )] > > setup( > ext_modules = cythonize(extensions) > ) > ---- > python setup.py build_ext --inplace > > On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < > elef at indiana.edu> wrote: > > Hi Emanuele, > > Here is an example of how we calculated the distance matrix in parallel > (for the MDF) using OpenMP > https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx > > You can just add another function that does the same using mam. It should > be really easy to implement as we have > already done it for the MDF for speeding up SLR. > > Then we need to update the bundle_distances* functions to use the parallel > versions. > > I'll be happy to help you with this. Let's try to schedule some time to > look at this together. > > Best regards, > Eleftherios > > > On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti > wrote: > > Hi, > > I usually compute the distance matrix between two lists of streamlines > using bundle_distances_mam() or bundle_distances_mdf(). When the lists are > large, it is convenient and easy to exploit the multiple cores of the CPU > because such computation is intrinsically (embarassingly) parallel. At the > moment I'm doing it through the multiprocessing or the joblib modules, > because I cannot find a way directly from DiPy, at least according to what > I see in dipy/tracking/distances.pyx . But consider that I am not > proficient in cython.parallel. > > Is there a preferable way to perform such parallel computation? I plan to > prepare a pull request in future and I'd like to be on the right track. > > Best, > > Emanuele > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stjeansam at gmail.com Wed Dec 14 11:14:17 2016 From: stjeansam at gmail.com (Samuel St-Jean) Date: Wed, 14 Dec 2016 17:14:17 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: That also depends on which version of clang ships by default with osx, in which case you have to play around with it to get a new one. I think it starts with clang 3.7 to have openmp support (I only ever tried Mac osx 10.9, so anyone more experienced can chime in), but everything older has to go through the hombebrew gcc install and company. Might be worhtwhile to check if openmp support is out of the box now, and starting on which mac osx versions, since older ones could be problematic for first time installs. I also have to admit I have no idea how old is old in the mac world, so maybe 10.9 is already phased out by now, but it was a hard and time consuming building around stuff with homebrew experience (and again, first time I used a mac, so, I guess the average user would also have some issues). Samuel 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis : > > Hi Emanuele, > > My understanding is that openmp was only temporarily not available when > clang replaced gcc in osx. > > So, I would suggest to go ahead with openmp. Any current installation > issues are only temporarily for osx. > Openmp gives us a lot of capability to play with shared memory and it is a > standard that will be around > for very long time. Also, the great integration in cython makes the > algorithms really easy to read. > So, especially for this project my recommendation is to use openmp rather > than multiprocessing. All the way! :) > > I am CC'ing Stephan who wrote the instructions for osx. I am sure he can > help you with this. I would also suggest > to check if xcode provides any new guis for enabling openmp. I remember > there was something for that. > > Laterz! > Eleftherios > > > > > On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti wrote: > >> Hi Eleftherios, >> >> Thank you for pointing me to the MDF example. From what I see the Cython >> syntax is not complex, which is good. >> >> My only concern is the availability of OpenMP in the systems where DiPy >> is used. On a reasonably recent GNU/Linux machine it seems straightforward >> to have libgomp and the proper version of gcc. On other systems - say OSX - >> the situation is less clear to me. According to what I read here >> http://nipy.org/dipy/installation.html#openmp-with-osx >> the OSX installation steps are not meant for standard end users. Are >> those instructions updated? >> As a test of that, we've just tried to skip the steps described above and >> instead to install gcc with conda on OSX ("conda install gcc"). In the >> process, conda installed the recent gcc-4.8 with libgomp, which seems good >> news. Unfortunately, when we tried to compile a simple example of Cython >> code using parallelization (see below), the process failed (fatal error: >> limits.h : no such file or directory)... >> >> For the reasons above, I am wondering whether the very simple solution of >> using the "multiprocessing" module, available from the standard Python >> library, may be an acceptable first step towards the more efficient >> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >> does not require to have Cython code, because it works on plain Python too. >> >> Best, >> >> Emanuele >> >> ---- test.pyx ---- >> from cython import parallel >> from libc.stdio cimport printf >> >> def test_func(): >> cdef int thread_id = -1 >> with nogil, parallel.parallel(num_threads=10): >> thread_id = parallel.threadid() >> printf("Thread ID: %d\n", thread_id) >> ----- >> >> ----- setup.py ----- >> from distutils.core import setup, Extension >> from Cython.Build import cythonize >> >> extensions = [Extension( >> "test", >> sources=["test.pyx"], >> extra_compile_args=["-fopenmp"], >> extra_link_args=["-fopenmp"] >> )] >> >> setup( >> ext_modules = cythonize(extensions) >> ) >> ---- >> python setup.py build_ext --inplace >> >> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >> elef at indiana.edu> wrote: >> >> Hi Emanuele, >> >> Here is an example of how we calculated the distance matrix in parallel >> (for the MDF) using OpenMP >> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >> >> You can just add another function that does the same using mam. It should >> be really easy to implement as we have >> already done it for the MDF for speeding up SLR. >> >> Then we need to update the bundle_distances* functions to use the >> parallel versions. >> >> I'll be happy to help you with this. Let's try to schedule some time to >> look at this together. >> >> Best regards, >> Eleftherios >> >> >> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >> wrote: >> >> Hi, >> >> I usually compute the distance matrix between two lists of streamlines >> using bundle_distances_mam() or bundle_distances_mdf(). When the lists are >> large, it is convenient and easy to exploit the multiple cores of the CPU >> because such computation is intrinsically (embarassingly) parallel. At the >> moment I'm doing it through the multiprocessing or the joblib modules, >> because I cannot find a way directly from DiPy, at least according to what >> I see in dipy/tracking/distances.pyx . But consider that I am not >> proficient in cython.parallel. >> >> Is there a preferable way to perform such parallel computation? I plan to >> prepare a pull request in future and I'd like to be on the right track. >> >> Best, >> >> Emanuele >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avesani at fbk.eu Wed Dec 14 12:21:32 2016 From: avesani at fbk.eu (Paolo Avesani) Date: Wed, 14 Dec 2016 18:21:32 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Just for reference I tried two ways on Mac OS 10.11.5: 1. compile with clang 2. compile with gcc provided by anaconda In both cases compilation failed. 1. compile with clang ---------------------------- $ python setup.py build_ext --inplace Compiling test.pyx because it changed. Cythonizing test.pyx running build_ext building 'test' extension creating build creating build/temp.macosx-10.6-x86_64-2.7 gcc -fno-strict-aliasing -I/Users/paolo/Software/miniconda/include -arch x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/paolo/Software/miniconda/include/python2.7 -c test.c -o build/temp.macosx-10.6-x86_64-2.7/test.o -fopenmp clang: error: unsupported option '-fopenmp' error: command 'gcc' failed with exit status 1 2. compile with gcc provided by anaconda --------------------------------------------------------- $ python setup.py build_ext --inplace Compiling test.pyx because it changed. Cythonizing test.pyx running build_ext building 'test' extension gcc -fno-strict-aliasing -I/Users/paolo/Software/miniconda/include -arch x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/paolo/Software/miniconda/include/python2.7 -c test.c -o build/temp.macosx-10.6-x86_64-2.7/test.o -fopenmp In file included from /Users/paolo/Software/miniconda/lib/gcc/x86_64-apple-darwin11.4.2/4.8.5/include-fixed/syslimits.h:7:0, from /Users/paolo/Software/miniconda/lib/gcc/x86_64-apple-darwin11.4.2/4.8.5/include-fixed/limits.h:34, from /Users/paolo/Software/miniconda/include/python2.7/Python.h:19, from test.c:16: /Users/paolo/Software/miniconda/lib/gcc/x86_64-apple-darwin11.4.2/4.8.5/include-fixed/limits.h:168:61: fatal error: limits.h: No such file or directory #include_next /* recurse down to the real one */ compilation terminated. error: command 'gcc' failed with exit status 1 On Wed, Dec 14, 2016 at 4:51 PM, Eleftherios Garyfallidis wrote: > > Hi Emanuele, > > My understanding is that openmp was only temporarily not available when > clang replaced gcc in osx. > > So, I would suggest to go ahead with openmp. Any current installation > issues are only temporarily for osx. > Openmp gives us a lot of capability to play with shared memory and it is a > standard that will be around > for very long time. Also, the great integration in cython makes the > algorithms really easy to read. > So, especially for this project my recommendation is to use openmp rather > than multiprocessing. All the way! :) > > I am CC'ing Stephan who wrote the instructions for osx. I am sure he can > help you with this. I would also suggest > to check if xcode provides any new guis for enabling openmp. I remember > there was something for that. > > Laterz! > Eleftherios > > > > > On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti wrote: > >> Hi Eleftherios, >> >> Thank you for pointing me to the MDF example. From what I see the Cython >> syntax is not complex, which is good. >> >> My only concern is the availability of OpenMP in the systems where DiPy >> is used. On a reasonably recent GNU/Linux machine it seems straightforward >> to have libgomp and the proper version of gcc. On other systems - say OSX - >> the situation is less clear to me. According to what I read here >> http://nipy.org/dipy/installation.html#openmp-with-osx >> the OSX installation steps are not meant for standard end users. Are >> those instructions updated? >> As a test of that, we've just tried to skip the steps described above and >> instead to install gcc with conda on OSX ("conda install gcc"). In the >> process, conda installed the recent gcc-4.8 with libgomp, which seems good >> news. Unfortunately, when we tried to compile a simple example of Cython >> code using parallelization (see below), the process failed (fatal error: >> limits.h : no such file or directory)... >> >> For the reasons above, I am wondering whether the very simple solution of >> using the "multiprocessing" module, available from the standard Python >> library, may be an acceptable first step towards the more efficient >> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >> does not require to have Cython code, because it works on plain Python too. >> >> Best, >> >> Emanuele >> >> ---- test.pyx ---- >> from cython import parallel >> from libc.stdio cimport printf >> >> def test_func(): >> cdef int thread_id = -1 >> with nogil, parallel.parallel(num_threads=10): >> thread_id = parallel.threadid() >> printf("Thread ID: %d\n", thread_id) >> ----- >> >> ----- setup.py ----- >> from distutils.core import setup, Extension >> from Cython.Build import cythonize >> >> extensions = [Extension( >> "test", >> sources=["test.pyx"], >> extra_compile_args=["-fopenmp"], >> extra_link_args=["-fopenmp"] >> )] >> >> setup( >> ext_modules = cythonize(extensions) >> ) >> ---- >> python setup.py build_ext --inplace >> >> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >> elef at indiana.edu> wrote: >> >> Hi Emanuele, >> >> Here is an example of how we calculated the distance matrix in parallel >> (for the MDF) using OpenMP >> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >> >> You can just add another function that does the same using mam. It should >> be really easy to implement as we have >> already done it for the MDF for speeding up SLR. >> >> Then we need to update the bundle_distances* functions to use the >> parallel versions. >> >> I'll be happy to help you with this. Let's try to schedule some time to >> look at this together. >> >> Best regards, >> Eleftherios >> >> >> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >> wrote: >> >> Hi, >> >> I usually compute the distance matrix between two lists of streamlines >> using bundle_distances_mam() or bundle_distances_mdf(). When the lists are >> large, it is convenient and easy to exploit the multiple cores of the CPU >> because such computation is intrinsically (embarassingly) parallel. At the >> moment I'm doing it through the multiprocessing or the joblib modules, >> because I cannot find a way directly from DiPy, at least according to what >> I see in dipy/tracking/distances.pyx . But consider that I am not >> proficient in cython.parallel. >> >> Is there a preferable way to perform such parallel computation? I plan to >> prepare a pull request in future and I'd like to be on the right track. >> >> Best, >> >> Emanuele >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- ------------------------------------------------------- Paolo Avesani Fondazione Bruno Kessler via Sommarive 18, 38050 Povo (TN) - I phone: +39 0461 314336 fax: +39 0461 302040 email: avesani at fbk.eu web: avesani.fbk.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Wed Dec 14 13:44:47 2016 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 14 Dec 2016 10:44:47 -0800 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Hi Paolo, I can partially reproduce your findings (also on a MAC, OS 10.12.1 in my case): On Wed, Dec 14, 2016 at 9:21 AM, Paolo Avesani wrote: > Just for reference I tried two ways on Mac OS 10.11.5: > 1. compile with clang > 2. compile with gcc provided by anaconda > In both cases compilation failed. > > 1. compile with clang > ---------------------------- > $ python setup.py build_ext --inplace > Compiling test.pyx because it changed. > Cythonizing test.pyx > running build_ext > building 'test' extension > creating build > creating build/temp.macosx-10.6-x86_64-2.7 > gcc -fno-strict-aliasing -I/Users/paolo/Software/miniconda/include -arch > x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes > -I/Users/paolo/Software/miniconda/include/python2.7 -c test.c -o > build/temp.macosx-10.6-x86_64-2.7/test.o -fopenmp > clang: error: unsupported option '-fopenmp' > error: command 'gcc' failed with exit status 1 > > I get the "-fopenmp" error, but compilation then proceeds without a problem. I don't think that openmp is used (does anyone know how I would know for sure?), but that's fine for my needs. As Stephan has reported, you can get an omp-enabled gcc from homebrew, but I don't use that, because when I do any real data analysis, I do it on AWS ubuntu machines anyway. I am not sure why your clan exits with status 1, but I don't get that on my machine. What do you see when you run `gcc --version`? > 2. compile with gcc provided by anaconda > --------------------------------------------------------- > $ python setup.py build_ext --inplace > Compiling test.pyx because it changed. > Cythonizing test.pyx > running build_ext > building 'test' extension > gcc -fno-strict-aliasing -I/Users/paolo/Software/miniconda/include -arch > x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes > -I/Users/paolo/Software/miniconda/include/python2.7 -c test.c -o > build/temp.macosx-10.6-x86_64-2.7/test.o -fopenmp > In file included from /Users/paolo/Software/minicond > a/lib/gcc/x86_64-apple-darwin11.4.2/4.8.5/include-fixed/syslimits.h:7:0, > from /Users/paolo/Software/minicond > a/lib/gcc/x86_64-apple-darwin11.4.2/4.8.5/include-fixed/limits.h:34, > from /Users/paolo/Software/minicond > a/include/python2.7/Python.h:19, > from test.c:16: > /Users/paolo/Software/miniconda/lib/gcc/x86_64-apple- > darwin11.4.2/4.8.5/include-fixed/limits.h:168:61: fatal error: limits.h: > No such file or directory > #include_next /* recurse down to the real one */ > compilation terminated. > error: command 'gcc' failed with exit status 1 > > Yep. I see a similar error with Anaconda gcc as well. Cheers, Ariel > > > On Wed, Dec 14, 2016 at 4:51 PM, Eleftherios Garyfallidis < > elef at indiana.edu> wrote: > >> >> Hi Emanuele, >> >> My understanding is that openmp was only temporarily not available when >> clang replaced gcc in osx. >> >> So, I would suggest to go ahead with openmp. Any current installation >> issues are only temporarily for osx. >> Openmp gives us a lot of capability to play with shared memory and it is >> a standard that will be around >> for very long time. Also, the great integration in cython makes the >> algorithms really easy to read. >> So, especially for this project my recommendation is to use openmp rather >> than multiprocessing. All the way! :) >> >> I am CC'ing Stephan who wrote the instructions for osx. I am sure he can >> help you with this. I would also suggest >> to check if xcode provides any new guis for enabling openmp. I remember >> there was something for that. >> >> Laterz! >> Eleftherios >> >> >> >> >> On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti >> wrote: >> >>> Hi Eleftherios, >>> >>> Thank you for pointing me to the MDF example. From what I see the Cython >>> syntax is not complex, which is good. >>> >>> My only concern is the availability of OpenMP in the systems where DiPy >>> is used. On a reasonably recent GNU/Linux machine it seems straightforward >>> to have libgomp and the proper version of gcc. On other systems - say OSX - >>> the situation is less clear to me. According to what I read here >>> http://nipy.org/dipy/installation.html#openmp-with-osx >>> the OSX installation steps are not meant for standard end users. Are >>> those instructions updated? >>> As a test of that, we've just tried to skip the steps described above >>> and instead to install gcc with conda on OSX ("conda install gcc"). In the >>> process, conda installed the recent gcc-4.8 with libgomp, which seems good >>> news. Unfortunately, when we tried to compile a simple example of Cython >>> code using parallelization (see below), the process failed (fatal error: >>> limits.h : no such file or directory)... >>> >>> For the reasons above, I am wondering whether the very simple solution >>> of using the "multiprocessing" module, available from the standard Python >>> library, may be an acceptable first step towards the more efficient >>> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >>> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >>> does not require to have Cython code, because it works on plain Python too. >>> >>> Best, >>> >>> Emanuele >>> >>> ---- test.pyx ---- >>> from cython import parallel >>> from libc.stdio cimport printf >>> >>> def test_func(): >>> cdef int thread_id = -1 >>> with nogil, parallel.parallel(num_threads=10): >>> thread_id = parallel.threadid() >>> printf("Thread ID: %d\n", thread_id) >>> ----- >>> >>> ----- setup.py ----- >>> from distutils.core import setup, Extension >>> from Cython.Build import cythonize >>> >>> extensions = [Extension( >>> "test", >>> sources=["test.pyx"], >>> extra_compile_args=["-fopenmp"], >>> extra_link_args=["-fopenmp"] >>> )] >>> >>> setup( >>> ext_modules = cythonize(extensions) >>> ) >>> ---- >>> python setup.py build_ext --inplace >>> >>> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >>> elef at indiana.edu> wrote: >>> >>> Hi Emanuele, >>> >>> Here is an example of how we calculated the distance matrix in parallel >>> (for the MDF) using OpenMP >>> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >>> >>> You can just add another function that does the same using mam. It >>> should be really easy to implement as we have >>> already done it for the MDF for speeding up SLR. >>> >>> Then we need to update the bundle_distances* functions to use the >>> parallel versions. >>> >>> I'll be happy to help you with this. Let's try to schedule some time to >>> look at this together. >>> >>> Best regards, >>> Eleftherios >>> >>> >>> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >>> wrote: >>> >>> Hi, >>> >>> I usually compute the distance matrix between two lists of streamlines >>> using bundle_distances_mam() or bundle_distances_mdf(). When the lists are >>> large, it is convenient and easy to exploit the multiple cores of the CPU >>> because such computation is intrinsically (embarassingly) parallel. At the >>> moment I'm doing it through the multiprocessing or the joblib modules, >>> because I cannot find a way directly from DiPy, at least according to what >>> I see in dipy/tracking/distances.pyx . But consider that I am not >>> proficient in cython.parallel. >>> >>> Is there a preferable way to perform such parallel computation? I plan >>> to prepare a pull request in future and I'd like to be on the right track. >>> >>> Best, >>> >>> Emanuele >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > ------------------------------------------------------- > Paolo Avesani > Fondazione Bruno Kessler > via Sommarive 18, > 38050 Povo (TN) - I > phone: +39 0461 314336 <+39%200461%20314336> > fax: +39 0461 302040 <+39%200461%20302040> > email: avesani at fbk.eu > web: avesani.fbk.eu > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Wed Dec 14 13:50:01 2016 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Wed, 14 Dec 2016 18:50:01 +0000 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: I would suggest before going to homebrew etc. to send an e-mail to Xcode asking for some guidelines. Because it seems clang now comes with openmp supported maybe all we need to do is update the correct headers. On Wed, Dec 14, 2016 at 1:45 PM Ariel Rokem wrote: > Hi Paolo, > > I can partially reproduce your findings (also on a MAC, OS 10.12.1 in my > case): > > On Wed, Dec 14, 2016 at 9:21 AM, Paolo Avesani wrote: > > Just for reference I tried two ways on Mac OS 10.11.5: > 1. compile with clang > 2. compile with gcc provided by anaconda > In both cases compilation failed. > > 1. compile with clang > ---------------------------- > $ python setup.py build_ext --inplace > Compiling test.pyx because it changed. > Cythonizing test.pyx > running build_ext > building 'test' extension > creating build > creating build/temp.macosx-10.6-x86_64-2.7 > gcc -fno-strict-aliasing -I/Users/paolo/Software/miniconda/include -arch > x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes > -I/Users/paolo/Software/miniconda/include/python2.7 -c test.c -o > build/temp.macosx-10.6-x86_64-2.7/test.o -fopenmp > clang: error: unsupported option '-fopenmp' > error: command 'gcc' failed with exit status 1 > > > I get the "-fopenmp" error, but compilation then proceeds without a > problem. I don't think that openmp is used (does anyone know how I would > know for sure?), but that's fine for my needs. As Stephan has reported, you > can get an omp-enabled gcc from homebrew, but I don't use that, because > when I do any real data analysis, I do it on AWS ubuntu machines anyway. > > I am not sure why your clan exits with status 1, but I don't get that on > my machine. What do you see when you run `gcc --version`? > > > 2. compile with gcc provided by anaconda > --------------------------------------------------------- > $ python setup.py build_ext --inplace > Compiling test.pyx because it changed. > Cythonizing test.pyx > running build_ext > building 'test' extension > gcc -fno-strict-aliasing -I/Users/paolo/Software/miniconda/include -arch > x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes > -I/Users/paolo/Software/miniconda/include/python2.7 -c test.c -o > build/temp.macosx-10.6-x86_64-2.7/test.o -fopenmp > In file included from > /Users/paolo/Software/miniconda/lib/gcc/x86_64-apple-darwin11.4.2/4.8.5/include-fixed/syslimits.h:7:0, > from > /Users/paolo/Software/miniconda/lib/gcc/x86_64-apple-darwin11.4.2/4.8.5/include-fixed/limits.h:34, > from > /Users/paolo/Software/miniconda/include/python2.7/Python.h:19, > from test.c:16: > /Users/paolo/Software/miniconda/lib/gcc/x86_64-apple-darwin11.4.2/4.8.5/include-fixed/limits.h:168:61: > fatal error: limits.h: No such file or directory > #include_next /* recurse down to the real one */ > compilation terminated. > error: command 'gcc' failed with exit status 1 > > > Yep. I see a similar error with Anaconda gcc as well. > > Cheers, > > Ariel > > > > > On Wed, Dec 14, 2016 at 4:51 PM, Eleftherios Garyfallidis < > elef at indiana.edu> wrote: > > > Hi Emanuele, > > My understanding is that openmp was only temporarily not available when > clang replaced gcc in osx. > > So, I would suggest to go ahead with openmp. Any current installation > issues are only temporarily for osx. > Openmp gives us a lot of capability to play with shared memory and it is a > standard that will be around > for very long time. Also, the great integration in cython makes the > algorithms really easy to read. > So, especially for this project my recommendation is to use openmp rather > than multiprocessing. All the way! :) > > I am CC'ing Stephan who wrote the instructions for osx. I am sure he can > help you with this. I would also suggest > to check if xcode provides any new guis for enabling openmp. I remember > there was something for that. > > Laterz! > Eleftherios > > > > > On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti wrote: > > Hi Eleftherios, > > Thank you for pointing me to the MDF example. From what I see the Cython > syntax is not complex, which is good. > > My only concern is the availability of OpenMP in the systems where DiPy is > used. On a reasonably recent GNU/Linux machine it seems straightforward to > have libgomp and the proper version of gcc. On other systems - say OSX - > the situation is less clear to me. According to what I read here > http://nipy.org/dipy/installation.html#openmp-with-osx > the OSX installation steps are not meant for standard end users. Are those > instructions updated? > As a test of that, we've just tried to skip the steps described above and > instead to install gcc with conda on OSX ("conda install gcc"). In the > process, conda installed the recent gcc-4.8 with libgomp, which seems good > news. Unfortunately, when we tried to compile a simple example of Cython > code using parallelization (see below), the process failed (fatal error: > limits.h : no such file or directory)... > > For the reasons above, I am wondering whether the very simple solution of > using the "multiprocessing" module, available from the standard Python > library, may be an acceptable first step towards the more efficient > multithreading of Cython/libgomp. With "multiprocessing", there is no extra > dependency on libgomp, or recent gcc or else. Moreover, multiprocessing > does not require to have Cython code, because it works on plain Python too. > > Best, > > Emanuele > > ---- test.pyx ---- > from cython import parallel > from libc.stdio cimport printf > > def test_func(): > cdef int thread_id = -1 > with nogil, parallel.parallel(num_threads=10): > thread_id = parallel.threadid() > printf("Thread ID: %d\n", thread_id) > ----- > > ----- setup.py ----- > from distutils.core import setup, Extension > from Cython.Build import cythonize > > extensions = [Extension( > "test", > sources=["test.pyx"], > extra_compile_args=["-fopenmp"], > extra_link_args=["-fopenmp"] > )] > > setup( > ext_modules = cythonize(extensions) > ) > ---- > python setup.py build_ext --inplace > > On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < > elef at indiana.edu> wrote: > > Hi Emanuele, > > Here is an example of how we calculated the distance matrix in parallel > (for the MDF) using OpenMP > https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx > > You can just add another function that does the same using mam. It should > be really easy to implement as we have > already done it for the MDF for speeding up SLR. > > Then we need to update the bundle_distances* functions to use the parallel > versions. > > I'll be happy to help you with this. Let's try to schedule some time to > look at this together. > > Best regards, > Eleftherios > > > On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti > wrote: > > Hi, > > I usually compute the distance matrix between two lists of streamlines > using bundle_distances_mam() or bundle_distances_mdf(). When the lists are > large, it is convenient and easy to exploit the multiple cores of the CPU > because such computation is intrinsically (embarassingly) parallel. At the > moment I'm doing it through the multiprocessing or the joblib modules, > because I cannot find a way directly from DiPy, at least according to what > I see in dipy/tracking/distances.pyx . But consider that I am not > proficient in cython.parallel. > > Is there a preferable way to perform such parallel computation? I plan to > prepare a pull request in future and I'd like to be on the right track. > > Best, > > Emanuele > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > -- > ------------------------------------------------------- > Paolo Avesani > Fondazione Bruno Kessler > via Sommarive 18, > 38050 Povo (TN) - I > phone: +39 0461 314336 <+39%200461%20314336> > fax: +39 0461 302040 <+39%200461%20302040> > email: avesani at fbk.eu > web: avesani.fbk.eu > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.meesters at gmail.com Wed Dec 14 16:04:34 2016 From: stephan.meesters at gmail.com (Stephan Meesters) Date: Wed, 14 Dec 2016 22:04:34 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Hi, The instructions at http://nipy.org/dipy/installation.html#openmp-with-osx are outdated since the clang-omp formula does not exist anymore. With the release of Clang 3.8.0 (08 Mar 2016), OpenMP 3.1 support is enabled in Clang by default. You will need the -fopenmp=libomp flag while building. I started a while back on a DIPY homebrew formula to allow installation via "brew install dipy", see https://github.com/Homebrew/homebrew-python/pull/310. However it was based around the deprecated clang-omp and I didn't get around to fix it. Might look into it soon if I find some spare time to tweak the formula. Regards, Stephan 2016-12-14 17:14 GMT+01:00 Samuel St-Jean : > That also depends on which version of clang ships by default with osx, in > which case you have to play around with it to get a new one. I think it > starts with clang 3.7 to have openmp support (I only ever tried Mac osx > 10.9, so anyone more experienced can chime in), but everything older has to > go through the hombebrew gcc install and company. Might be worhtwhile to > check if openmp support is out of the box now, and starting on which mac > osx versions, since older ones could be problematic for first time > installs. > > I also have to admit I have no idea how old is old in the mac world, so > maybe 10.9 is already phased out by now, but it was a hard and time > consuming building around stuff with homebrew experience (and again, first > time I used a mac, so, I guess the average user would also have some > issues). > > Samuel > > 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis : > >> >> Hi Emanuele, >> >> My understanding is that openmp was only temporarily not available when >> clang replaced gcc in osx. >> >> So, I would suggest to go ahead with openmp. Any current installation >> issues are only temporarily for osx. >> Openmp gives us a lot of capability to play with shared memory and it is >> a standard that will be around >> for very long time. Also, the great integration in cython makes the >> algorithms really easy to read. >> So, especially for this project my recommendation is to use openmp rather >> than multiprocessing. All the way! :) >> >> I am CC'ing Stephan who wrote the instructions for osx. I am sure he can >> help you with this. I would also suggest >> to check if xcode provides any new guis for enabling openmp. I remember >> there was something for that. >> >> Laterz! >> Eleftherios >> >> >> >> >> On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti >> wrote: >> >>> Hi Eleftherios, >>> >>> Thank you for pointing me to the MDF example. From what I see the Cython >>> syntax is not complex, which is good. >>> >>> My only concern is the availability of OpenMP in the systems where DiPy >>> is used. On a reasonably recent GNU/Linux machine it seems straightforward >>> to have libgomp and the proper version of gcc. On other systems - say OSX - >>> the situation is less clear to me. According to what I read here >>> http://nipy.org/dipy/installation.html#openmp-with-osx >>> the OSX installation steps are not meant for standard end users. Are >>> those instructions updated? >>> As a test of that, we've just tried to skip the steps described above >>> and instead to install gcc with conda on OSX ("conda install gcc"). In the >>> process, conda installed the recent gcc-4.8 with libgomp, which seems good >>> news. Unfortunately, when we tried to compile a simple example of Cython >>> code using parallelization (see below), the process failed (fatal error: >>> limits.h : no such file or directory)... >>> >>> For the reasons above, I am wondering whether the very simple solution >>> of using the "multiprocessing" module, available from the standard Python >>> library, may be an acceptable first step towards the more efficient >>> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >>> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >>> does not require to have Cython code, because it works on plain Python too. >>> >>> Best, >>> >>> Emanuele >>> >>> ---- test.pyx ---- >>> from cython import parallel >>> from libc.stdio cimport printf >>> >>> def test_func(): >>> cdef int thread_id = -1 >>> with nogil, parallel.parallel(num_threads=10): >>> thread_id = parallel.threadid() >>> printf("Thread ID: %d\n", thread_id) >>> ----- >>> >>> ----- setup.py ----- >>> from distutils.core import setup, Extension >>> from Cython.Build import cythonize >>> >>> extensions = [Extension( >>> "test", >>> sources=["test.pyx"], >>> extra_compile_args=["-fopenmp"], >>> extra_link_args=["-fopenmp"] >>> )] >>> >>> setup( >>> ext_modules = cythonize(extensions) >>> ) >>> ---- >>> python setup.py build_ext --inplace >>> >>> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >>> elef at indiana.edu> wrote: >>> >>> Hi Emanuele, >>> >>> Here is an example of how we calculated the distance matrix in parallel >>> (for the MDF) using OpenMP >>> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >>> >>> You can just add another function that does the same using mam. It >>> should be really easy to implement as we have >>> already done it for the MDF for speeding up SLR. >>> >>> Then we need to update the bundle_distances* functions to use the >>> parallel versions. >>> >>> I'll be happy to help you with this. Let's try to schedule some time to >>> look at this together. >>> >>> Best regards, >>> Eleftherios >>> >>> >>> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >>> wrote: >>> >>> Hi, >>> >>> I usually compute the distance matrix between two lists of streamlines >>> using bundle_distances_mam() or bundle_distances_mdf(). When the lists are >>> large, it is convenient and easy to exploit the multiple cores of the CPU >>> because such computation is intrinsically (embarassingly) parallel. At the >>> moment I'm doing it through the multiprocessing or the joblib modules, >>> because I cannot find a way directly from DiPy, at least according to what >>> I see in dipy/tracking/distances.pyx . But consider that I am not >>> proficient in cython.parallel. >>> >>> Is there a preferable way to perform such parallel computation? I plan >>> to prepare a pull request in future and I'd like to be on the right track. >>> >>> Best, >>> >>> Emanuele >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivetti at fbk.eu Thu Dec 15 03:41:28 2016 From: olivetti at fbk.eu (Emanuele Olivetti) Date: Thu, 15 Dec 2016 09:41:28 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Thank you to all of you for the many details that help to clear up the picture. It is my understanding that even the last version of OSX, i.e. v10.12.*, does not support libomp within the Apple's Xcode development framework. At the same time, future version should support it, at some point. Honestly, this does not seem an ideal scenario, because not many OSX users chase the latest versions of the opeating system, while everyone has multiple cores since many years. For the same reason, I doubt that contacting the Xcode side may bring us closer to the solution. To Ariel: if you want to test that OpemMP works, once you build test.so, just import it in the Python console and execute test.test_func(). You should get this: --- >>> import test >>> test.test_func() Thread ID: 2 Thread ID: 8 Thread ID: 7 Thread ID: 3 Thread ID: 4 Thread ID: 5 Thread ID: 6 Thread ID: 0 Thread ID: 1 Thread ID: 9 --- If you do not enable the OpenMP support (just comment out the two related lines in setup.py and re-build), the output will differ and only one thread will show up: --- >>> import test >>> test.test_func() Thread ID: 0 --- Anyway, what surprises me most is the failure of Anaconda's gcc+libgomp on OSX. In principle that toolchain is exactly the same as on GNU/Linux, so I see no reason for it fail. I'll try to dig more into this one. To Eleftherios: I agree with you that OpenMP is the best technical solution, because the use of threads - which shares memory - is definitely more preferable than multiprocessing - which replicates data in each process. Anyway, the limitations I see are still there: 1) OpenMP support seems problematic on non-GNU/Linux systems. By the way, what is the situation on Windows? Here we don't have such system so we couldn't try. 2) OpemMP works only with Cython code. This means that no Python part of DiPy can use parallel execution. This seems a bit too excessive to me, because I expect that not all parts of DiPy will be re-written in Cython, in the foreseeable future. So, again, I advocate for some use of the standard multiprocessing module :) as an temporary step when OpenMP cannot be used. Best, Emanuele On Wed, Dec 14, 2016 at 10:04 PM, Stephan Meesters < stephan.meesters at gmail.com> wrote: > Hi, > > The instructions at http://nipy.org/dipy/installation.html#openmp-with-osx > are outdated since the clang-omp formula does not exist anymore. > > With the release of Clang 3.8.0 (08 Mar 2016), OpenMP 3.1 support is > enabled in Clang by default. You will need the -fopenmp=libomp flag while > building. > > I started a while back on a DIPY homebrew formula to allow installation > via "brew install dipy", see https://github.com/Homebrew/ > homebrew-python/pull/310. However it was based around the deprecated > clang-omp and I didn't get around to fix it. Might look into it soon if I > find some spare time to tweak the formula. > > Regards, > Stephan > > 2016-12-14 17:14 GMT+01:00 Samuel St-Jean : > >> That also depends on which version of clang ships by default with osx, in >> which case you have to play around with it to get a new one. I think it >> starts with clang 3.7 to have openmp support (I only ever tried Mac osx >> 10.9, so anyone more experienced can chime in), but everything older has to >> go through the hombebrew gcc install and company. Might be worhtwhile to >> check if openmp support is out of the box now, and starting on which mac >> osx versions, since older ones could be problematic for first time >> installs. >> >> I also have to admit I have no idea how old is old in the mac world, so >> maybe 10.9 is already phased out by now, but it was a hard and time >> consuming building around stuff with homebrew experience (and again, first >> time I used a mac, so, I guess the average user would also have some >> issues). >> >> Samuel >> >> 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis : >> >>> >>> Hi Emanuele, >>> >>> My understanding is that openmp was only temporarily not available when >>> clang replaced gcc in osx. >>> >>> So, I would suggest to go ahead with openmp. Any current installation >>> issues are only temporarily for osx. >>> Openmp gives us a lot of capability to play with shared memory and it is >>> a standard that will be around >>> for very long time. Also, the great integration in cython makes the >>> algorithms really easy to read. >>> So, especially for this project my recommendation is to use openmp >>> rather than multiprocessing. All the way! :) >>> >>> I am CC'ing Stephan who wrote the instructions for osx. I am sure he can >>> help you with this. I would also suggest >>> to check if xcode provides any new guis for enabling openmp. I remember >>> there was something for that. >>> >>> Laterz! >>> Eleftherios >>> >>> >>> >>> >>> On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti >>> wrote: >>> >>>> Hi Eleftherios, >>>> >>>> Thank you for pointing me to the MDF example. From what I see the >>>> Cython syntax is not complex, which is good. >>>> >>>> My only concern is the availability of OpenMP in the systems where DiPy >>>> is used. On a reasonably recent GNU/Linux machine it seems straightforward >>>> to have libgomp and the proper version of gcc. On other systems - say OSX - >>>> the situation is less clear to me. According to what I read here >>>> http://nipy.org/dipy/installation.html#openmp-with-osx >>>> the OSX installation steps are not meant for standard end users. Are >>>> those instructions updated? >>>> As a test of that, we've just tried to skip the steps described above >>>> and instead to install gcc with conda on OSX ("conda install gcc"). In the >>>> process, conda installed the recent gcc-4.8 with libgomp, which seems good >>>> news. Unfortunately, when we tried to compile a simple example of Cython >>>> code using parallelization (see below), the process failed (fatal error: >>>> limits.h : no such file or directory)... >>>> >>>> For the reasons above, I am wondering whether the very simple solution >>>> of using the "multiprocessing" module, available from the standard Python >>>> library, may be an acceptable first step towards the more efficient >>>> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >>>> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >>>> does not require to have Cython code, because it works on plain Python too. >>>> >>>> Best, >>>> >>>> Emanuele >>>> >>>> ---- test.pyx ---- >>>> from cython import parallel >>>> from libc.stdio cimport printf >>>> >>>> def test_func(): >>>> cdef int thread_id = -1 >>>> with nogil, parallel.parallel(num_threads=10): >>>> thread_id = parallel.threadid() >>>> printf("Thread ID: %d\n", thread_id) >>>> ----- >>>> >>>> ----- setup.py ----- >>>> from distutils.core import setup, Extension >>>> from Cython.Build import cythonize >>>> >>>> extensions = [Extension( >>>> "test", >>>> sources=["test.pyx"], >>>> extra_compile_args=["-fopenmp"], >>>> extra_link_args=["-fopenmp"] >>>> )] >>>> >>>> setup( >>>> ext_modules = cythonize(extensions) >>>> ) >>>> ---- >>>> python setup.py build_ext --inplace >>>> >>>> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >>>> elef at indiana.edu> wrote: >>>> >>>> Hi Emanuele, >>>> >>>> Here is an example of how we calculated the distance matrix in parallel >>>> (for the MDF) using OpenMP >>>> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >>>> >>>> You can just add another function that does the same using mam. It >>>> should be really easy to implement as we have >>>> already done it for the MDF for speeding up SLR. >>>> >>>> Then we need to update the bundle_distances* functions to use the >>>> parallel versions. >>>> >>>> I'll be happy to help you with this. Let's try to schedule some time to >>>> look at this together. >>>> >>>> Best regards, >>>> Eleftherios >>>> >>>> >>>> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >>>> wrote: >>>> >>>> Hi, >>>> >>>> I usually compute the distance matrix between two lists of streamlines >>>> using bundle_distances_mam() or bundle_distances_mdf(). When the lists are >>>> large, it is convenient and easy to exploit the multiple cores of the CPU >>>> because such computation is intrinsically (embarassingly) parallel. At the >>>> moment I'm doing it through the multiprocessing or the joblib modules, >>>> because I cannot find a way directly from DiPy, at least according to what >>>> I see in dipy/tracking/distances.pyx . But consider that I am not >>>> proficient in cython.parallel. >>>> >>>> Is there a preferable way to perform such parallel computation? I plan >>>> to prepare a pull request in future and I'd like to be on the right track. >>>> >>>> Best, >>>> >>>> Emanuele >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Thu Dec 15 08:54:24 2016 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Thu, 15 Dec 2016 13:54:24 +0000 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Let's not be rushed to change API decisions that we have been investigating for years. The multiprocessing framework has its own can of worms. And I would personally not spend time to develop the algorithm twice. I mean once for multiprocessing and once for openmp. But that is your call. Also, let's leave Stephan a bit of time to investigate this. And let's also ask in Anaconda, Cython and Clang for suggestions on how to solve this installation problem. We need to figure out this independently of your contribution. OpenMP is fine with Windows and Linux. And as I said just develop it as we did and only temporarily in OSX you will have things single threaded. Because Apple decided to make radical changes we shouldn't be changing our protocols. Especially when they are well established standards. Yes, we use multiprocessing for the reconstruction step. But anyway you are not helping me here because you haven't show me your code yet. Show us the code! :D And please give us some days to investigate the issue. On Thu, Dec 15, 2016 at 3:42 AM Emanuele Olivetti wrote: Thank you to all of you for the many details that help to clear up the picture. It is my understanding that even the last version of OSX, i.e. v10.12.*, does not support libomp within the Apple's Xcode development framework. At the same time, future version should support it, at some point. Honestly, this does not seem an ideal scenario, because not many OSX users chase the latest versions of the opeating system, while everyone has multiple cores since many years. For the same reason, I doubt that contacting the Xcode side may bring us closer to the solution. To Ariel: if you want to test that OpemMP works, once you build test.so, just import it in the Python console and execute test.test_func(). You should get this: --- >>> import test >>> test.test_func() Thread ID: 2 Thread ID: 8 Thread ID: 7 Thread ID: 3 Thread ID: 4 Thread ID: 5 Thread ID: 6 Thread ID: 0 Thread ID: 1 Thread ID: 9 --- If you do not enable the OpenMP support (just comment out the two related lines in setup.py and re-build), the output will differ and only one thread will show up: --- >>> import test >>> test.test_func() Thread ID: 0 --- Anyway, what surprises me most is the failure of Anaconda's gcc+libgomp on OSX. In principle that toolchain is exactly the same as on GNU/Linux, so I see no reason for it fail. I'll try to dig more into this one. To Eleftherios: I agree with you that OpenMP is the best technical solution, because the use of threads - which shares memory - is definitely more preferable than multiprocessing - which replicates data in each process. Anyway, the limitations I see are still there: 1) OpenMP support seems problematic on non-GNU/Linux systems. By the way, what is the situation on Windows? Here we don't have such system so we couldn't try. 2) OpemMP works only with Cython code. This means that no Python part of DiPy can use parallel execution. This seems a bit too excessive to me, because I expect that not all parts of DiPy will be re-written in Cython, in the foreseeable future. So, again, I advocate for some use of the standard multiprocessing module :) as an temporary step when OpenMP cannot be used. Best, Emanuele On Wed, Dec 14, 2016 at 10:04 PM, Stephan Meesters < stephan.meesters at gmail.com> wrote: Hi, The instructions at http://nipy.org/dipy/installation.html#openmp-with-osx are outdated since the clang-omp formula does not exist anymore. With the release of Clang 3.8.0 (08 Mar 2016), OpenMP 3.1 support is enabled in Clang by default. You will need the -fopenmp=libomp flag while building. I started a while back on a DIPY homebrew formula to allow installation via "brew install dipy", see https://github.com/Homebrew/homebrew-python/pull/310. However it was based around the deprecated clang-omp and I didn't get around to fix it. Might look into it soon if I find some spare time to tweak the formula. Regards, Stephan 2016-12-14 17:14 GMT+01:00 Samuel St-Jean : That also depends on which version of clang ships by default with osx, in which case you have to play around with it to get a new one. I think it starts with clang 3.7 to have openmp support (I only ever tried Mac osx 10.9, so anyone more experienced can chime in), but everything older has to go through the hombebrew gcc install and company. Might be worhtwhile to check if openmp support is out of the box now, and starting on which mac osx versions, since older ones could be problematic for first time installs. I also have to admit I have no idea how old is old in the mac world, so maybe 10.9 is already phased out by now, but it was a hard and time consuming building around stuff with homebrew experience (and again, first time I used a mac, so, I guess the average user would also have some issues). Samuel 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis : Hi Emanuele, My understanding is that openmp was only temporarily not available when clang replaced gcc in osx. So, I would suggest to go ahead with openmp. Any current installation issues are only temporarily for osx. Openmp gives us a lot of capability to play with shared memory and it is a standard that will be around for very long time. Also, the great integration in cython makes the algorithms really easy to read. So, especially for this project my recommendation is to use openmp rather than multiprocessing. All the way! :) I am CC'ing Stephan who wrote the instructions for osx. I am sure he can help you with this. I would also suggest to check if xcode provides any new guis for enabling openmp. I remember there was something for that. Laterz! Eleftherios On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti wrote: Hi Eleftherios, Thank you for pointing me to the MDF example. From what I see the Cython syntax is not complex, which is good. My only concern is the availability of OpenMP in the systems where DiPy is used. On a reasonably recent GNU/Linux machine it seems straightforward to have libgomp and the proper version of gcc. On other systems - say OSX - the situation is less clear to me. According to what I read here http://nipy.org/dipy/installation.html#openmp-with-osx the OSX installation steps are not meant for standard end users. Are those instructions updated? As a test of that, we've just tried to skip the steps described above and instead to install gcc with conda on OSX ("conda install gcc"). In the process, conda installed the recent gcc-4.8 with libgomp, which seems good news. Unfortunately, when we tried to compile a simple example of Cython code using parallelization (see below), the process failed (fatal error: limits.h : no such file or directory)... For the reasons above, I am wondering whether the very simple solution of using the "multiprocessing" module, available from the standard Python library, may be an acceptable first step towards the more efficient multithreading of Cython/libgomp. With "multiprocessing", there is no extra dependency on libgomp, or recent gcc or else. Moreover, multiprocessing does not require to have Cython code, because it works on plain Python too. Best, Emanuele ---- test.pyx ---- from cython import parallel from libc.stdio cimport printf def test_func(): cdef int thread_id = -1 with nogil, parallel.parallel(num_threads=10): thread_id = parallel.threadid() printf("Thread ID: %d\n", thread_id) ----- ----- setup.py ----- from distutils.core import setup, Extension from Cython.Build import cythonize extensions = [Extension( "test", sources=["test.pyx"], extra_compile_args=["-fopenmp"], extra_link_args=["-fopenmp"] )] setup( ext_modules = cythonize(extensions) ) ---- python setup.py build_ext --inplace On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis wrote: Hi Emanuele, Here is an example of how we calculated the distance matrix in parallel (for the MDF) using OpenMP https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx You can just add another function that does the same using mam. It should be really easy to implement as we have already done it for the MDF for speeding up SLR. Then we need to update the bundle_distances* functions to use the parallel versions. I'll be happy to help you with this. Let's try to schedule some time to look at this together. Best regards, Eleftherios On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti wrote: Hi, I usually compute the distance matrix between two lists of streamlines using bundle_distances_mam() or bundle_distances_mdf(). When the lists are large, it is convenient and easy to exploit the multiple cores of the CPU because such computation is intrinsically (embarassingly) parallel. At the moment I'm doing it through the multiprocessing or the joblib modules, because I cannot find a way directly from DiPy, at least according to what I see in dipy/tracking/distances.pyx . But consider that I am not proficient in cython.parallel. Is there a preferable way to perform such parallel computation? I plan to prepare a pull request in future and I'd like to be on the right track. Best, Emanuele _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Dec 15 10:09:32 2016 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 15 Dec 2016 07:09:32 -0800 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Emanule, On Thu, Dec 15, 2016 at 12:41 AM, Emanuele Olivetti wrote: > Thank you to all of you for the many details that help to clear up the > picture. > > It is my understanding that even the last version of OSX, i.e. v10.12.*, > does not support libomp within the Apple's Xcode development framework. At > the same time, future version should support it, at some point. Honestly, > this does not seem an ideal scenario, because not many OSX users chase the > latest versions of the opeating system, while everyone has multiple cores > since many years. For the same reason, I doubt that contacting the Xcode > side may bring us closer to the solution. > To Ariel: if you want to test that OpemMP works, once you build test.so, > just import it in the Python console and execute test.test_func(). You > should get this: > Was there supposed to be a file attached? Thanks! Ariel > --- > >>> import test > >>> test.test_func() > Thread ID: 2 > Thread ID: 8 > Thread ID: 7 > Thread ID: 3 > Thread ID: 4 > Thread ID: 5 > Thread ID: 6 > Thread ID: 0 > Thread ID: 1 > Thread ID: 9 > --- > If you do not enable the OpenMP support (just comment out the two related > lines in setup.py and re-build), the output will differ and only one thread > will show up: > --- > >>> import test > >>> test.test_func() > Thread ID: 0 > --- > > Anyway, what surprises me most is the failure of Anaconda's gcc+libgomp on > OSX. In principle that toolchain is exactly the same as on GNU/Linux, so I > see no reason for it fail. I'll try to dig more into this one. > > To Eleftherios: I agree with you that OpenMP is the best technical > solution, because the use of threads - which shares memory - is definitely > more preferable than multiprocessing - which replicates data in each > process. Anyway, the limitations I see are still there: > 1) OpenMP support seems problematic on non-GNU/Linux systems. By the way, > what is the situation on Windows? Here we don't have such system so we > couldn't try. > 2) OpemMP works only with Cython code. This means that no Python part of > DiPy can use parallel execution. This seems a bit too excessive to me, > because I expect that not all parts of DiPy will be re-written in Cython, > in the foreseeable future. > > So, again, I advocate for some use of the standard multiprocessing module > :) as an temporary step when OpenMP cannot be used. > > Best, > > Emanuele > > > On Wed, Dec 14, 2016 at 10:04 PM, Stephan Meesters < > stephan.meesters at gmail.com> wrote: > >> Hi, >> >> The instructions at http://nipy.org/dipy/instal >> lation.html#openmp-with-osx are outdated since the clang-omp formula >> does not exist anymore. >> >> With the release of Clang 3.8.0 (08 Mar 2016), OpenMP 3.1 support is >> enabled in Clang by default. You will need the -fopenmp=libomp flag while >> building. >> >> I started a while back on a DIPY homebrew formula to allow installation >> via "brew install dipy", see https://github.com/Homebrew/ho >> mebrew-python/pull/310. However it was based around the deprecated >> clang-omp and I didn't get around to fix it. Might look into it soon if I >> find some spare time to tweak the formula. >> >> Regards, >> Stephan >> >> 2016-12-14 17:14 GMT+01:00 Samuel St-Jean : >> >>> That also depends on which version of clang ships by default with osx, >>> in which case you have to play around with it to get a new one. I think it >>> starts with clang 3.7 to have openmp support (I only ever tried Mac osx >>> 10.9, so anyone more experienced can chime in), but everything older has to >>> go through the hombebrew gcc install and company. Might be worhtwhile to >>> check if openmp support is out of the box now, and starting on which mac >>> osx versions, since older ones could be problematic for first time >>> installs. >>> >>> I also have to admit I have no idea how old is old in the mac world, so >>> maybe 10.9 is already phased out by now, but it was a hard and time >>> consuming building around stuff with homebrew experience (and again, first >>> time I used a mac, so, I guess the average user would also have some >>> issues). >>> >>> Samuel >>> >>> 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis : >>> >>>> >>>> Hi Emanuele, >>>> >>>> My understanding is that openmp was only temporarily not available when >>>> clang replaced gcc in osx. >>>> >>>> So, I would suggest to go ahead with openmp. Any current installation >>>> issues are only temporarily for osx. >>>> Openmp gives us a lot of capability to play with shared memory and it >>>> is a standard that will be around >>>> for very long time. Also, the great integration in cython makes the >>>> algorithms really easy to read. >>>> So, especially for this project my recommendation is to use openmp >>>> rather than multiprocessing. All the way! :) >>>> >>>> I am CC'ing Stephan who wrote the instructions for osx. I am sure he >>>> can help you with this. I would also suggest >>>> to check if xcode provides any new guis for enabling openmp. I remember >>>> there was something for that. >>>> >>>> Laterz! >>>> Eleftherios >>>> >>>> >>>> >>>> >>>> On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti >>>> wrote: >>>> >>>>> Hi Eleftherios, >>>>> >>>>> Thank you for pointing me to the MDF example. From what I see the >>>>> Cython syntax is not complex, which is good. >>>>> >>>>> My only concern is the availability of OpenMP in the systems where >>>>> DiPy is used. On a reasonably recent GNU/Linux machine it seems >>>>> straightforward to have libgomp and the proper version of gcc. On other >>>>> systems - say OSX - the situation is less clear to me. According to what I >>>>> read here >>>>> http://nipy.org/dipy/installation.html#openmp-with-osx >>>>> the OSX installation steps are not meant for standard end users. Are >>>>> those instructions updated? >>>>> As a test of that, we've just tried to skip the steps described above >>>>> and instead to install gcc with conda on OSX ("conda install gcc"). In the >>>>> process, conda installed the recent gcc-4.8 with libgomp, which seems good >>>>> news. Unfortunately, when we tried to compile a simple example of Cython >>>>> code using parallelization (see below), the process failed (fatal error: >>>>> limits.h : no such file or directory)... >>>>> >>>>> For the reasons above, I am wondering whether the very simple solution >>>>> of using the "multiprocessing" module, available from the standard Python >>>>> library, may be an acceptable first step towards the more efficient >>>>> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >>>>> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >>>>> does not require to have Cython code, because it works on plain Python too. >>>>> >>>>> Best, >>>>> >>>>> Emanuele >>>>> >>>>> ---- test.pyx ---- >>>>> from cython import parallel >>>>> from libc.stdio cimport printf >>>>> >>>>> def test_func(): >>>>> cdef int thread_id = -1 >>>>> with nogil, parallel.parallel(num_threads=10): >>>>> thread_id = parallel.threadid() >>>>> printf("Thread ID: %d\n", thread_id) >>>>> ----- >>>>> >>>>> ----- setup.py ----- >>>>> from distutils.core import setup, Extension >>>>> from Cython.Build import cythonize >>>>> >>>>> extensions = [Extension( >>>>> "test", >>>>> sources=["test.pyx"], >>>>> extra_compile_args=["-fopenmp"], >>>>> extra_link_args=["-fopenmp"] >>>>> )] >>>>> >>>>> setup( >>>>> ext_modules = cythonize(extensions) >>>>> ) >>>>> ---- >>>>> python setup.py build_ext --inplace >>>>> >>>>> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >>>>> elef at indiana.edu> wrote: >>>>> >>>>> Hi Emanuele, >>>>> >>>>> Here is an example of how we calculated the distance matrix in >>>>> parallel (for the MDF) using OpenMP >>>>> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >>>>> >>>>> You can just add another function that does the same using mam. It >>>>> should be really easy to implement as we have >>>>> already done it for the MDF for speeding up SLR. >>>>> >>>>> Then we need to update the bundle_distances* functions to use the >>>>> parallel versions. >>>>> >>>>> I'll be happy to help you with this. Let's try to schedule some time >>>>> to look at this together. >>>>> >>>>> Best regards, >>>>> Eleftherios >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I usually compute the distance matrix between two lists of streamlines >>>>> using bundle_distances_mam() or bundle_distances_mdf(). When the lists are >>>>> large, it is convenient and easy to exploit the multiple cores of the CPU >>>>> because such computation is intrinsically (embarassingly) parallel. At the >>>>> moment I'm doing it through the multiprocessing or the joblib modules, >>>>> because I cannot find a way directly from DiPy, at least according to what >>>>> I see in dipy/tracking/distances.pyx . But consider that I am not >>>>> proficient in cython.parallel. >>>>> >>>>> Is there a preferable way to perform such parallel computation? I plan >>>>> to prepare a pull request in future and I'd like to be on the right track. >>>>> >>>>> Best, >>>>> >>>>> Emanuele >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivetti at fbk.eu Thu Dec 15 10:43:39 2016 From: olivetti at fbk.eu (Emanuele Olivetti) Date: Thu, 15 Dec 2016 16:43:39 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Hi Eleftherios, Sorry I did not mean to rush. Moreover, I am not against OpenMP at all, so for sure collecting more information about it and OSX is valuable in any case. I am happy Stephan is looking into that. As for my plan, I guess the first step is to try to extend bundle_distance_*() with OpenMP, since that is "the" meaningful choice given the code is already in Cython. I was also considering to add a further layer (wrapper) that uses multiprocessing when OpenMP is not available and the user requires to use multiple cores. I already do that in my code, but I want to better understand how this fits with the DiPy's API design. As for using multiprocessing, I see it as a viable solution when memory is not an issue and the code is pure Python (or when OpenMP is an issue). As you correctly report, multiprocessing is already used in DiPy, so I was trying to understand whether it was something deprecated or not. So from now on I will assume it is not ;) Best, Emanuele On Thu, Dec 15, 2016 at 2:54 PM, Eleftherios Garyfallidis wrote: > Let's not be rushed to change API decisions that we have been > investigating for years. The multiprocessing framework has its own can of > worms. And I would personally not spend time to develop the algorithm > twice. I mean once for multiprocessing and once for openmp. But that is > your call. > > Also, let's leave Stephan a bit of time to investigate this. And let's > also ask in Anaconda, Cython and Clang for suggestions on how to solve this > installation problem. We need to figure out this independently of your > contribution. > > OpenMP is fine with Windows and Linux. And as I said just develop it as we > did and only temporarily in OSX you will have things single threaded. > Because Apple decided to make radical changes we shouldn't be changing our > protocols. Especially when they are well established standards. > > Yes, we use multiprocessing for the reconstruction step. But anyway you > are not helping me here because you haven't show me your code yet. Show us > the code! :D > > And please give us some days to investigate the issue. > > On Thu, Dec 15, 2016 at 3:42 AM Emanuele Olivetti wrote: > > Thank you to all of you for the many details that help to clear up the > picture. > > It is my understanding that even the last version of OSX, i.e. v10.12.*, > does not support libomp within the Apple's Xcode development framework. At > the same time, future version should support it, at some point. Honestly, > this does not seem an ideal scenario, because not many OSX users chase the > latest versions of the opeating system, while everyone has multiple cores > since many years. For the same reason, I doubt that contacting the Xcode > side may bring us closer to the solution. > To Ariel: if you want to test that OpemMP works, once you build test.so, > just import it in the Python console and execute test.test_func(). You > should get this: > --- > >>> import test > >>> test.test_func() > Thread ID: 2 > Thread ID: 8 > Thread ID: 7 > Thread ID: 3 > Thread ID: 4 > Thread ID: 5 > Thread ID: 6 > Thread ID: 0 > Thread ID: 1 > Thread ID: 9 > --- > If you do not enable the OpenMP support (just comment out the two related > lines in setup.py and re-build), the output will differ and only one thread > will show up: > --- > >>> import test > >>> test.test_func() > Thread ID: 0 > --- > > Anyway, what surprises me most is the failure of Anaconda's gcc+libgomp on > OSX. In principle that toolchain is exactly the same as on GNU/Linux, so I > see no reason for it fail. I'll try to dig more into this one. > > To Eleftherios: I agree with you that OpenMP is the best technical > solution, because the use of threads - which shares memory - is definitely > more preferable than multiprocessing - which replicates data in each > process. Anyway, the limitations I see are still there: > 1) OpenMP support seems problematic on non-GNU/Linux systems. By the way, > what is the situation on Windows? Here we don't have such system so we > couldn't try. > 2) OpemMP works only with Cython code. This means that no Python part of > DiPy can use parallel execution. This seems a bit too excessive to me, > because I expect that not all parts of DiPy will be re-written in Cython, > in the foreseeable future. > > So, again, I advocate for some use of the standard multiprocessing module > :) as an temporary step when OpenMP cannot be used. > > Best, > > Emanuele > > > On Wed, Dec 14, 2016 at 10:04 PM, Stephan Meesters < > stephan.meesters at gmail.com> wrote: > > Hi, > > The instructions at http://nipy.org/dipy/installation.html#openmp-with-osx are > outdated since the clang-omp formula does not exist anymore. > > With the release of Clang 3.8.0 (08 Mar 2016), OpenMP 3.1 support is > enabled in Clang by default. You will need the -fopenmp=libomp flag while > building. > > I started a while back on a DIPY homebrew formula to allow installation > via "brew install dipy", see https://github.com/Homebrew/ > homebrew-python/pull/310. However it was based around the deprecated > clang-omp and I didn't get around to fix it. Might look into it soon if I > find some spare time to tweak the formula. > > Regards, > Stephan > > 2016-12-14 17:14 GMT+01:00 Samuel St-Jean : > > That also depends on which version of clang ships by default with osx, in > which case you have to play around with it to get a new one. I think it > starts with clang 3.7 to have openmp support (I only ever tried Mac osx > 10.9, so anyone more experienced can chime in), but everything older has to > go through the hombebrew gcc install and company. Might be worhtwhile to > check if openmp support is out of the box now, and starting on which mac > osx versions, since older ones could be problematic for first time > installs. > > I also have to admit I have no idea how old is old in the mac world, so > maybe 10.9 is already phased out by now, but it was a hard and time > consuming building around stuff with homebrew experience (and again, first > time I used a mac, so, I guess the average user would also have some > issues). > > Samuel > > 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis : > > > Hi Emanuele, > > My understanding is that openmp was only temporarily not available when > clang replaced gcc in osx. > > So, I would suggest to go ahead with openmp. Any current installation > issues are only temporarily for osx. > Openmp gives us a lot of capability to play with shared memory and it is a > standard that will be around > for very long time. Also, the great integration in cython makes the > algorithms really easy to read. > So, especially for this project my recommendation is to use openmp rather > than multiprocessing. All the way! :) > > I am CC'ing Stephan who wrote the instructions for osx. I am sure he can > help you with this. I would also suggest > to check if xcode provides any new guis for enabling openmp. I remember > there was something for that. > > Laterz! > Eleftherios > > > > > On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti wrote: > > Hi Eleftherios, > > Thank you for pointing me to the MDF example. From what I see the Cython > syntax is not complex, which is good. > > My only concern is the availability of OpenMP in the systems where DiPy is > used. On a reasonably recent GNU/Linux machine it seems straightforward to > have libgomp and the proper version of gcc. On other systems - say OSX - > the situation is less clear to me. According to what I read here > http://nipy.org/dipy/installation.html#openmp-with-osx > the OSX installation steps are not meant for standard end users. Are those > instructions updated? > As a test of that, we've just tried to skip the steps described above and > instead to install gcc with conda on OSX ("conda install gcc"). In the > process, conda installed the recent gcc-4.8 with libgomp, which seems good > news. Unfortunately, when we tried to compile a simple example of Cython > code using parallelization (see below), the process failed (fatal error: > limits.h : no such file or directory)... > > For the reasons above, I am wondering whether the very simple solution of > using the "multiprocessing" module, available from the standard Python > library, may be an acceptable first step towards the more efficient > multithreading of Cython/libgomp. With "multiprocessing", there is no extra > dependency on libgomp, or recent gcc or else. Moreover, multiprocessing > does not require to have Cython code, because it works on plain Python too. > > Best, > > Emanuele > > ---- test.pyx ---- > from cython import parallel > from libc.stdio cimport printf > > def test_func(): > cdef int thread_id = -1 > with nogil, parallel.parallel(num_threads=10): > thread_id = parallel.threadid() > printf("Thread ID: %d\n", thread_id) > ----- > > ----- setup.py ----- > from distutils.core import setup, Extension > from Cython.Build import cythonize > > extensions = [Extension( > "test", > sources=["test.pyx"], > extra_compile_args=["-fopenmp"], > extra_link_args=["-fopenmp"] > )] > > setup( > ext_modules = cythonize(extensions) > ) > ---- > python setup.py build_ext --inplace > > On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < > elef at indiana.edu> wrote: > > Hi Emanuele, > > Here is an example of how we calculated the distance matrix in parallel > (for the MDF) using OpenMP > https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx > > You can just add another function that does the same using mam. It should > be really easy to implement as we have > already done it for the MDF for speeding up SLR. > > Then we need to update the bundle_distances* functions to use the parallel > versions. > > I'll be happy to help you with this. Let's try to schedule some time to > look at this together. > > Best regards, > Eleftherios > > > On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti > wrote: > > Hi, > > I usually compute the distance matrix between two lists of streamlines > using bundle_distances_mam() or bundle_distances_mdf(). When the lists are > large, it is convenient and easy to exploit the multiple cores of the CPU > because such computation is intrinsically (embarassingly) parallel. At the > moment I'm doing it through the multiprocessing or the joblib modules, > because I cannot find a way directly from DiPy, at least according to what > I see in dipy/tracking/distances.pyx . But consider that I am not > proficient in cython.parallel. > > Is there a preferable way to perform such parallel computation? I plan to > prepare a pull request in future and I'd like to be on the right track. > > Best, > > Emanuele > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivetti at fbk.eu Thu Dec 15 11:02:22 2016 From: olivetti at fbk.eu (Emanuele Olivetti) Date: Thu, 15 Dec 2016 17:02:22 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Hi Ariel, I put the code in a previous message and did not attach it my last message, on purpose. Now I am attaching it here, for your convenience. Notice that is the same test.pyx/setup.py you succeeded to compile on your recent OSX, wihtout OpenMP support. You can just import that module and invoke test.test_func() to see the output I mentioned: python -c "import test; test.test_func()" Anyway, what I now believe is even more interesting, is to test something simpler: https://gist.github.com/romeroyonatan/6a380e189cee4b1290700cbc5259c837 That is a tiny piece of C code that does basically the same of test.pyx but without the extra complexity of Cython. I tried it on GNU/Linux (gcc+libgomp) and it works as expcted. Then I tried it on Paolo's laptop (OSX 10.11.5) and it fails both with CLang and with Anaconda's gcc4.8+libgomp (= "conda install gcc"). So this example narrows down the problem to OpenMP only on OSX - no Python, Cython or else. Could you please try compile and run it? As indicated there, you just need to: gcc -fopenmp hello-openmp.c ./a.out I am very surprised that such a minimal example fails to compile on OSX with Anaconda's gcc4.8+libgomp. If someone has an explanation of such issue, I'd really like to know more about it. Best, Emanuele On Thu, Dec 15, 2016 at 4:09 PM, Ariel Rokem wrote: > Emanule, > > On Thu, Dec 15, 2016 at 12:41 AM, Emanuele Olivetti > wrote: > >> Thank you to all of you for the many details that help to clear up the >> picture. >> >> It is my understanding that even the last version of OSX, i.e. v10.12.*, >> does not support libomp within the Apple's Xcode development framework. At >> the same time, future version should support it, at some point. Honestly, >> this does not seem an ideal scenario, because not many OSX users chase the >> latest versions of the opeating system, while everyone has multiple cores >> since many years. For the same reason, I doubt that contacting the Xcode >> side may bring us closer to the solution. >> To Ariel: if you want to test that OpemMP works, once you build test.so, >> just import it in the Python console and execute test.test_func(). You >> should get this: >> > > Was there supposed to be a file attached? > > Thanks! > > Ariel > > >> --- >> >>> import test >> >>> test.test_func() >> Thread ID: 2 >> Thread ID: 8 >> Thread ID: 7 >> Thread ID: 3 >> Thread ID: 4 >> Thread ID: 5 >> Thread ID: 6 >> Thread ID: 0 >> Thread ID: 1 >> Thread ID: 9 >> --- >> If you do not enable the OpenMP support (just comment out the two related >> lines in setup.py and re-build), the output will differ and only one thread >> will show up: >> --- >> >>> import test >> >>> test.test_func() >> Thread ID: 0 >> --- >> >> Anyway, what surprises me most is the failure of Anaconda's gcc+libgomp >> on OSX. In principle that toolchain is exactly the same as on GNU/Linux, so >> I see no reason for it fail. I'll try to dig more into this one. >> >> To Eleftherios: I agree with you that OpenMP is the best technical >> solution, because the use of threads - which shares memory - is definitely >> more preferable than multiprocessing - which replicates data in each >> process. Anyway, the limitations I see are still there: >> 1) OpenMP support seems problematic on non-GNU/Linux systems. By the way, >> what is the situation on Windows? Here we don't have such system so we >> couldn't try. >> 2) OpemMP works only with Cython code. This means that no Python part of >> DiPy can use parallel execution. This seems a bit too excessive to me, >> because I expect that not all parts of DiPy will be re-written in Cython, >> in the foreseeable future. >> >> So, again, I advocate for some use of the standard multiprocessing module >> :) as an temporary step when OpenMP cannot be used. >> >> Best, >> >> Emanuele >> >> >> On Wed, Dec 14, 2016 at 10:04 PM, Stephan Meesters < >> stephan.meesters at gmail.com> wrote: >> >>> Hi, >>> >>> The instructions at http://nipy.org/dipy/instal >>> lation.html#openmp-with-osx are outdated since the clang-omp formula >>> does not exist anymore. >>> >>> With the release of Clang 3.8.0 (08 Mar 2016), OpenMP 3.1 support is >>> enabled in Clang by default. You will need the -fopenmp=libomp flag while >>> building. >>> >>> I started a while back on a DIPY homebrew formula to allow installation >>> via "brew install dipy", see https://github.com/Homebrew/ho >>> mebrew-python/pull/310. However it was based around the deprecated >>> clang-omp and I didn't get around to fix it. Might look into it soon if I >>> find some spare time to tweak the formula. >>> >>> Regards, >>> Stephan >>> >>> 2016-12-14 17:14 GMT+01:00 Samuel St-Jean : >>> >>>> That also depends on which version of clang ships by default with osx, >>>> in which case you have to play around with it to get a new one. I think it >>>> starts with clang 3.7 to have openmp support (I only ever tried Mac osx >>>> 10.9, so anyone more experienced can chime in), but everything older has to >>>> go through the hombebrew gcc install and company. Might be worhtwhile to >>>> check if openmp support is out of the box now, and starting on which mac >>>> osx versions, since older ones could be problematic for first time >>>> installs. >>>> >>>> I also have to admit I have no idea how old is old in the mac world, so >>>> maybe 10.9 is already phased out by now, but it was a hard and time >>>> consuming building around stuff with homebrew experience (and again, first >>>> time I used a mac, so, I guess the average user would also have some >>>> issues). >>>> >>>> Samuel >>>> >>>> 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis : >>>> >>>>> >>>>> Hi Emanuele, >>>>> >>>>> My understanding is that openmp was only temporarily not available >>>>> when clang replaced gcc in osx. >>>>> >>>>> So, I would suggest to go ahead with openmp. Any current installation >>>>> issues are only temporarily for osx. >>>>> Openmp gives us a lot of capability to play with shared memory and it >>>>> is a standard that will be around >>>>> for very long time. Also, the great integration in cython makes the >>>>> algorithms really easy to read. >>>>> So, especially for this project my recommendation is to use openmp >>>>> rather than multiprocessing. All the way! :) >>>>> >>>>> I am CC'ing Stephan who wrote the instructions for osx. I am sure he >>>>> can help you with this. I would also suggest >>>>> to check if xcode provides any new guis for enabling openmp. I >>>>> remember there was something for that. >>>>> >>>>> Laterz! >>>>> Eleftherios >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti >>>>> wrote: >>>>> >>>>>> Hi Eleftherios, >>>>>> >>>>>> Thank you for pointing me to the MDF example. From what I see the >>>>>> Cython syntax is not complex, which is good. >>>>>> >>>>>> My only concern is the availability of OpenMP in the systems where >>>>>> DiPy is used. On a reasonably recent GNU/Linux machine it seems >>>>>> straightforward to have libgomp and the proper version of gcc. On other >>>>>> systems - say OSX - the situation is less clear to me. According to what I >>>>>> read here >>>>>> http://nipy.org/dipy/installation.html#openmp-with-osx >>>>>> the OSX installation steps are not meant for standard end users. Are >>>>>> those instructions updated? >>>>>> As a test of that, we've just tried to skip the steps described above >>>>>> and instead to install gcc with conda on OSX ("conda install gcc"). In the >>>>>> process, conda installed the recent gcc-4.8 with libgomp, which seems good >>>>>> news. Unfortunately, when we tried to compile a simple example of Cython >>>>>> code using parallelization (see below), the process failed (fatal error: >>>>>> limits.h : no such file or directory)... >>>>>> >>>>>> For the reasons above, I am wondering whether the very simple >>>>>> solution of using the "multiprocessing" module, available from the standard >>>>>> Python library, may be an acceptable first step towards the more efficient >>>>>> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >>>>>> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >>>>>> does not require to have Cython code, because it works on plain Python too. >>>>>> >>>>>> Best, >>>>>> >>>>>> Emanuele >>>>>> >>>>>> ---- test.pyx ---- >>>>>> from cython import parallel >>>>>> from libc.stdio cimport printf >>>>>> >>>>>> def test_func(): >>>>>> cdef int thread_id = -1 >>>>>> with nogil, parallel.parallel(num_threads=10): >>>>>> thread_id = parallel.threadid() >>>>>> printf("Thread ID: %d\n", thread_id) >>>>>> ----- >>>>>> >>>>>> ----- setup.py ----- >>>>>> from distutils.core import setup, Extension >>>>>> from Cython.Build import cythonize >>>>>> >>>>>> extensions = [Extension( >>>>>> "test", >>>>>> sources=["test.pyx"], >>>>>> extra_compile_args=["-fopenmp"], >>>>>> extra_link_args=["-fopenmp"] >>>>>> )] >>>>>> >>>>>> setup( >>>>>> ext_modules = cythonize(extensions) >>>>>> ) >>>>>> ---- >>>>>> python setup.py build_ext --inplace >>>>>> >>>>>> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >>>>>> elef at indiana.edu> wrote: >>>>>> >>>>>> Hi Emanuele, >>>>>> >>>>>> Here is an example of how we calculated the distance matrix in >>>>>> parallel (for the MDF) using OpenMP >>>>>> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >>>>>> >>>>>> You can just add another function that does the same using mam. It >>>>>> should be really easy to implement as we have >>>>>> already done it for the MDF for speeding up SLR. >>>>>> >>>>>> Then we need to update the bundle_distances* functions to use the >>>>>> parallel versions. >>>>>> >>>>>> I'll be happy to help you with this. Let's try to schedule some time >>>>>> to look at this together. >>>>>> >>>>>> Best regards, >>>>>> Eleftherios >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I usually compute the distance matrix between two lists of >>>>>> streamlines using bundle_distances_mam() or bundle_distances_mdf(). When >>>>>> the lists are large, it is convenient and easy to exploit the multiple >>>>>> cores of the CPU because such computation is intrinsically (embarassingly) >>>>>> parallel. At the moment I'm doing it through the multiprocessing or the >>>>>> joblib modules, because I cannot find a way directly from DiPy, at least >>>>>> according to what I see in dipy/tracking/distances.pyx . But consider that >>>>>> I am not proficient in cython.parallel. >>>>>> >>>>>> Is there a preferable way to perform such parallel computation? I >>>>>> plan to prepare a pull request in future and I'd like to be on the right >>>>>> track. >>>>>> >>>>>> Best, >>>>>> >>>>>> Emanuele >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.pyx Type: text/x-python Size: 241 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.py Type: text/x-python Size: 326 bytes Desc: not available URL: From arokem at gmail.com Thu Dec 15 12:49:38 2016 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 15 Dec 2016 09:49:38 -0800 Subject: [Neuroimaging] [DIPY] Fwd: Your Public folder will soon become a private folder Message-ID: This might affect some of our data fetchers: https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L255 https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L279 https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L322 https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L338 https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L379 https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L390 Eleftherios - are these on your Dropbox account? Time to move to Figshare? ---------- Forwarded message ---------- From: Dropbox Date: Thu, Dec 15, 2016 at 9:38 AM Subject: Your Public folder will soon become a private folder To: arokem at gmail.com Hi Ariel, We?re always looking to improve the Dropbox sharing experience. The Public folder was the first sharing method we introduced, and since then, we?ve built even better ways for you to share securely and work together with your team. As a result, we?ll soon be ending support for the Public folder. Dropbox Basic users will be able to use the Public folder until March 15, 2017. After that date the files in your Public folder will become private, and links to these files will be deactivated. Your files will remain safe in Dropbox. If you?d like to keep sharing files in your Public folder, you can create new shared links. Just make sure to send the new URLs to your collaborators. In addition to shared links, we have a number of sharing options designed to make collaboration easier and give you more control. To learn more, visit our Help Center. The Dropbox team ? 2016 Dropbox -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Thu Dec 15 12:57:40 2016 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Thu, 15 Dec 2016 17:57:40 +0000 Subject: [Neuroimaging] [DIPY] Fwd: Your Public folder will soon become a private folder In-Reply-To: References: Message-ID: We have space in Nitrc. Wouldn't that be preferable than figshare? On Thu, Dec 15, 2016 at 12:56 PM Ariel Rokem wrote: > This might affect some of our data fetchers: > > https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L255 > https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L279 > https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L322 > https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L338 > https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L379 > https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L390 > > Eleftherios - are these on your Dropbox account? Time to move to Figshare? > > ---------- Forwarded message ---------- > From: *Dropbox* > Date: Thu, Dec 15, 2016 at 9:38 AM > Subject: Your Public folder will soon become a private folder > To: arokem at gmail.com > > > Hi Ariel, > > We?re always looking to improve the Dropbox sharing experience. The Public > folder was the first sharing method we introduced, and since then, we?ve > built even better ways for you to share securely and work together with > your team. > > As a result, we?ll soon be ending support for the Public folder. Dropbox > Basic users will be able to use the Public folder until March 15, 2017. > After that date the files in your Public folder will become private, and > links to these files will be deactivated. Your files will remain safe in > Dropbox. > > If you?d like to keep sharing files in your Public folder, you can create > new shared links. > > Just make sure to send the new URLs to your collaborators. > > In addition to shared links, we have a number of sharing options designed > to make collaboration easier and give you more control. To learn more, visit > our Help Center. > > > The Dropbox team > ? 2016 Dropbox > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Dec 15 19:18:24 2016 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 15 Dec 2016 16:18:24 -0800 Subject: [Neuroimaging] [DIPY] Fwd: Your Public folder will soon become a private folder In-Reply-To: References: Message-ID: On Thu, Dec 15, 2016 at 9:57 AM, Eleftherios Garyfallidis wrote: > We have space in Nitrc. Wouldn't that be preferable than figshare? > > Maybe. Do they provide a DOI? > On Thu, Dec 15, 2016 at 12:56 PM Ariel Rokem wrote: > >> This might affect some of our data fetchers: >> >> https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L255 >> https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L279 >> https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L322 >> https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L338 >> https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L379 >> https://github.com/nipy/dipy/blob/master/dipy/data/fetcher.py#L390 >> >> Eleftherios - are these on your Dropbox account? Time to move to Figshare? >> >> ---------- Forwarded message ---------- >> From: *Dropbox* >> Date: Thu, Dec 15, 2016 at 9:38 AM >> Subject: Your Public folder will soon become a private folder >> To: arokem at gmail.com >> >> >> Hi Ariel, >> >> We?re always looking to improve the Dropbox sharing experience. The >> Public folder was the first sharing method we introduced, and since then, >> we?ve built even better ways for you to share securely and work together >> with your team. >> >> As a result, we?ll soon be ending support for the Public folder. Dropbox >> Basic users will be able to use the Public folder until March 15, 2017. >> After that date the files in your Public folder will become private, and >> links to these files will be deactivated. Your files will remain safe in >> Dropbox. >> >> If you?d like to keep sharing files in your Public folder, you can create >> new shared links. >> >> Just make sure to send the new URLs to your collaborators. >> >> In addition to shared links, we have a number of sharing options designed >> to make collaboration easier and give you more control. To learn more, visit >> our Help Center. >> >> >> The Dropbox team >> ? 2016 Dropbox >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Dec 15 19:19:44 2016 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 15 Dec 2016 16:19:44 -0800 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: On Thu, Dec 15, 2016 at 8:02 AM, Emanuele Olivetti wrote: > Hi Ariel, > > I put the code in a previous message and did not attach it my last > message, on purpose. Now I am attaching it here, for your convenience. > Notice that is the same test.pyx/setup.py you succeeded to compile on your > recent OSX, wihtout OpenMP support. You can just import that module and > invoke test.test_func() to see the output I mentioned: > python -c "import test; test.test_func()" > > Anyway, what I now believe is even more interesting, is to test something > simpler: > https://gist.github.com/romeroyonatan/6a380e189cee4b1290700cbc5259c837 > That is a tiny piece of C code that does basically the same of test.pyx > but without the extra complexity of Cython. I tried it on GNU/Linux > (gcc+libgomp) and it works as expcted. Then I tried it on Paolo's laptop > (OSX 10.11.5) and it fails both with CLang and with Anaconda's > gcc4.8+libgomp (= "conda install gcc"). So this example narrows down the > problem to OpenMP only on OSX - no Python, Cython or else. Could you please > try compile and run it? As indicated there, you just need to: > gcc -fopenmp hello-openmp.c > ./a.out > > Hmm. I can't seem to be able to compile either of these. I think that dipy does some additional magic to check whether you can use openmp or not, around here: https://github.com/nipy/dipy/blob/master/setup.py#L118-L122 > I am very surprised that such a minimal example fails to compile on OSX > with Anaconda's gcc4.8+libgomp. If someone has an explanation of such > issue, I'd really like to know more about it. > > Best, > > Emanuele > > > > On Thu, Dec 15, 2016 at 4:09 PM, Ariel Rokem wrote: > >> Emanule, >> >> On Thu, Dec 15, 2016 at 12:41 AM, Emanuele Olivetti >> wrote: >> >>> Thank you to all of you for the many details that help to clear up the >>> picture. >>> >>> It is my understanding that even the last version of OSX, i.e. v10.12.*, >>> does not support libomp within the Apple's Xcode development framework. At >>> the same time, future version should support it, at some point. Honestly, >>> this does not seem an ideal scenario, because not many OSX users chase the >>> latest versions of the opeating system, while everyone has multiple cores >>> since many years. For the same reason, I doubt that contacting the Xcode >>> side may bring us closer to the solution. >>> To Ariel: if you want to test that OpemMP works, once you build test.so, >>> just import it in the Python console and execute test.test_func(). You >>> should get this: >>> >> >> Was there supposed to be a file attached? >> >> Thanks! >> >> Ariel >> >> >>> --- >>> >>> import test >>> >>> test.test_func() >>> Thread ID: 2 >>> Thread ID: 8 >>> Thread ID: 7 >>> Thread ID: 3 >>> Thread ID: 4 >>> Thread ID: 5 >>> Thread ID: 6 >>> Thread ID: 0 >>> Thread ID: 1 >>> Thread ID: 9 >>> --- >>> If you do not enable the OpenMP support (just comment out the two >>> related lines in setup.py and re-build), the output will differ and only >>> one thread will show up: >>> --- >>> >>> import test >>> >>> test.test_func() >>> Thread ID: 0 >>> --- >>> >>> Anyway, what surprises me most is the failure of Anaconda's gcc+libgomp >>> on OSX. In principle that toolchain is exactly the same as on GNU/Linux, so >>> I see no reason for it fail. I'll try to dig more into this one. >>> >>> To Eleftherios: I agree with you that OpenMP is the best technical >>> solution, because the use of threads - which shares memory - is definitely >>> more preferable than multiprocessing - which replicates data in each >>> process. Anyway, the limitations I see are still there: >>> 1) OpenMP support seems problematic on non-GNU/Linux systems. By the >>> way, what is the situation on Windows? Here we don't have such system so we >>> couldn't try. >>> 2) OpemMP works only with Cython code. This means that no Python part of >>> DiPy can use parallel execution. This seems a bit too excessive to me, >>> because I expect that not all parts of DiPy will be re-written in Cython, >>> in the foreseeable future. >>> >>> So, again, I advocate for some use of the standard multiprocessing >>> module :) as an temporary step when OpenMP cannot be used. >>> >>> Best, >>> >>> Emanuele >>> >>> >>> On Wed, Dec 14, 2016 at 10:04 PM, Stephan Meesters < >>> stephan.meesters at gmail.com> wrote: >>> >>>> Hi, >>>> >>>> The instructions at http://nipy.org/dipy/instal >>>> lation.html#openmp-with-osx are outdated since the clang-omp formula >>>> does not exist anymore. >>>> >>>> With the release of Clang 3.8.0 (08 Mar 2016), OpenMP 3.1 support is >>>> enabled in Clang by default. You will need the -fopenmp=libomp flag while >>>> building. >>>> >>>> I started a while back on a DIPY homebrew formula to allow installation >>>> via "brew install dipy", see https://github.com/Homebrew/ho >>>> mebrew-python/pull/310. However it was based around the deprecated >>>> clang-omp and I didn't get around to fix it. Might look into it soon if I >>>> find some spare time to tweak the formula. >>>> >>>> Regards, >>>> Stephan >>>> >>>> 2016-12-14 17:14 GMT+01:00 Samuel St-Jean : >>>> >>>>> That also depends on which version of clang ships by default with osx, >>>>> in which case you have to play around with it to get a new one. I think it >>>>> starts with clang 3.7 to have openmp support (I only ever tried Mac osx >>>>> 10.9, so anyone more experienced can chime in), but everything older has to >>>>> go through the hombebrew gcc install and company. Might be worhtwhile to >>>>> check if openmp support is out of the box now, and starting on which mac >>>>> osx versions, since older ones could be problematic for first time >>>>> installs. >>>>> >>>>> I also have to admit I have no idea how old is old in the mac world, >>>>> so maybe 10.9 is already phased out by now, but it was a hard and time >>>>> consuming building around stuff with homebrew experience (and again, first >>>>> time I used a mac, so, I guess the average user would also have some >>>>> issues). >>>>> >>>>> Samuel >>>>> >>>>> 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis >>>>> : >>>>> >>>>>> >>>>>> Hi Emanuele, >>>>>> >>>>>> My understanding is that openmp was only temporarily not available >>>>>> when clang replaced gcc in osx. >>>>>> >>>>>> So, I would suggest to go ahead with openmp. Any current installation >>>>>> issues are only temporarily for osx. >>>>>> Openmp gives us a lot of capability to play with shared memory and it >>>>>> is a standard that will be around >>>>>> for very long time. Also, the great integration in cython makes the >>>>>> algorithms really easy to read. >>>>>> So, especially for this project my recommendation is to use openmp >>>>>> rather than multiprocessing. All the way! :) >>>>>> >>>>>> I am CC'ing Stephan who wrote the instructions for osx. I am sure he >>>>>> can help you with this. I would also suggest >>>>>> to check if xcode provides any new guis for enabling openmp. I >>>>>> remember there was something for that. >>>>>> >>>>>> Laterz! >>>>>> Eleftherios >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti >>>>>> wrote: >>>>>> >>>>>>> Hi Eleftherios, >>>>>>> >>>>>>> Thank you for pointing me to the MDF example. From what I see the >>>>>>> Cython syntax is not complex, which is good. >>>>>>> >>>>>>> My only concern is the availability of OpenMP in the systems where >>>>>>> DiPy is used. On a reasonably recent GNU/Linux machine it seems >>>>>>> straightforward to have libgomp and the proper version of gcc. On other >>>>>>> systems - say OSX - the situation is less clear to me. According to what I >>>>>>> read here >>>>>>> http://nipy.org/dipy/installation.html#openmp-with-osx >>>>>>> the OSX installation steps are not meant for standard end users. Are >>>>>>> those instructions updated? >>>>>>> As a test of that, we've just tried to skip the steps described >>>>>>> above and instead to install gcc with conda on OSX ("conda install gcc"). >>>>>>> In the process, conda installed the recent gcc-4.8 with libgomp, which >>>>>>> seems good news. Unfortunately, when we tried to compile a simple example >>>>>>> of Cython code using parallelization (see below), the process failed (fatal >>>>>>> error: limits.h : no such file or directory)... >>>>>>> >>>>>>> For the reasons above, I am wondering whether the very simple >>>>>>> solution of using the "multiprocessing" module, available from the standard >>>>>>> Python library, may be an acceptable first step towards the more efficient >>>>>>> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >>>>>>> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >>>>>>> does not require to have Cython code, because it works on plain Python too. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Emanuele >>>>>>> >>>>>>> ---- test.pyx ---- >>>>>>> from cython import parallel >>>>>>> from libc.stdio cimport printf >>>>>>> >>>>>>> def test_func(): >>>>>>> cdef int thread_id = -1 >>>>>>> with nogil, parallel.parallel(num_threads=10): >>>>>>> thread_id = parallel.threadid() >>>>>>> printf("Thread ID: %d\n", thread_id) >>>>>>> ----- >>>>>>> >>>>>>> ----- setup.py ----- >>>>>>> from distutils.core import setup, Extension >>>>>>> from Cython.Build import cythonize >>>>>>> >>>>>>> extensions = [Extension( >>>>>>> "test", >>>>>>> sources=["test.pyx"], >>>>>>> extra_compile_args=["-fopenmp"], >>>>>>> extra_link_args=["-fopenmp"] >>>>>>> )] >>>>>>> >>>>>>> setup( >>>>>>> ext_modules = cythonize(extensions) >>>>>>> ) >>>>>>> ---- >>>>>>> python setup.py build_ext --inplace >>>>>>> >>>>>>> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >>>>>>> elef at indiana.edu> wrote: >>>>>>> >>>>>>> Hi Emanuele, >>>>>>> >>>>>>> Here is an example of how we calculated the distance matrix in >>>>>>> parallel (for the MDF) using OpenMP >>>>>>> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >>>>>>> >>>>>>> You can just add another function that does the same using mam. It >>>>>>> should be really easy to implement as we have >>>>>>> already done it for the MDF for speeding up SLR. >>>>>>> >>>>>>> Then we need to update the bundle_distances* functions to use the >>>>>>> parallel versions. >>>>>>> >>>>>>> I'll be happy to help you with this. Let's try to schedule some time >>>>>>> to look at this together. >>>>>>> >>>>>>> Best regards, >>>>>>> Eleftherios >>>>>>> >>>>>>> >>>>>>> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I usually compute the distance matrix between two lists of >>>>>>> streamlines using bundle_distances_mam() or bundle_distances_mdf(). When >>>>>>> the lists are large, it is convenient and easy to exploit the multiple >>>>>>> cores of the CPU because such computation is intrinsically (embarassingly) >>>>>>> parallel. At the moment I'm doing it through the multiprocessing or the >>>>>>> joblib modules, because I cannot find a way directly from DiPy, at least >>>>>>> according to what I see in dipy/tracking/distances.pyx . But consider that >>>>>>> I am not proficient in cython.parallel. >>>>>>> >>>>>>> Is there a preferable way to perform such parallel computation? I >>>>>>> plan to prepare a pull request in future and I'd like to be on the right >>>>>>> track. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Emanuele >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Dec 15 21:27:08 2016 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 15 Dec 2016 18:27:08 -0800 Subject: [Neuroimaging] Nitime 0.7 Message-ID: We are happy to announce a new release of Nitime, a library for the analysis of time-series from neuroscience experiments! This release is a maintenance release and also includes a few small bug fixes. We have also transitioned away from testing with nose, in favor of py.test. The following developers contributed to this release: - Ariel Rokem - Eric Larson - Paul Ivanov - Takeshi Abe - Tom Dupr? la Tour - James Franco The full release notes are here: http://nipy.org/nitime/whatsnew/version0.7.html On behalf of the (ni)team, Ariel -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivetti at fbk.eu Fri Dec 16 06:45:38 2016 From: olivetti at fbk.eu (Emanuele Olivetti) Date: Fri, 16 Dec 2016 12:45:38 +0100 Subject: [Neuroimaging] parallel computation of bundle_distances_mam/mdf ? In-Reply-To: References: Message-ID: Ariel, thank you for trying it out. About the C code, on Paolo's macbook, there was an unexpected behavior when issuing "gcc" from the terminal. At least unexpected to me. Even when the PATH environmental variable pointed to the miniconda/bin directory as first thing - so "which gcc" returned miniconda gcc - the compilation was done with clang (!). Apparently, "gcc" was set as alias for clang. You might incur in the same issue. Best, Emanuele On Fri, Dec 16, 2016 at 1:19 AM, Ariel Rokem wrote: > > > On Thu, Dec 15, 2016 at 8:02 AM, Emanuele Olivetti > wrote: > >> Hi Ariel, >> >> I put the code in a previous message and did not attach it my last >> message, on purpose. Now I am attaching it here, for your convenience. >> Notice that is the same test.pyx/setup.py you succeeded to compile on your >> recent OSX, wihtout OpenMP support. You can just import that module and >> invoke test.test_func() to see the output I mentioned: >> python -c "import test; test.test_func()" >> >> Anyway, what I now believe is even more interesting, is to test something >> simpler: >> https://gist.github.com/romeroyonatan/6a380e189cee4b1290700cbc5259c837 >> That is a tiny piece of C code that does basically the same of test.pyx >> but without the extra complexity of Cython. I tried it on GNU/Linux >> (gcc+libgomp) and it works as expcted. Then I tried it on Paolo's laptop >> (OSX 10.11.5) and it fails both with CLang and with Anaconda's >> gcc4.8+libgomp (= "conda install gcc"). So this example narrows down the >> problem to OpenMP only on OSX - no Python, Cython or else. Could you please >> try compile and run it? As indicated there, you just need to: >> gcc -fopenmp hello-openmp.c >> ./a.out >> >> > Hmm. I can't seem to be able to compile either of these. I think that dipy > does some additional magic to check whether you can use openmp or not, > around here: > > https://github.com/nipy/dipy/blob/master/setup.py#L118-L122 > > > >> I am very surprised that such a minimal example fails to compile on OSX >> with Anaconda's gcc4.8+libgomp. If someone has an explanation of such >> issue, I'd really like to know more about it. >> >> Best, >> >> Emanuele >> >> >> >> On Thu, Dec 15, 2016 at 4:09 PM, Ariel Rokem wrote: >> >>> Emanule, >>> >>> On Thu, Dec 15, 2016 at 12:41 AM, Emanuele Olivetti >>> wrote: >>> >>>> Thank you to all of you for the many details that help to clear up the >>>> picture. >>>> >>>> It is my understanding that even the last version of OSX, i.e. >>>> v10.12.*, does not support libomp within the Apple's Xcode development >>>> framework. At the same time, future version should support it, at some >>>> point. Honestly, this does not seem an ideal scenario, because not many OSX >>>> users chase the latest versions of the opeating system, while everyone has >>>> multiple cores since many years. For the same reason, I doubt that >>>> contacting the Xcode side may bring us closer to the solution. >>>> To Ariel: if you want to test that OpemMP works, once you build >>>> test.so, just import it in the Python console and execute test.test_func(). >>>> You should get this: >>>> >>> >>> Was there supposed to be a file attached? >>> >>> Thanks! >>> >>> Ariel >>> >>> >>>> --- >>>> >>> import test >>>> >>> test.test_func() >>>> Thread ID: 2 >>>> Thread ID: 8 >>>> Thread ID: 7 >>>> Thread ID: 3 >>>> Thread ID: 4 >>>> Thread ID: 5 >>>> Thread ID: 6 >>>> Thread ID: 0 >>>> Thread ID: 1 >>>> Thread ID: 9 >>>> --- >>>> If you do not enable the OpenMP support (just comment out the two >>>> related lines in setup.py and re-build), the output will differ and only >>>> one thread will show up: >>>> --- >>>> >>> import test >>>> >>> test.test_func() >>>> Thread ID: 0 >>>> --- >>>> >>>> Anyway, what surprises me most is the failure of Anaconda's gcc+libgomp >>>> on OSX. In principle that toolchain is exactly the same as on GNU/Linux, so >>>> I see no reason for it fail. I'll try to dig more into this one. >>>> >>>> To Eleftherios: I agree with you that OpenMP is the best technical >>>> solution, because the use of threads - which shares memory - is definitely >>>> more preferable than multiprocessing - which replicates data in each >>>> process. Anyway, the limitations I see are still there: >>>> 1) OpenMP support seems problematic on non-GNU/Linux systems. By the >>>> way, what is the situation on Windows? Here we don't have such system so we >>>> couldn't try. >>>> 2) OpemMP works only with Cython code. This means that no Python part >>>> of DiPy can use parallel execution. This seems a bit too excessive to me, >>>> because I expect that not all parts of DiPy will be re-written in Cython, >>>> in the foreseeable future. >>>> >>>> So, again, I advocate for some use of the standard multiprocessing >>>> module :) as an temporary step when OpenMP cannot be used. >>>> >>>> Best, >>>> >>>> Emanuele >>>> >>>> >>>> On Wed, Dec 14, 2016 at 10:04 PM, Stephan Meesters < >>>> stephan.meesters at gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> The instructions at http://nipy.org/dipy/instal >>>>> lation.html#openmp-with-osx are outdated since the clang-omp formula >>>>> does not exist anymore. >>>>> >>>>> With the release of Clang 3.8.0 (08 Mar 2016), OpenMP 3.1 support is >>>>> enabled in Clang by default. You will need the -fopenmp=libomp flag while >>>>> building. >>>>> >>>>> I started a while back on a DIPY homebrew formula to allow >>>>> installation via "brew install dipy", see >>>>> https://github.com/Homebrew/homebrew-python/pull/310. However it was >>>>> based around the deprecated clang-omp and I didn't get around to fix it. >>>>> Might look into it soon if I find some spare time to tweak the formula. >>>>> >>>>> Regards, >>>>> Stephan >>>>> >>>>> 2016-12-14 17:14 GMT+01:00 Samuel St-Jean : >>>>> >>>>>> That also depends on which version of clang ships by default with >>>>>> osx, in which case you have to play around with it to get a new one. I >>>>>> think it starts with clang 3.7 to have openmp support (I only ever tried >>>>>> Mac osx 10.9, so anyone more experienced can chime in), but everything >>>>>> older has to go through the hombebrew gcc install and company. Might be >>>>>> worhtwhile to check if openmp support is out of the box now, and starting >>>>>> on which mac osx versions, since older ones could be problematic for first >>>>>> time installs. >>>>>> >>>>>> I also have to admit I have no idea how old is old in the mac world, >>>>>> so maybe 10.9 is already phased out by now, but it was a hard and time >>>>>> consuming building around stuff with homebrew experience (and again, first >>>>>> time I used a mac, so, I guess the average user would also have some >>>>>> issues). >>>>>> >>>>>> Samuel >>>>>> >>>>>> 2016-12-14 16:51 GMT+01:00 Eleftherios Garyfallidis >>>>> >: >>>>>> >>>>>>> >>>>>>> Hi Emanuele, >>>>>>> >>>>>>> My understanding is that openmp was only temporarily not available >>>>>>> when clang replaced gcc in osx. >>>>>>> >>>>>>> So, I would suggest to go ahead with openmp. Any current >>>>>>> installation issues are only temporarily for osx. >>>>>>> Openmp gives us a lot of capability to play with shared memory and >>>>>>> it is a standard that will be around >>>>>>> for very long time. Also, the great integration in cython makes the >>>>>>> algorithms really easy to read. >>>>>>> So, especially for this project my recommendation is to use openmp >>>>>>> rather than multiprocessing. All the way! :) >>>>>>> >>>>>>> I am CC'ing Stephan who wrote the instructions for osx. I am sure he >>>>>>> can help you with this. I would also suggest >>>>>>> to check if xcode provides any new guis for enabling openmp. I >>>>>>> remember there was something for that. >>>>>>> >>>>>>> Laterz! >>>>>>> Eleftherios >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Dec 14, 2016 at 6:29 AM Emanuele Olivetti >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Eleftherios, >>>>>>>> >>>>>>>> Thank you for pointing me to the MDF example. From what I see the >>>>>>>> Cython syntax is not complex, which is good. >>>>>>>> >>>>>>>> My only concern is the availability of OpenMP in the systems where >>>>>>>> DiPy is used. On a reasonably recent GNU/Linux machine it seems >>>>>>>> straightforward to have libgomp and the proper version of gcc. On other >>>>>>>> systems - say OSX - the situation is less clear to me. According to what I >>>>>>>> read here >>>>>>>> http://nipy.org/dipy/installation.html#openmp-with-osx >>>>>>>> the OSX installation steps are not meant for standard end users. >>>>>>>> Are those instructions updated? >>>>>>>> As a test of that, we've just tried to skip the steps described >>>>>>>> above and instead to install gcc with conda on OSX ("conda install gcc"). >>>>>>>> In the process, conda installed the recent gcc-4.8 with libgomp, which >>>>>>>> seems good news. Unfortunately, when we tried to compile a simple example >>>>>>>> of Cython code using parallelization (see below), the process failed (fatal >>>>>>>> error: limits.h : no such file or directory)... >>>>>>>> >>>>>>>> For the reasons above, I am wondering whether the very simple >>>>>>>> solution of using the "multiprocessing" module, available from the standard >>>>>>>> Python library, may be an acceptable first step towards the more efficient >>>>>>>> multithreading of Cython/libgomp. With "multiprocessing", there is no extra >>>>>>>> dependency on libgomp, or recent gcc or else. Moreover, multiprocessing >>>>>>>> does not require to have Cython code, because it works on plain Python too. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Emanuele >>>>>>>> >>>>>>>> ---- test.pyx ---- >>>>>>>> from cython import parallel >>>>>>>> from libc.stdio cimport printf >>>>>>>> >>>>>>>> def test_func(): >>>>>>>> cdef int thread_id = -1 >>>>>>>> with nogil, parallel.parallel(num_threads=10): >>>>>>>> thread_id = parallel.threadid() >>>>>>>> printf("Thread ID: %d\n", thread_id) >>>>>>>> ----- >>>>>>>> >>>>>>>> ----- setup.py ----- >>>>>>>> from distutils.core import setup, Extension >>>>>>>> from Cython.Build import cythonize >>>>>>>> >>>>>>>> extensions = [Extension( >>>>>>>> "test", >>>>>>>> sources=["test.pyx"], >>>>>>>> extra_compile_args=["-fopenmp"], >>>>>>>> extra_link_args=["-fopenmp"] >>>>>>>> )] >>>>>>>> >>>>>>>> setup( >>>>>>>> ext_modules = cythonize(extensions) >>>>>>>> ) >>>>>>>> ---- >>>>>>>> python setup.py build_ext --inplace >>>>>>>> >>>>>>>> On Tue, Dec 13, 2016 at 11:17 PM, Eleftherios Garyfallidis < >>>>>>>> elef at indiana.edu> wrote: >>>>>>>> >>>>>>>> Hi Emanuele, >>>>>>>> >>>>>>>> Here is an example of how we calculated the distance matrix in >>>>>>>> parallel (for the MDF) using OpenMP >>>>>>>> https://github.com/nipy/dipy/blob/master/dipy/align/bundlemin.pyx >>>>>>>> >>>>>>>> You can just add another function that does the same using mam. It >>>>>>>> should be really easy to implement as we have >>>>>>>> already done it for the MDF for speeding up SLR. >>>>>>>> >>>>>>>> Then we need to update the bundle_distances* functions to use the >>>>>>>> parallel versions. >>>>>>>> >>>>>>>> I'll be happy to help you with this. Let's try to schedule some >>>>>>>> time to look at this together. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Eleftherios >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Dec 12, 2016 at 11:16 AM Emanuele Olivetti >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I usually compute the distance matrix between two lists of >>>>>>>> streamlines using bundle_distances_mam() or bundle_distances_mdf(). When >>>>>>>> the lists are large, it is convenient and easy to exploit the multiple >>>>>>>> cores of the CPU because such computation is intrinsically (embarassingly) >>>>>>>> parallel. At the moment I'm doing it through the multiprocessing or the >>>>>>>> joblib modules, because I cannot find a way directly from DiPy, at least >>>>>>>> according to what I see in dipy/tracking/distances.pyx . But consider that >>>>>>>> I am not proficient in cython.parallel. >>>>>>>> >>>>>>>> Is there a preferable way to perform such parallel computation? I >>>>>>>> plan to prepare a pull request in future and I'd like to be on the right >>>>>>>> track. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Emanuele >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Haselgrove at umassmed.edu Fri Dec 16 11:13:28 2016 From: Christian.Haselgrove at umassmed.edu (Haselgrove, Christian) Date: Fri, 16 Dec 2016 16:13:28 +0000 Subject: [Neuroimaging] [DIPY] Fwd: Your Public folder will soon become a private folder In-Reply-To: References: Message-ID: <67A3E6B7-A889-401A-A0A3-A4D9C6F46D83@umassmed.edu> > On Thu, Dec 15, 2016 at 9:57 AM, Eleftherios Garyfallidis wrote: > We have space in Nitrc. Wouldn't that be preferable than figshare? > > > Maybe. Do they provide a DOI? Not at the moment, but it's something we're looking into. It might be a good pilot for us, in fact -- if you want to contact me off-list, we can hash out the details. c -- Christian Haselgrove christian.haselgrove at umassmed.edu 774-455-4109 From fperez.net at gmail.com Fri Dec 16 14:48:27 2016 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 16 Dec 2016 11:48:27 -0800 Subject: [Neuroimaging] Nitime 0.7 In-Reply-To: References: Message-ID: Congrats, Ariel and team!! I've not contributed a line of code to nitime in ages, but I'm very happy to see it continue to grow :) Cheers, f On Thu, Dec 15, 2016 at 6:27 PM, Ariel Rokem wrote: > We are happy to announce a new release of Nitime, a library for the > analysis of time-series from neuroscience experiments! > > This release is a maintenance release and also includes a few small bug > fixes. We have also transitioned away from testing with nose, in favor of > py.test. > > The following developers contributed to this release: > > - Ariel Rokem > - Eric Larson > - Paul Ivanov > - Takeshi Abe > - Tom Dupr? la Tour > - James Franco > > The full release notes are here: http://nipy.org/nitime/ > whatsnew/version0.7.html > > On behalf of the (ni)team, > > Ariel > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -------------- next part -------------- An HTML attachment was scrubbed... URL: From 18758264356 at 163.com Tue Dec 27 04:17:32 2016 From: 18758264356 at 163.com (Judd) Date: Tue, 27 Dec 2016 17:17:32 +0800 (CST) Subject: [Neuroimaging] Help: A problem with affine in Dipy Message-ID: <21b42440.cc5c.1593f920b3a.Coremail.18758264356@163.com> Hello: My name is Judd, And I'm from China(Maybe English isn't well, sorry!). Recently, I was try an example in Dipy Gallery(Connectivity Matrices, ROI Intersections and Density Maps http://nipy.org/dipy/examples_built/streamline_tools.html#example-streamline-tools). And my test file is my own fiber and FA file which save by nibabel like this: nib.trackvis.write(csd_sl_fname, csd_streamlines_trk, hdr, points_space='voxel') nib.save(FA_img, FA_file) but when I use these file, it doesn't work, and I realized FA file and fiber file isn't in the same position. So I think it may be some trouble in affine, but I don't know How to change position by affine(I use dipy code change by affine, but still wrong). Did you have a formula or paper about affine? Thanks!! Judd 2016.12.27 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 18758264356 at 163.com Fri Dec 30 08:29:40 2016 From: 18758264356 at 163.com (Judd) Date: Fri, 30 Dec 2016 21:29:40 +0800 (CST) Subject: [Neuroimaging] Help: A problem with affine in Dipy Message-ID: <5fb3b8ee.dd0a.1594febf44c.Coremail.18758264356@163.com> Hello: My name is Judd, And I'm from China(Maybe English isn't well, sorry!). Recently, I was try an example in Dipy Gallery(Connectivity Matrices, ROI Intersections and Density Maps http://nipy.org/dipy/examples_built/streamline_tools.html#example-streamline-tools). And my test file is my own fiber and FA file which save by nibabel like this: nib.trackvis.write(csd_sl_fname, csd_streamlines_trk, hdr, points_space='voxel') nib.save(FA_img, FA_file) but when I use these file, it doesn't work, and I realized FA file and fiber file isn't in the same position. So I think it may be some trouble in affine, but I don't know How to change position by affine(I use dipy code change by affine, but still wrong). Did you have a formula or paper about affine? Thanks!! Judd 2016.12.27 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrbago at gmail.com Fri Dec 30 19:58:23 2016 From: mrbago at gmail.com (Bago) Date: Sat, 31 Dec 2016 00:58:23 +0000 Subject: [Neuroimaging] Help: A problem with affine in Dipy In-Reply-To: <5fb3b8ee.dd0a.1594febf44c.Coremail.18758264356@163.com> References: <5fb3b8ee.dd0a.1594febf44c.Coremail.18758264356@163.com> Message-ID: Hi Judd, Could you clarify what "it doesn't work" means? "Trackvis", the visualization software, expects the streamlines to be in a specific "point space" in order to visualize correctly. If you're having trouble viewing your points co-aligned with your FA file, it's because the points are being saved in the wrong point space. Take a look at the end of the example, http://nipy.org/dipy/examples_built/streamline_tools.html#example-streamline-tools, and try saving the streamlines using the same method. (Make sure you build the trackvis header and use "move_streamlines"). If you've done that and the streamlines are displaying correctly in Trackvis but you're still having trouble using the utils module, then look for the function `dipy.tracking.utils.affine_for_trackvis`. That function should return the correct affine for the "trackvis point space". Alternatively you can try out the new steamline API in nibabel.streamlines, http://nipy.org/nibabel/reference/nibabel.streamlines.html#nibabel.streamlines.load. This API should make it easier to load trk files into NIFTI RAS+ point space so that your image and streamlines share a real world coordinate system. Hope that helps, Bago On Fri, Dec 30, 2016 at 1:18 PM Judd <18758264356 at 163.com> wrote: > Hello: > My name is Judd, And I'm from China(Maybe English isn't well, sorry!). > Recently, I was try an example in Dipy Gallery(Connectivity Matrices, ROI > Intersections and Density Maps > http://nipy.org/dipy/examples_built/streamline_tools.html#example-streamline-tools > ). And my test file is my own fiber and FA file which save by nibabel > like this: > *nib.trackvis.write(csd_sl_fname, csd_streamlines_trk, hdr, > points_space='voxel')* > *nib.save(FA_img, FA_file)* > > but when I use these file, it doesn't work, and I realized FA file and > fiber file isn't in the same position. So I think it may be some trouble in > *affine, *but I don't know How to change position by affine(I use dipy > code change by affine, but still wrong). Did you have a formula or paper > about affine? > > > > Thanks!! > > > Judd > > > 2016.12.27 > > > > > > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: