Hi Arnold,
Are you compiling for MATLAB or Octave? The issue observed by Melanni
was with Octave. Here you are compiling with mex from the terminal, so
it is aiming at compiling for MATLAB (*.mexa64).
Also, which version of Ubuntu are you using?
Best regards,
Guillaume.
On 31/10/2018 19:59, Arnold Evia wrote:
> Compiling the file using terminal didn't make a difference.
> Still observe the same behavior.
>
> I tried compiling without the platform tags, and got the following result:
>
> rm -f file2mat.mexa64 mat2file.mexa64 init.mexa64
> mex -O -largeArrayDims file2mat.c
> Building with 'gcc'.
> Warning: You are using gcc version '5.5.0'. The version of gcc is not
> supported. The version currently supported with MEX is '6.3.x'. For a
> list of currently supported compilers see:
> https://www.mathworks.com/support/compilers/current_release.
> MEX completed successfully.
> mex -O -largeArrayDims mat2file.c
> Building with 'gcc'.
> Warning: You are using gcc version '5.5.0'. The version of gcc is not
> supported. The version currently supported with MEX is '6.3.x'. For a
> list of currently supported compilers see:
> https://www.mathworks.com/support/compilers/current_release.
> MEX completed successfully.
> mex -O -largeArrayDims init.c
> Building with 'gcc'.
> Warning: You are using gcc version '5.5.0'. The version of gcc is not
> supported. The version currently supported with MEX is '6.3.x'. For a
> list of currently supported compilers see:
> https://www.mathworks.com/support/compilers/current_release.
> MEX completed successfully.
>
> Is mkoctfile dependent on the version of gcc?
> If so, then I will try again after updating gcc.
>
> Arnold M. Evia, Ph.D.
> Senior Research Associate
> Department of Biomedical Engineering
> Medical Imaging Research Center
> Illinois Institute of Technology
> http://www.iit.edu/~mri/
>
>
> On Wed, Oct 31, 2018 at 7:37 AM Flandin, Guillaume <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> Hi Arnold,
>
> Thanks, we went down the same road with Melanni last week, and, while I
> am still trying to understand what the problem is (somehow related to
> memory alignment), the issue was disappearing if the MEX file were
> compiled from a terminal:
> mkoctfile --mex mat2file.c
> instead of invoking mex() within octave:
> mex mat2file.c
> It shouldn't make any difference (check the source code of mex.m) but
> apparently it does... I would be curious if you can reproduce the same
> phenomenon.
>
> Best regards,
> Guillaume.
>
>
> On 30/10/2018 21:33, Arnold Evia wrote:
> > Hello Guillaume and Melanni,
> >
> > I am also having the same issue as Melanni using PALM in Ubuntu.
> > I tried the commands that you suggested, and got the same output
> as Melanni.
> >
> > After some debugging, I may have found a clue as to what's happening.
> > In mat2file.c, I placed a few print statements for some variables
> right before the error message (line 252):
> >
> > printf("code = %d\n",map->dtype->code);
> > printf("bits = %d\n",map->dtype->bits);
> > printf("channels = %d\n",map->dtype->channels);
> >
> > if (map->dtype == NULL) mexErrMsgTxt("Unrecognised
> 'dtype' value.");
> > if (map->dtype->bits % 8) mexErrMsgTxt("Can not yet write
> logical data.");
> > if (map->dtype->channels != 1) mexErrMsgTxt("Can not yet write
> complex data.");
> >
> > The program returned unusual numbers:
> >
> > code = 16
> > bits = 32726
> > channels = 7
> > Error using subsasgn>subfun
> ([log in to unmask]:168)
> > mat2file: Can not yet write logical data.
> >
> > Running the program again with the same parameters, values for
> code and channels stays constant, but the value for bits would change:
> >
> > code = 16
> > bits = 32696
> > channels = 7
> > Error using subsasgn>subfun
> ([log in to unmask]:168)
> > mat2file: Can not yet write complex data.
> >
> > As you can see, sometimes bits will be divisible by 8, and the
> program returns a different error.
> > There is a table in the script that defines the values for bits,
> and channels for a specific code.
> > In this case, bits should be 32, and channels should be 1.
> > I don't know why bits and channels are being set to incorrect
> values, and I hope this sheds some light.
> >
> > -Arnold Evia
> >
>
> --
> Guillaume Flandin, PhD
> Wellcome Centre for Human Neuroimaging
> UCL Queen Square Institute of Neurology
> London WC1N 3BG
>
--
Guillaume Flandin, PhD
Wellcome Centre for Human Neuroimaging
UCL Queen Square Institute of Neurology
London WC1N 3BG
########################################################################
To unsubscribe from the FSL list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=FSL&A=1
|