fortran to matlab
ambi
Does anybody know is there are any equivalents to FORTRAN's named
"common blocks" in MATLAB?......
Ian Harvey
Tobias Burnus
> A global variable that is a structure.
But be careful with padding, if your elements in the structure/common
block which are smaller than the alignment.
For illustration, try the following program with and without the pragmas
uncommented - and, in case of gfortran, with and without -fno-align-commons.
For some compilers, one may need to change the number of underscores
(especially: "global_var__") in the C program - or use BIND(C).
Tobias
! ------------- Fortran part ---------
subroutine test()
character :: a
integer :: b
character :: c
common /global_var/ a, b, c
print *, a, b, c
end subroutine test
/* ------------ C part ------------ */
/*#pragma pack(push)
#pragma pack(1) */
typedef struct {
char a;
int b;
char c;
}
type;
/*#pragma pack(pop)*/
extern type global_var_;
void test_(void);
int main ()
{
global_var_.a = 'a';
global_var_.b = 42;
global_var_.c = 'c';
test_ ();
return 0;
}
Tobias Burnus
> But be careful with padding, if your elements in the structure/common
> block which are smaller than the alignment.
The last sentence is completely mangled. I wanted to write: if there are
elements in the structure, which are smaller than the alignment.
Typically, the hardware and compilers use word alignment (32 bit/4
byte). Hence, one has alignment problems with variables such as
characters (with length which are not multiples of 4) or some integer
types (e.g. c_char, c_short, ...).
If you use as in the example, "(1 byte)(4 bytes)(1 byte)" variables,
there is the problem that accessing the second variable is inefficient
as it is spread over two 4-byte blocks. Hence, compiler like to add some
paddings: "(1 byte)(3 bytes paddings)(4 bytes)(1 byte)".
Depending whether the C or the Fortran compiler adds padding, the result
differs. C compilers tend to add padding by default, while some Fortran
compilers do likewise, others don't. Additional, the padding might be
added before or after the "too short" variable.
Tobias
Ian Harvey
> On 09/02/2011 11:12 AM, Ian Harvey wrote:
>> A global variable that is a structure.
>
> But be careful with padding, if your elements in the structure/common
> block which are smaller than the alignment.
I interpreted the original question to be "what is the equivalent
concept in Matlab of named common in Fortran".
dpb
Reading between the header and the question--rather than convert
existing (presumed functional?) Fortran code _to_ Matlab, turn into a
callable Matlab function (or set of functions) via mex.
--
Richard Maine
> On 09/02/2011 11:12 AM, Ian Harvey wrote:
> > A global variable that is a structure.
>
> But be careful with padding,
and with many, many other things. Fortran COMMON has some pretty arcane
features. You won't find anything that is completely equivalent to the
extent that you can convert absolutely any Fortran usage without care.
Such things as COMMON blocks that have different variable names in
different scopes and take advantage of storage association in other ways
can complicate life considerably, even while staying within the
restrictions of the standard. (It can get worse with programs that go
beyond what the standard guarantees). Fortunately, the most common uses
of COMMON are simple, but code that uses the messy bits does exist and
is not as rare as one might hope. I've seen nonstandard COMMON usage
that isn't even easy to port between different implementations of
Fortran.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
benbarrowes
> features. You won't find anything that is completely equivalent to the
> extent that you can convert absolutely any Fortran usage without care.
My approach in f2matlab is to find the first instance of the common
block (say, named cblock). When this file is converted to an m-file,
f2matlab renames every instance of the first variable in the block
cblock_1, the second variable in the block cblock_2, and so on. These
variables are made global. This is done whenever this common block
cblock is found in any of the subprograms in the program suite. In
this way, scope is correct over the entire suite.
I have not found a way to control alignment issues in converting, but
most compilers will warn if alignment matters. In this case, I adjust
the fortran before conversion.
Furthermore, if variable types are mixed between different definitions
of the block (a double in one block corresponds to a character array
in another), that must be manually corrected before or after
conversion.
This approach results in less readable m-code, but it is the way I get
the fewest problems in functionality between the fortran and m-files.
bb
glen herrmannsfeldt
>> features. You won't find anything that is completely equivalent to the
>> extent that you can convert absolutely any Fortran usage without care.
> My approach in f2matlab is to find the first instance of the common
> block (say, named cblock). When this file is converted to an m-file,
> f2matlab renames every instance of the first variable in the block
> cblock_1, the second variable in the block cblock_2, and so on. These
> variables are made global. This is done whenever this common block
> cblock is found in any of the subprograms in the program suite. In
> this way, scope is correct over the entire suite.
That works for the usual cases, though there are some less usual ones.
Note that COMMON and EQUIVALENCE are closely connected. You should
at least generate a message if a COMMON variable is also in
EQUIVALENCE.
> I have not found a way to control alignment issues in converting, but
> most compilers will warn if alignment matters. In this case, I adjust
> the fortran before conversion.
In the early days, the usual way COMMON was defined was that
there was no padding. For hardware with alignment requirements
it was fixed up at run-time. (Copy data, perform operation,
copy back, possibly after an interrupt for bad alignment.)
Later, it was more usual for them to be padded.
Even without alignment problems, there are interesting cases
regarding arrays EQUIVALENCEd to variables in COMMON.
> Furthermore, if variable types are mixed between different definitions
> of the block (a double in one block corresponds to a character array
> in another), that must be manually corrected before or after
> conversion.
Well, that is just bad. But REAL and INTEGER are supposed to be
the same size, and DOUBLE PRECISION twice that size. Those
cases should be made to work. You could number them in terms
of storage location offsets instead of sequentially.
> This approach results in less readable m-code, but it is the way I get
> the fewest problems in functionality between the fortran and m-files.
Seems a fine solution to me.
-- glen