itaps-parallel VisIt Linked with Parallel FMDB

[Mark Miller]

Hi Onkar,

Some good news. I've managed to link VisIt with parallel FMDB vi iMeshP
and open a multi-part sms file. However, when I go to plot it in VisIt,
it is segv'ing somewhere in VisIt. So, I still have some work to do.
However, up until now, it has been a major chore to get everything to
link and operate correctly. VisIt's shared libraries have made it
particularly difficult.

Mark

On Wed, 2008-11-12 at 16:33, Onkar Sahni wrote:
> I think my point is being missed, here is my last attempt... if in case of
> MOAB "AC_CONFIG_HEADERS is called to produce MBCN_FCDefs.h" why not one
> can produce "ITAPS_FCDefs.h" in a central place and one central
> iMesh_protos.h includes ITAPS_FCDefs.h that is generated during as an
> install/build process (all ITAPS header files can live in one location,
> for example, /usr/local/itaps/headers).
> 
> In summary, user/app. would do following basic steps:
> 
> * Download itaps-headers (say in /<path-itaps-headers>/)
> * Run configure to generate ITAPS_FCDefs.h in /<path-itaps-headers>/ (an
> app./user would do this step with platform and compiler combination of
> their choice)
> 
> * Download any implementation/service (such as FMDB/MOAB/GRUMMP or iZoltan)
> * Run configure and compile it (point to /<path-itaps-headers>/ to get
> header files from central place)
> 
> * Write app. code like MHD solver
> * Build it and link with appropriate libs. (ofcourse fortran name mangling
> has to be consistent while compling app. code with ITAPS_FCDefs.h
> generated by app.)
> 
> Is this not possible?
> 
> - Onkar
> 
> > On Wed, 2008-11-12 at 16:53 -0500, Onkar Sahni wrote:
> >> > The FC_FUNC macro winds up getting defined by something; Autoconf's
> >> configure script does some work to define it. Or, like Onkar suggests,
> >> you can define some logic ahead of time to set whatever FC_FUNC does
> >> using logic like so...
> >> >
> >> > #ifdef AIX
> >> > #define FC_FUNC(lowFunc,UPfunc) _lowFunc
> >> > #elif GFORTRAN
> >> > #define FC_FUNC(lowFunc,UPfunc) UPfunc
> >> > #elif ...
> >> > ..
> >> > .
> >>
> >>   So here is my question (basically what I was trying to ask in
> >> tele-con)
> >> which may or may not be possible:
> >>
> >>   Can "#define FC_FUNC............" be generated in a central place
> >> during
> >> the process to install and build itaps softwares (before building any
> >
> > I don't think it can because its definition depends on the name mangling
> > properties of the fortran compiler being used at time of (configuration)
> > compilation. Yes, the number of possible definitions for FC_FUNC is
> > finite, but know which it should be set to for a given compiler (and
> > what to use in the way of a detecting that) varies from compiler to
> > compiler. The BEST you can achieve is to identify what FC_FUNC should be
> > identified for common cases or cases that you know of so that it doesn't
> > need to be re-computed with each configure/compile.
> >
> >> implementation/library or service). This would be an extra configure
> >> step in say /usr/local/itaps/headers (central location where all headers
> >> sit along with probably configure stuff) and this step would just
> >> generate a new header file say "itaps_fc_func.h".
> >
> >
> >> Say if one uses gfortran then the header file generated in "central"
> >> place
> >> (as an extra step using configure in "central" place) will contain
> >> following lines and every service and implementation simply use it.
> >>
> >>   #ifndef _ITAPS_FC_FUNC_H_
> >>   #define _ITAPS_FC_FUNC_H_
> >>
> >>   /* following line is for specific platform, compiler... combination */
> >>   #define FC_FUNC(lowFunc,UPfunc) UPfunc
> >>
> >>   #endif
> >>
> >> - Onkar
> >>
> >> >
> >> > The only issue I see with this approach is that you need to have
> >> defined
> >> ahead of time all the possible #ifdef #elif cases above and whenever you
> >> go to a new machine, then you'll have to re-visit this logic. So, I like
> >> the approach where Autconf's configure is used to set FC_FUNC.
> >> >
> >> > Finally, whatever FC_FUNC is set to, it MUST match the actual name
> >> mangling used by whatever fortran compiler is being used to compile the
> >> code. So, it is not just a matter of everyone agreeing on an
> >> > implementation for FC_FUNC. FC_FUNC must also address whatever name
> >> mangling is being used by a given fortran compiler on a given platform
> >> when the code is getting compiled. For that reason, I think the best
> >> approach is the Autoconf approach.
> >> >
> >> > 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!!)
> >> >
> >> >
> >>
> >>
> >>
> >>
> > --
> > 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!!)
> >
> >
-- 
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!!)