Help getting HelloMeshF77.F to run on GRUMMP

[Tim Tautges]

Preamble: have you searched around on the tstt-interface list archives?  I thought we described many of these things 
when we went to the C interface, but I could be wrong.  It doesn't hurt to describe them again, though.

And yes, Carl, this does need to be documented somewhere besides email :).

Mark Miller wrote:
> Hi All,
> 
> In order to understand problems I introduced for Fortran interface as a
> result of my recent change to iMesh.h, I went ahead and compiled one of
> the Fortran examples I could find, HelloMeshF77.F against GRUMMP.
> 
> I learned a few things I want to share here and I have a question or two
> also.
> 
> First, I did not understand this until yesterday, but we're using
> FC_FUNC and CPP to map symbols in C language to the Fortran name mangled
> equivalent bindings. So, the result of this is that the actual
> implementation's .a file has imesh_newmesh__ defined but not
> iMesh_newMesh. This is a bit odd. For example, debugging C code means I
> set break points on imesh_newmesh__ and not iMesh_newMesh. That is a
> little strange but maybe ok.
> 

To be a bit more precise, and to indicate the motivation a bit better, these macros map what the code says is the 
unmangled iMesh function names into the mangled form, which is callable as-is from C and Fortran both.  So, the user 
always sees the unmangled names in code.  The mangled names are usually different from those.

> I guess I understand why we're doing it that way. Fortran doesn't have
> the equivalent of CPP. So, we can't very well do this kind of magic with
> Fortran. Or can we? Why not use CPP and code-generate the Fortran
> interface from the C interface resulting in an implementation having,
> for example, both iMesh_newMesh (C func.) and imesh_newmesh__ defined in
> the resulting .a/.so files. I think this would be easy using CPP. Every
> fortran func would immediately just turn around and call its C
> equivalent....
> 
> void imesh_newmesh__(...) { iMesh_newMesh(...); }
> 

Well, many large Fortran applications use CPP to preprocess their fortran anyway (thus the .F extension, rather than .f 
or .f77), and all the systems I know of support this (that's not precise, but it's not worth the time to state 
properly).  So it's not a matter of doing it easily with the preprocessor.  The real crux is that we don't want to call 
wrapper functions, which impose an overhead that can be avoided.  One could argue you could do this with inlining too, 
but then you wouldn't be compatible with f77.

> Next, there is an iMesh_f.h file required to compile HelloMeshF77.F but
> I could NOT find it where I thought it should be. I found it
> in ./Papers/iMesh07/FindConnect/iMesh_f.h. Shouldn't this be 'next to'
> iMesh.h. Also, shouldn't we just code generate this file from iMesh and
> likewise from iBase? I have code that does this kind of thing for Silo
> library.
> 

We could, but the things in iMesh_f.h are almost completely static, i.e. they haven't changed since the C interface was 
written.

> Next, why is HelloMeshF77.F written using the C-like symbol names for
> the functions? It uses iMesh_newMesh() knowing that fortran compiler
> will mangle case. It is a bit unnatural. Why not just use the 'natural'
> fortran thing? imesh_newmesh()
> 

How compilers mangle case is not part of the standard.  So, those applications would have to change depending on the 
compiler.  In other words, there is no natural fortran thing.  That statement applies more to underscores than to case 
(I think the f77 standard says all upper case, right?).

> Next, in order to compile HelloMeshF77.F, I needed to compile with g77
> but link with g++. Now, I did NOT use the Makefile.noatuconf there. I
> just compiled things manually. But, I think this is right as GRUMMP is a
> C++ implementation under the covers. And, we cannot link it correctly
> without a C++ compiler. Do others agree? Or, did I do something wrong?
> 

You're only partly correct there.  First, I don't think g77 is going to work for you at all, you should be using 
gfortran.  Second, you'll need the 4.3 series of gcc, because it was only with that version that gfortran supported call 
by value.  Third, you don't need to link with g++, as long as the linker you are calling is told the correct libraries 
to link in.  In MOAB, we accomplish this by putting those extra library link parts in a make variable which can be used 
by applications.  I don't remember, but I think they may be appended to IMESH_LIBS.

> Finally, I cannot get HelloMeshF77 to run successfully. GRUMMP is always
> trying to add '.vmesh' to the filename. That is fine, but try as I
> might, no matter what I do, iMesh_load() winds up getting some scrambled
> name.
> 

That's a GRUMMP issue, I suspect.

- tim

> Mark
> 
> 
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706