Fortran code in Simulink

4 views (last 30 days)
afaq ahmad
afaq ahmad on 5 Dec 2021
Edited: dpb on 6 Dec 2021
I tried invoking Fortran legacy code in Simulink by means of S-function and C-wrapper function.
I was able to compile and link the Fortran subroutines with mex file. However, when I run the simulation in Simulink, I recieve the following error:
I can't make out of what this error actually means and would really appreciate if someone unwraps it.
Thanks.
  2 Comments
dpb
dpb on 5 Dec 2021
Edited: dpb on 5 Dec 2021
Pretty clear -- the Fortran code tried to write to a file opened as READONLY.
By convention in Fortran, units 5,6 are connected to input/output console units, respectively, by default and no explicit OPEN is needed...
Of course, with MATLAB/Simulink, TMW may have done something behind the scenes to prevent console output, I dunno; I don't have and have never seen Simulink so no idea if S-files have any such restriction imposed on them. If so, that should be documented as such.
From the truncated error output you posted, we can't see if the offending Fortran routine was identified or not -- since it is encapsulated in a DLL, likely it isn't so you'll have to look for where it might be in the source file. I also dunno what debugging facilities for mex filex Simulink might support, if any, if you were to compile/link with debug info.
The line
write (lutty,1800) xnormc,xnormr
is in the Fortran routine you were having difficulty compiling yesterday, but the definition of lutty wasn't provided. But, you'll need to examine all WRITE and OPEN statements to see just what the code is trying to do.
Here, one would expect the lutty would resolve back to 6.
dpb
dpb on 6 Dec 2021
Edited: dpb on 6 Dec 2021
Oh! Another thought...since you're apparently picking up pieces of what was a Fortran application and trying to use them standalone inside MATLAB/Simulink by turning them into mex functions, have you ensured all variables are initialized?
One would have to see how the original program main program module was constructed to see where/how all those LU numbers were assigned -- if you didn't provide for them, since Fortran compiles every compilation unit independently, it can't tell if a variable such as lutty is passed as an argument has been defined or not (in the calling function/subroutine/program -- it's defined locally by the dummy argument, of course).
If there were a BLOCKDATA module or DATA statements and COMMON or just what/how it was done, you'll need to make sure they are all defined correctly. Unless, of course, there is a DATA or an assignment statement inside each subroutine -- which would not be the normal coding practice, btw.
Not sure what Intel compiler does with unitiialized variables -- the Fortran Standard does NOT specify that a declaration such as
integer lutty
also imples a zero initialization or any such thing -- the variable is allocated memory, but nothing is assigned; that is the programmer's responsibility. In the olden days with single-user machines and less concern over security issues, one got whatever happened to be left over in memory at that location when the program ran; today the OS will likely clear memory before handing it over to the process so there's a pretty good chance if you overlooked defining these explicitly that they are 0 at run time.

Sign in to comment.

Answers (0)

Categories

Find more on Fortran with MATLAB in Help Center and File Exchange

Products


Release

R2018a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!