Simulating Fortran common blocks with a nested function in Matlab.

I took some Fortran code and converted it into Matlab code. The Fortran code had a lot of common blocks being used to update various variables. I originally tried using a very large structure to pass things back and forth between various functions but found this to be very slow. Now I have things all nested in a function, partly because this is a method of lines approach, splitting up PDES into DAEs and using ODE15s but also this allows updating of various variables without having to pass things back and forth all of the time. Not the best for readability. I now have some time to clean this up and was wondering if anyone has some good approaches for dealing with Fortran code with a lot of common blocks and transferring it over to Matlab.

Both the Matlab and Fortran codes give similar results and in 2014b, Matlab seems to keep up. Probably because both are poorly optimized.

I guess what I am wondering is, with very large systems of equations, where there are a lot of variables describing the physical problem, will separate functions be faster than nested functions?

Answer 1

[dpb]

"...approaches for dealing with Fortran code with a lot of common blocks and transferring it over to Matlab."

My first plan would be to turn it into a mex function rather than converting it.

"with very large systems of equations, where there are a lot of variables describing the physical problem, will separate functions be faster than nested functions?"

Only profiling would tell for certain but the answer is almost certainly "no". That there has to be an invocation of the argument list on the call that isn't there in the nested function implies the obverse unless there's some other "trick" going on that the JIT compiler can take care of transparently and behind the scenes.

How much difference there would be in an absolute sense would have much to do with how the nesting is; but typically if it's the functional and jacobean, etc., etc., etc., ... they're called at the deepest level so the call/return overhead may in fact be a sizable factor overall.

Again, if it runs as the Fortran code, I'd just build an interface to that code to call from Matlab and be done.

[Marc]

Thanks dpb.

I was thinking about turning this into a mex function but there is a lot of stuff that I have created over the years in Matlab that I want to add on to this code within the function. Plus, the ODE solver being used in the original is LIMEX, which is a very nice solver, but I wanted to have the flexibility of using the Matlab solvers or Sundials as well.

Interestingly, the Matlab code with the nested functions and ODE15s, runs very close in speed if not faster than the Fortran code. I think a big part of this is because the way the original code sets up LIMEX, it calls it at very small time increments, whereas ODE15s chooses its own time increments. Hence, the fortran code calls LIMEX a lot of times, where I am only calling ODE15s "once" for a given time interval.

I would really have to rethink things but maybe I could MEX the Fortran function and use ODE15s or CVODE with that?

Thanks

[dpb]

Sure, you can call virtually anything from Matlab in the MEX function if it works better that way.