Converting legacy FORTRAN code to MATLAB code

I have found Ben Barrowes' f2matlab program for converting legacy FORTRAN to MATLAB.

Has anyone actually used this software successfully? When I try to run it from the command prompt:

f2matlab('myprogram.f90')

or

f2matlab('myprogram.f')

where myprogram.90 or myprogram.f are in the correct location and are found, the code blows up right away on a disp statement with the following error message. It looks like it tries to read the first statements of the .f90 or .f files as a filename:

************************************************************************************************************************************************************

-----------------------------------------------------------

| f2matlab -- Ben Barrowes, Barrowes Consulting |

-----------------------------------------------------------

Not enough input arguments.

Error in f2matlab (line 225)

disp(['Before includes ',filename,' (',num2str(cputime-tStart),' elapsed)']);

*************************************************************************************************************************************************************

Anyway, does anyone know what is going on?

Answer 1

[Cris LaPierre]

Ben seems to be responsive to Discussion posts on the corresponding File Exchange page. You might try posting your question there.

https://www.mathworks.com/matlabcentral/fileexchange/5260-benbarrowes-f2matlab

[Ken Bannister]

Many thanks. I discovered that the file I wanted to convert was NOT in the path

where Ben's program could find it. My bad!

[Ben Barrowes]

Ken. Let me know if you run into problems with f2matlab. Follow the README file first, but I can usually help with conversions pro bono if you don't need me to validate or debug the resulting matlab code.

[Ken Bannister]

Sir, thanking you for your kind offer of help. f2matlab is truly a miraculous program. I am learning. A big part of my challenge is not f2matlab at all, but MATLAB itself! When I converted the small F77 routine "print1," listed below, f2matlab did the best it could to convert the write and format statements, but then matlab couldn't execute them. I found out that printing out arrays, so easily done in FORTRAN, is a giant pain in the kiester in MATLAB. I had to do Google searches to find good examples of how arrays are printed out in MATLAB, copy them into my converted version of print1, and conduct trial-and-error experiments until I got it to work - not inuitive at all! It could be I did not use f2matlab correctly. Perhaps if you processed my print1 through your version of f2matlab, a better result would ensure.

V/R, - Ken Bannister

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

subroutine print1(n1,w,s,n2,nout)

dimension w(20),s(20,20)

write(nout,25)

do 20 j=1,n1

if(w(j))5,10,10

5 v1 = -sqrt(-w(j))/6.2831853

go to 15

10 v1 = sqrt(w(j))/6.2831853

15 write(nout,30)j,v1

write(nout,35)(s(i,j),i=1,n2)

20 continue

25 format(///1x,12h mode shapes)

30 format(/1x,12h mode number,i3,12h ferquency ,e12.4)

35 format(1x,4e12.4)

return

end

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++The conversion result was as follows. Turned out the "[n1,w,s,n2,nout]=" character string in the function line may be unnecessary. I wasn't sure what happened with the if statement "if(w(j))5,10,10". The result was:

if(w(j));

5,10,10;

end;

I also don't know why "j=n1+1" appeared after the last end statement. Again, easy to remove it.:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

function [n1,w,s,n2,nout]=print1(n1,w,s,n2,nout,varargin);

format_25=[ '\n ' , '\n ' , '\n ' ,'%1x',' mode shapes'];

format_30=[ '\n ' ,'%1x',' mode number',repmat('%*g',1,_),'%3d',' ferquency','%12.4e'];

format_35=['%1x',repmat('%12.4e',1,4)];

s_orig=s;s_shape=[20,20];s=reshape([s_orig(1:min(prod(s_shape),numel(s_orig))),zeros(1,max(0,prod(s_shape)-numel(s_orig)))],s_shape);

[writeErrFlag]=writeFmt(nout,[format_25]);

for j=1:n1;

if(w(j));

5,10,10;

end;

v1 = -sqrt(-w(j))./6.2831853;

go to 15;

v1 = sqrt(w(j))./6.2831853;

[writeErrFlag]=writeFmt(nout,[format_30],'j','v1');

[writeErrFlag]=writeFmt(nout,[format_35],{'s(i,j)','i','1','1','n2'});

% 20 continue;

return;

end j=n1+1

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

And when I try executing it, I got the following output. All it meant was that in format_30, in the character string "repmat('%*g',1,_)" the underscore came out as an illegal ASCII character, so merely needed to be deleted. But then the fun began to get the write statements working:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>> print1

Error: File: print1.m Line: 5 Column: 56

Invalid text character. Check for unsupported symbol, invisible character, or pasting of non-ASCII

characters.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Ken Bannister]

Ben: One further comment. Again, not at all an f2matlab problem. I keep having trouble in MATLAB with making sure everything needed is in the correct path so that it can be found. It could be I didn't do this correctly with f2matlab. Any advice you can render on this would be greatly appreciated. - Ken

[Ben Barrowes]

Ken: your code has a couple of issues that the free fileexchange version of f2matlab can't handle. In the README file it says that the file needs to have all goto statements (including arithmetic if statements) refactored before f2matlab can work. This is an "arithmetic if" in your code:

if(w(j))5,10,10

And then you also have a goto statement "go to 15" in your code.

I have a more capable version of f2matlab, and here is the result for your code:

function [n1,w_fv,s,n2,nout]=print1(n1,w_fv,s,n2,nout,varargin);
persistent firstCall i j v1   format_25  format_30  format_35

if isempty(firstCall);
    firstCall=1;
