BV - matlab7 on red hat : Unable to get matrix from Matlab..

as_dub · Post by **as_dub** » Tue Mar 14, 2006 11:17 pm

Hello !

I have problem running Matlab 7 from BV.
I work on Linux (Red Hat Enterprise Linux 3). The validation works well (no problem with matlab.validation()) , but the matlab.matlab() command doesn't work.... it raise the error
"RuntimeError: Unable to get matrix from MATLAB workspace"
Any idea of what is happening ? Has anyone tested BV - matlab7 communication on red hat ? Thank you !

Anne-Sophie

as_dub · Post by **as_dub** » Tue Mar 14, 2006 11:32 pm

a little more information in case it helps :

if I launch manually Matlab (while BV is running)
I can run
MatRun = matlab.matlab()
MatRun.put("value", self.value )
BUT
MatRun.eval( 'b = eye(2) * [2 0; 0 3]') doesn't work...

as_dub · Post by **as_dub** » Fri Mar 17, 2006 4:33 pm

Hello !

in case it helps (again !)

my test script (below) works well with Matlab 7 on Windows (exactly the same Matlab version that I use on Linux)

MatRun = matlab.matlab()
MatRun.put("value", self.value )
MatRun.eval( 'b = eye(2) * [2 0; 0 3]')

The problem may come from communication between BV and Red Hat Linux..

I started thinking about getting the 6.5 Matlab version to be able to test some data.
Does anybody know if I can get a 6.5 Matlab version from the Matlab 7 licence, or should I pay for this ?
In case I can get the 6.5 version, can I install it on the same workstation with Matlab 7 so both versions will work ? (so I could configure BV to work with 6.5 for now)

Has anybody done this before ? or does anybody have any knowledge on the issue... Any information would be very useful for me !

Thank you !

Anne-Sophie

Post by **riviere** » Mon Mar 20, 2006 11:29 pm

Hi,

Since version 3.0.1 of our packages, multiple matlab versions should be supported: we have compiled pymat modules for both matlab 6.5 and 7. But as Matlab engine libraries are compiled with an antique compiler and obsolete libraries, there may still be some compatibility problems that we have not noticed (and that we even might not be able to solve).
Have you checked Matlab executable and version are OK in BrainVisa config ? The version should be detected (by running matlab once) if it is not set, but can be forced in the config (matlabRelease option). If it is not correctly set or guessed, BV may switch to the wrong pymat module, which would explain your problem. So try forcing matlabRelease to 14 (for matlab 7).

Matlab 6.5 and 7.x can coexist on the same system: you just have to install them in a different place. But I would not guess it it possible with the same licence (?).

Denis

as_dub · Post by **as_dub** » Tue Mar 21, 2006 12:44 am

Unfortunaltly it doesn't work... I wrote 14 in the MatlabRelease field, and started again BV, but it still not work...

Should I do something else (than start again BV) ? Thank you.
Anne-Sophie

denghien · Post by **denghien** » Thu Mar 23, 2006 10:00 am

Hi,

I think you can get an old version of matlab from your licence and Mathworks.

Isa

as_dub · Post by **as_dub** » Thu Mar 23, 2006 3:39 pm

Yes !
I talked with the Mathworks technical support. They told me that it is possible to install both 6.5 and 7 versions on a Linux workstation, and gave me instructions to do this (and also a link to download Matlab 6.5, which I think is available for Matlab 7 owners). If anybody wants to have the step-by-step instructions' email that I received from Mathworks feel free to ask me !

Now, BV communicates with Matlab 6.5 and works well !

Anyway, thank you Isa for answering me !

AnneSo

Post by **riviere** » Fri Mar 24, 2006 12:08 pm

Now the question is: why doesn't Matlab7 work ? It seems to work for us (on Fedora 2 and Fedora 4 distribs).
I remember some library compatibility problems went away when we renamed (or moved away) <matlab7_path>/sys/os/glnx86/libgcc_s.so.1 to allow using the system libgcc_s.so.1 (or the one from our binary package) because the one provided with matlab is anterior to dinosaurs, but I'm not sure it is the key of the problem here: I think it was mainly to compile mex files using C++ (it caused some glibc symbol version issues).
Denis

as_dub · Post by **as_dub** » Fri Mar 24, 2006 10:49 pm

I believed that the problem came from Matlab (something which would have changed between 6.5 and 7 versions). So in case it helps I give your a link that Mathworks sent me, it is about changes between Matlab versions.

http://www.mathworks.com/access/helpdes ... rn/rn.html

In case it helps..

Good luck Denis !

pifou · Post by **pifou** » Wed Jun 07, 2006 11:37 am

hello,

i have the same problem!!!

I return to matlab 6.1 !!!

Good luck!!

sg

Post by **riviere** » Wed Jun 07, 2006 2:19 pm

Hi,

Well, yes I think I know what is wrong, I had completely forgotten about it: it's simply that in the package 3.0.1 we have put matlab engine libraries, but even if we have built both pymat modules for matlab 6 and 7, we could ship only one version of the matlab engine libraries because they have exactly the same filename in matlab 6 and 7.
So to fix it, you have to:

- provide matlab libraries path in the libraries path (LD_LIBRARY_PATH variable on linux systems), generally <matlab6path>/extern/lib/glnx86 or <matlab7path>/bin/glnx86 (note the different location for matlab 6 and 7)
- remove the matlab libs in the pack, in <SHFJ_pack>/lib, remove:
libmat.so, libmx.so, libut.so, libeng.so

These libs were shipped with the pack 3.0.1 so it could work out of the box with matlab 6, but interfere with matlab 7. We don't provide them anymore in the 3.0.2 package.

Denis