Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Problem with Intel parallel XE compiler

Comrun_Y_
Beginner
682 Views

Hi . I'm using the combination of Intel parallel studio XE 2015 cluster edition (student version) and microsoft visual studio 2013 and Matlab 2016b in order to create MEX files out of Fortran source codes inside Matlab and then call it from Matlab. 

Our Fortran source code is compatible with Digital Visual Fortran (or Compaq visual fortran-CVF). It used to work with that compiler and matlab 2006. Now that we're trying to transfer them into windows 7 with new version of Matlab, I got some errors. I already made the mex file successfully inside the Matlab2016 but when it comes to call the mex file, Matlab crashes. 

I also went through the article " Migrating from Compaq* Visual Fortran" but couldn't solve this. Would you please help me with this?

For your information, I've attached some parts of our fortran .F file.

 

Thanks,

 

0 Kudos
13 Replies
Comrun_Y_
Beginner
682 Views

Hi

527897J

 

ust wanted to provide you a little bit more information. Originally, we had .for file which was compatible with CVF and was working in old version of Matlab. I changed that file to .f90 (and .F) and created a .mexw64 file in Matlab 2016 using ifort 2015 and VS 2013. Our Matlab program runs fine until it comes to call this function. When there is no .mex file in the Matlab path, it gives an error looking for this function and when I put the .mex file of this code, It crashes (giving me the error that I've attached)

 

 I found a .dsp file  (our CVF project file) and then opened that in Visual studio 2013 and it showed me the same box asking to convert it to current Intel visual format and then, I followed the article (i.e Migrating from compaq to Intel ...), right clicked at the file and selected "extract compaq visual fortran project items and it showed me .f90 files (automatically converted new file) . 
 
Everything looks the way it supposed to be except that when I extract that new .f90 file and created a new mex file and put it into folder, I got the same error in Matlab as if it was no change. 
I suspect that It might have something to do with the error I get when I try to rebuild it in Vs13 (please see attached). I'm not sure if i miss a step here or not. Please find some screen shots of the Matlab error (either with or without mex file) as well as Rebuild error in Vs13, attached. 
 
In the meantime, I would be happy to provide you with more information. I look forward to hearing from you.
 
Thank you,
 
 
0 Kudos
mecej4
Honored Contributor III
682 Views

Please provide the source code of your Mex function, using the {code} button or by attaching a zip file containing the source code. No images (JPG, PDF, etc.) for program text, please.

Which version (32- or 64-bit) of Matlab do you use?

0 Kudos
Comrun_Y_
Beginner
682 Views

Hi. Attached, please find the code. I'm using 64 bit version. Thanks 

527901

0 Kudos
mecej4
Honored Contributor III
682 Views

The source file contains fixed format Fortran, so ".f90" is an incorrect suffix for it. After changing the suffix to ".f", I built the Mex file with no problems.

Please provide values of the 31 input arguments for testing the function.

0 Kudos
Comrun_Y_
Beginner
682 Views

I know it create the mex file. Even originally, I built the mex file by changing .for to .F and it was successfully created. Also, I could create that successfully with .f90. The issue is that Matlab crashes when we are trying to call that mex function inside Matlab. This code is a part of a bigger program written in Matlab which crashes when it needs to call this mex. I hope this could clarify my problem. Please take a look at the previously attached file to get an idea about the error. 

0 Kudos
mecej4
Honored Contributor III
682 Views

Your file contains close to 2000 lines of code, and I have no idea what it is supposed to do. The function takes 31 input arguments and 4 output arguments. Given this level of complexity, it is perfectly reasonable that the code may crash because of incorrect arguments being passed to it, or because of some errors in the code itself. To probe further into the cause of the problem, one needs test values for the 31 input arguments.

The Matlab error message simply says that something went wrong inside the function, and you need more information to fix the problem.

0 Kudos
Comrun_Y_
Beginner
682 Views

Ok that makes sense but I know it worked well with CVF and Matlab 2006 on win xp before. So I'm positive that the code doesn't have any bug cause it worked before. However, I'll try it again and will let you know soon. 

0 Kudos
mecej4
Honored Contributor III
682 Views

Comrun Y. wrote:
Ok that makes sense but I know it worked well with CVF and Matlab 2006 on win xp before. So I'm positive that the code doesn't have any bug cause it worked before. 

In 64-bit code, pointers are 64-bits, and integers may be 32-bits (most often) or 64-bits. Therefore, code that assumed that integers and pointers were equal in size and worked in 32-bit code may fail as 64-bit code.

0 Kudos
Comrun_Y_
Beginner
682 Views

Thank you for your comment. So how can I verify this issue? Should I change both the compiler and Matlab to 32-bit? 

I'veI noticed that the intel folder is already installed in "Program files (x86)". Does this indicate that the compiler is 32 bit then? 

0 Kudos
Steven_L_Intel1
Employee
682 Views

The Program FIles (x86) folder is used for both 32-bit and 64-bit compilers. If you build in Visual Studio the project configuration selects whether it is Win32 (32-bit) or x64 (64-bit). There is not enough information here for us to help you - you need the assistance of someone with Matlab and who can build and run your code with that.

0 Kudos
andrew_4619
Honored Contributor II
682 Views

You could create a fortran test program to call your subroutine and see if it behaves how it is meant to with known parameters. This cuts matlab out of the loop when checking for bugs in your source.

0 Kudos
Comrun_Y_
Beginner
682 Views

mecej4 wrote:

Quote:

Comrun Y. wrote:
Ok that makes sense but I know it worked well with CVF and Matlab 2006 on win xp before. So I'm positive that the code doesn't have any bug cause it worked before. 

 

In 64-bit code, pointers are 64-bits, and integers may be 32-bits (most often) or 64-bits. Therefore, code that assumed that integers and pointers were equal in size and worked in 32-bit code may fail as 64-bit code.

Thank you for your comment. I think this is the most probable source of error in my case as I'm using a mix language of Fortran and Matlab. I'm working into converting my code source (or mex declration parts) into 64bit . could you please verify that my code is currently in 32-bit format?

Also, I was wondering if you can help me to convert my code into 64bit in anyway you know ( if you know any article or source by any chance ). I couldn't find a clear instruction on converting from 32-bit to 64-bit on Intel website. 

I'm not sure if converting or debugging the code would work or do I need to re-install any other version of the compiler or visual studio?

My second question is regarding "rebuild" the code. Is there any difference between Converting a CVF Project and rebuilding an existing CVF application? I could follow the steps in the article "migrating from compaq to intel" regarding converting CVF projects but after that, when i was trying to rebuild the code I got several synatx error (please see attached the errors). Should I also rebuild it or converting would be sufficient?

 

 

rebuild error_0.jpg

0 Kudos
mecej4
Honored Contributor III
682 Views

I think that you have misconceptions about Fortran code and building projects in Visual Studio. These are best addressed by your reading appropriate books, manuals and documentation. Reinstalling software or "converting" codes and scripts is probably not going to be of any help.

The error messages in the blurry image in #13 are the result of attempting to compile fixed-format source as if it were free-format source, as I stated in #5. Andrew gave you excellent advice in #12. Follow it, and post any error messages in text form, not blurry images.

0 Kudos
Reply