end;
if firstCall;
    format_25=[ '\n' , '\n' , '\n' ,'%1x',' mode shapes'];
    format_30=[ '\n' ,'%1x',' mode number','%3i','  ferquency ','%12.4e'];
    format_35=['%1x',repmat('%12.4e',1,4)];
    i=0;
    j=0;
    v1=0.0;
end
firstCall=0;
[s,s_orig,s_shape]=reshapeinout(s,[20,20]);
[writeErrFlag,wfso]=writeFmt(nout,[format_25]);
eval(wfso);
for j = 1: n1
    if(w_fv(j) < 0)
        v1 = -sqrt(-w_fv(j))./6.2831853;
    else;
        v1 = sqrt(w_fv(j))./6.2831853;
    end
    [writeErrFlag,wfso]=writeFmt(nout,[format_30],'j','v1');
    eval(wfso);
    [writeErrFlag,wfso]=writeFmt(nout,[format_35],{'s(i,j)','i',1,1,n2});
    eval(wfso);
end
j = fix(n1+1);
s=reshapeinout(s,s_orig,s_shape);
end %subroutine print1

I have attached a zip file of some auxiliary functions that this routine will also need (writeFmt.m, reshapeinouts.m, etc.).

Some of these lines are probably overkill for your code (reshaping inputs and outputs), but fortran can do some things that matlab can't (and probably shouldn't) do. For example, in fortran, you could pass just a 1-D vector 400 values (or longer!) long into your 3rd input, s, and fortran would be fine with it. Not so in matlab. Thus the reshaping just in case. If I turn this functionaliy off, the code would look like this:

function [n1,w_fv,s,n2,nout]=print1(n1,w_fv,s,n2,nout,varargin);
persistent firstCall i j v1   format_25  format_30  format_35

if isempty(firstCall);
    firstCall=1;
end;
if firstCall;
    format_25=[ '\n' , '\n' , '\n' ,'%1x',' mode shapes'];
    format_30=[ '\n' ,'%1x',' mode number','%3i','  ferquency ','%12.4e'];
    format_35=['%1x',repmat('%12.4e',1,4)];
    i=0;
    j=0;
    v1=0.0;
end
firstCall=0;
[writeErrFlag,wfso]=writeFmt(nout,[format_25]);
eval(wfso);
for j = 1: n1
    if(w_fv(j) < 0)
        v1 = -sqrt(-w_fv(j))./6.2831853;
    else;
        v1 = sqrt(w_fv(j))./6.2831853;
    end
    [writeErrFlag,wfso]=writeFmt(nout,[format_30],'j','v1');
    eval(wfso);
    [writeErrFlag,wfso]=writeFmt(nout,[format_35],{'s(i,j)','i',1,1,n2});
    eval(wfso);
end
j = fix(n1+1);
end %subroutine print1

Answer 2

[Ken Bannister]

Ben: Many thanks again on your help. You are right, I should have studied your README file much more carefully! I have always been ill-at-ease with FORTRAN if statements, and MATLAB's slightly different way of handling them has only added to my unease. I never used FORTRAN go to statements in my own programming work because I was told they represent bad programming practice. I remember at one time, in an early FORTRAN version, it was even possible to use a "computed go to" statement of the form "GO TO M" where "M" was a statement number your program could compute on the fly! Two other FORTRAN features I really hate are COMMON (labeled and unlabeled), and EQUIVALENCE. If you aren't careful, you can do serious damage to your data (and your psyche) using EQUIVALENCE statements. Computer memory (they called it "core storage" in the old days) used to be a very precious and costly commodity, so programmers would go to extremes to minimize memory use. FORTRAN developers accommodated this zealous pursuit.

Thanks also for sharing your MATLAB expertise and sharing the zip file of additional f2matlab routines. There is no way I could have figured out some of these solutions on my own. I see two new (to me) functions , "persistent" and "reshape" I need to learn about and understand how to use. The program that houses my "print1" routine does have some variables it needs to share with several other routines. It looks like the old MATLAB "global" statement is no longer recommended, so I need to figure out a good alternative. - Ken Bannister

[Ken Bannister]

Ben: Just curious what this output means from f2matlab. I converted another f77 routine to f90 using an online British source, making sure all the "go to" statements were reprogrammed ("refactored"?). When I ran it through f2matlab, I got the messages below, followed by output that looks substantially like what I submitted. Perhaps conversions of some statements to MATLAB were indeed done, but maybe there too many other issues were present in the f90 file to go any further? There were several DIMENSION, COMMON, and EQUIVALENCE statements that remained in the f90 file, so perhaps all those have to converted by hand? :

V/R, Ken Bannister

">> f2matlab('MAIN_PROGRAMf90.f90')

-----------------------------------------------------------

| f2matlab -- Ben Barrowes, Barrowes Consulting |

-----------------------------------------------------------

Before includes MAIN_PROGRAMf90.f90 (0.03125 elapsed)

Read in the file MAIN_PROGRAMf90.f90 (0.09375 elapsed)

preliminary simple changes (set 1) (0.23438 elapsed)

preliminary simple changes (set 2) (0.4375 elapsed)

Done with preliminary simple changes (0.48438 elapsed)

********* Taking care of the modules (if there are any) *** "

[Ken Bannister]

Ben: My bad. After further testing using a much-reduced version of my converted f90 input, I discovered that it

helps to have a "program" statement at the top of the file, e.g., "program ken_test". Once I added a statement like that, f2matlab was able to do its processing. V/R, Ken