Dear list,
Since I changed to the the develop version (0.14.dev0), I've been seeing a
warning message whenever I try to do the co-registration using
mne.gui.coregistration:
Dear list,
Since I changed to the the develop version (0.14.dev0), I've been seeing a
warning message whenever I try to do the co-registration using
mne.gui.coregistration:
hi,
your version of mne_surf2bem is too old.
please try to install the latest version of mne C. Take the nightly build.
The --force option was introduced much later than 2009.
now I think we should fix this as mne_surf2bem should not be necessary
for this operation.
I opened an issue on github
https://github.com/mne-tools/mne-python/issues/3709
HTH
Alex
Thank you for the feedback.
I admit that the download page for the MNE-C is a bit confusing.
On the top there is the old version 2.7.0, followed by the nightly-build
2.7.4, followed by the last stable version 2.7.3.
I tried the 2.7.3, which I guess is the last stable version (from 2011),
and got the same error.
I installed the nightly-build (2016), and now it is working, although I'm
not very comfortable running nightly-builds in production...
Also, it complained about a missing library: libgfortran.so.1
*mne_surf2bem: error while loading shared libraries: libgfortran.so.1:
cannot open shared object file: No such file or directory*
Which is weird, since it is an old lib, and I have libgfortran.so.3
installed, and the previous MNE versions seemed to do just fine.
I added an old libgfortran.so.1 available in the anaconda repository, but
since I added the whole folder to the ld.so.conf, I'm getting some weird
warnings...
I think I'm going back to MNE-2.7.3-3268-Linux-x86_64 after I finish
generating the surfaces, and remove libgfortran.so.1 from the path
Is there a stable version of 2.7.4 ?
Thank you,
Leonardo
2016-10-28 14:29 GMT-05:00 Alexandre Gramfort <
alexandre.gramfort at telecom-paristech.fr>:
hi,
your version of mne_surf2bem is too old.
please try to install the latest version of mne C. Take the nightly build.
The --force option was introduced much later than 2009.now I think we should fix this as mne_surf2bem should not be necessary
for this operation.I opened an issue on github
avoid use of mne_surf2bem · Issue #3709 · mne-tools/mne-python · GitHub
HTH
Alex> Dear list,
>
> Since I changed to the the develop version (0.14.dev0), I've been seeing
a
> warning message whenever I try to do the co-registration using
> mne.gui.coregistration:
>
> ------
>
> No high resolution head model was found for subject USER_2005_T1, using
> standard head instead. In order to generate a high resolution head model,
> run:
>
>
> $ mne make_scalp_surfaces -s USER_2005_T1
>
>
> ------
>
> https://drive.google.com/open?id=0B0p7WZ2wlTFSTjZQSGNMOHpCTGc
>
> So far, following the Head Model tutorial, I've been using
>
> mne watershed_bem -s USER
> (output: https://drive.google.com/open?id=0B0p7WZ2wlTFSODIzekhIQ2tuNnM)
>
> which generates the head surface .fif file in :
>
> bem/USER_2005_T1-head.fif (together with some other surface files)
>
> and did not have any further problems.
>
> Following the warning, I tried to run the
>
> mne make_scalp_surfaces -s USER_2005_T1
>
> and even though the high-resolution was created in
>
> bem/NCCAM_2005_T1-head-dense.fif (together with the surf/*seghead*
files)
>
> I got the following error in the part that generates the medium
tessellation
> (output here :
> https://drive.google.com/open?id=0B0p7WZ2wlTFSZHp0VVpBUWxNbXc).
>
> Therefore my question is: can I safely ignore the warning and use the
lower
> resolution bem generated by the watershed algorithm?
> What would be the advantages of using the high-resolution version?
>
> One clear advantage for me it to use the high resolution when possible to
> mark the fiducials, but I figure that for the actual forward model a
lower
> resolution must be used otherwise it would take long to compute all
> electrical distances, no?
>
> Of note:
>
> * The same error occurs when I use the version 0.13-dev and 0.13 stable.
> * I'm using
>
> mne_surf2bem version 1.6 compiled at Dec 21 2009 19:47:09
>
> * I noticed that mne_surf2bem complains about a --force option, which
> apparently do not exist.
> If I try to remove the offending argument, I get a different error
(output
> here: https://drive.google.com/open?id=0B0p7WZ2wlTFSbHdTWkpub2N2T3c)
>
> Any help is appreciated!
>
> Thank you,
> Leonardo Barbosa
>
> _______________________________________________
> Mne_analysis mailing list
> Mne_analysis at nmr.mgh.harvard.edu
> Mne_analysis Info Page
>
>
> 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
> contains patient information, please contact the Partners Compliance
> HelpLine at
> MyComplianceReport.com: Compliance and Ethics Reporting . 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.
>
_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20161029/e9d7b550/attachment.html
Hi Leonardo,
Rather than installing libgfortran.so.1 you can also create a symbolic
link to the libgfortran.so.3 file that has worked for me in past.
If your are on a ubuntu based system the command is (from memory):
ln -s /usr/lib/x86_64-linux-gnu/libgfortran.so.3
/usr/lib/x86_64-linux-gnu/libgfortran.so.
- mads
hi,
Also, it complained about a missing library: libgfortran.so.1
yes we know
you can use mads trick
here is also the lib you may need on linux:
https://dl.dropboxusercontent.com/u/2140486/libgfortran.so.1.i686.zip
https://dl.dropboxusercontent.com/u/2140486/libgfortran.so.1.x86_64.zip
don't trouble yourself about using a nightly version the MNE-C code. It
is a very stable. The code changes are much less frequent than with mne-python.
Sorry for all this hassle.
Best,
Alex
Cool, the symbolic link did the trick (thanks mads!).
I'm able to run "mne make_scalp_surfaces" without further issues.
Also the co-registration looks good.
Thank you for all the feedback!,
Leonardo
2016-10-30 3:51 GMT-05:00 Alexandre Gramfort <
alexandre.gramfort at telecom-paristech.fr>:
hi,
> Also, it complained about a missing library: libgfortran.so.1
yes we know
you can use mads trick
here is also the lib you may need on linux:
https://dl.dropboxusercontent.com/u/2140486/libgfortran.so.1.i686.zip
https://dl.dropboxusercontent.com/u/2140486/libgfortran.so.1.x86_64.zipdon't trouble yourself about using a nightly version the MNE-C code. It
is a very stable. The code changes are much less frequent than with
mne-python.Sorry for all this hassle.
Best,
Alex> mne_surf2bem: error while loading shared libraries: libgfortran.so.1:
cannot
> open shared object file: No such file or directory
>
> Which is weird, since it is an old lib, and I have libgfortran.so.3
> installed, and the previous MNE versions seemed to do just fine.
> I added an old libgfortran.so.1 available in the anaconda repository,
but
> since I added the whole folder to the ld.so.conf, I'm getting some weird
> warnings...
> I think I'm going back to MNE-2.7.3-3268-Linux-x86_64 after I finish
> generating the surfaces, and remove libgfortran.so.1 from the path
>
> Is there a stable version of 2.7.4 ?
>
> Thank you,
> Leonardo
>
>
> 2016-10-28 14:29 GMT-05:00 Alexandre Gramfort
> <alexandre.gramfort at telecom-paristech.fr>:
>>
>> hi,
>>
>> your version of mne_surf2bem is too old.
>>
>> please try to install the latest version of mne C. Take the nightly
build.
>> The --force option was introduced much later than 2009.
>>
>> now I think we should fix this as mne_surf2bem should not be necessary
>> for this operation.
>>
>> I opened an issue on github
>>
>> avoid use of mne_surf2bem · Issue #3709 · mne-tools/mne-python · GitHub
>>
>> HTH
>> Alex
>>
>>
>> > Dear list,
>> >
>> > Since I changed to the the develop version (0.14.dev0), I've been
seeing
>> > a
>> > warning message whenever I try to do the co-registration using
>> > mne.gui.coregistration:
>> >
>> > ------
>> >
>> > No high resolution head model was found for subject USER_2005_T1,
using
>> > standard head instead. In order to generate a high resolution head
>> > model,
>> > run:
>> >
>> >
>> > $ mne make_scalp_surfaces -s USER_2005_T1
>> >
>> >
>> > ------
>> >
>> > https://drive.google.com/open?id=0B0p7WZ2wlTFSTjZQSGNMOHpCTGc
>> >
>> > So far, following the Head Model tutorial, I've been using
>> >
>> > mne watershed_bem -s USER
>> > (output: https://drive.google.com/open?id=
0B0p7WZ2wlTFSODIzekhIQ2tuNnM)
>> >
>> > which generates the head surface .fif file in :
>> >
>> > bem/USER_2005_T1-head.fif (together with some other surface files)
>> >
>> > and did not have any further problems.
>> >
>> > Following the warning, I tried to run the
>> >
>> > mne make_scalp_surfaces -s USER_2005_T1
>> >
>> > and even though the high-resolution was created in
>> >
>> > bem/NCCAM_2005_T1-head-dense.fif (together with the surf/*seghead*
>> > files)
>> >
>> > I got the following error in the part that generates the medium
>> > tessellation
>> > (output here :
>> > https://drive.google.com/open?id=0B0p7WZ2wlTFSZHp0VVpBUWxNbXc).
>> >
>> > Therefore my question is: can I safely ignore the warning and use the
>> > lower
>> > resolution bem generated by the watershed algorithm?
>> > What would be the advantages of using the high-resolution version?
>> >
>> > One clear advantage for me it to use the high resolution when possible
>> > to
>> > mark the fiducials, but I figure that for the actual forward model a
>> > lower
>> > resolution must be used otherwise it would take long to compute all
>> > electrical distances, no?
>> >
>> > Of note:
>> >
>> > * The same error occurs when I use the version 0.13-dev and 0.13
stable.
>> > * I'm using
>> >
>> > mne_surf2bem version 1.6 compiled at Dec 21 2009 19:47:09
>> >
>> > * I noticed that mne_surf2bem complains about a --force option, which
>> > apparently do not exist.
>> > If I try to remove the offending argument, I get a different error
>> > (output
>> > here: https://drive.google.com/open?id=0B0p7WZ2wlTFSbHdTWkpub2N2T3c)
>> >
>> > Any help is appreciated!
>> >
>> > Thank you,
>> > Leonardo Barbosa
>> >
>> > _______________________________________________
>> > Mne_analysis mailing list
>> > Mne_analysis at nmr.mgh.harvard.edu
>> > Mne_analysis Info Page
>> >
>> >
>> > 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
>> > contains patient information, please contact the Partners Compliance
>> > HelpLine at
>> > MyComplianceReport.com: Compliance and Ethics Reporting . 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.
>> >
>> _______________________________________________
>> Mne_analysis mailing list
>> Mne_analysis at nmr.mgh.harvard.edu
>> Mne_analysis Info Page
>
>
>
> _______________________________________________
> Mne_analysis mailing list
> Mne_analysis at nmr.mgh.harvard.edu
> Mne_analysis Info Page
>
>
> 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
> contains patient information, please contact the Partners Compliance
> HelpLine at
> MyComplianceReport.com: Compliance and Ethics Reporting . 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.
>
_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20161031/fe318d68/attachment.html