MATLAB: Simulating Fortran common blocks with a nested function in Matlab.

Question

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

"...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.