Help getting HelloMeshF77.F to run on GRUMMP

[Mark Miller]

Hi Tim,

Sorry if you wound up re-stating something from a previous email.

No, I didn't search the archives. I don't think I know where they are.
but, I could have at least searched my own 'archive' of itaps emails.

On Tue, 2009-11-03 at 14:25 -0600, Tim Tautges wrote:
> 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.

Thats only true as long as they never debug anything.

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

Ok, I understand that. At least in theory. In practice, I really wonder
if that overhead -- which would exist only for a fortran caller -- is
going to be any factor in adoption.

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

Funny you should say that. Becuase, you just requested we add
iBase_OPTION_NOT_PROCESSED.


> 
> > 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?).

yeah, thats right or maybe all lower case?

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

Ok, maybe this explains why it won't work after I've compiled it.

> 
> > 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
> > 
> > 
> > 
> 
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86 at llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)