see about upgrading our ExodusII/Nemesis versions #35

Closed
benkirk opened this Issue Jan 30, 2013 · 24 comments

Projects

None yet

5 participants

@benkirk
libMesh - C++ Finite Element Library member

@roystgnr says

"The version up on SourceForge seems to be using int64_t pretty
universally; the one in our contrib/ is hard-coded for int."

I'll take a look at this, but probably after the release.

@benkirk benkirk was assigned Jan 30, 2013
@benkirk
libMesh - C++ Finite Element Library member

I've got the latest exodusI/nemesis and netcdf packages, and am going to work on this this week while on travel...

@jwpeterson, I'll point you to my branch to try when it is working, you can let me know how bad this hurts MOOSE before I commit it to libMesh/master.

@benkirk
libMesh - C++ Finite Element Library member

This is going to be a big deal - in particular, the new exodus implementation requires netcdf-4.1 or greater, which in turn requires hdf5.

since our old exodusII/nemesis API has so few requirements, I'm inclined to leave it for a while with an --enable-old-exodusII or something.

@roystgnr, @friedmud, @jwpeterson -- thoughts?

-Ben

@friedmud
libMesh - C++ Finite Element Library member
@benkirk
libMesh - C++ Finite Element Library member
@friedmud
libMesh - C++ Finite Element Library member
@jwpeterson
libMesh - C++ Finite Element Library member
@benkirk
libMesh - C++ Finite Element Library member

I'd rather not distribute it (1) because configuring it takes as long (or longer) than libMesh, and (2) it is pretty widely available (more so than netcdf anyway). But I've got a fallback if we want to - since HDF5 is an autotools package it is easy to incorporate it, but at the cost of longer configures.

At any rate, I've got an exodus_refresh branch going at https://github.com/benkirk/libmesh.git

@jwpeterson, could you take a look at this and see how bad it is going to hurt you guys? By default it builds all the old stuff, you can force the new API by

$ ./configure ... --enable-netcdf=new --enable-exodus=new --enable-nemesis=new

It should find your HDF5 if it is there. If you don't have HDF5 you can still do

$ ./configure ... --enable-netcdf=new --enable-exodus=new --enable-nemesis=new --disable-hdf5

and that'll still build the new API, but my understanding is large files (>2Gb) won't work.

@friedmud
libMesh - C++ Finite Element Library member

I just pulled this down and I'm building it now...

@friedmud
libMesh - C++ Finite Element Library member

Looks like it's not quite working with in-tree building:

libtool: link: `/Users/gastdr/projects/libmesh/lib/libnetcdf.la' is not a valid libtool archive

I got that at the end of trying to compile MOOSE. We may have something wrong with our Makefile stuff...

I just "make install"ed and I'm rebuilding.

@benkirk
libMesh - C++ Finite Element Library member
@friedmud
libMesh - C++ Finite Element Library member

Surprisingly.... all is well with MOOSE when using:

../configure --prefix=$INSTALL_DIR --with-methods="opt dbg" --enable-legacy-include-paths --enable-legacy-using-namespace --enable-netcdf=new --enable-exodus=new --enable-nemesis=new --disable-hdf5

That was easy ;-)

Thanks for doing this Ben!

@benkirk
libMesh - C++ Finite Element Library member

Awesome, thanks for testing it.

I'm planning to tag v0.9.0 as soon as everything is green again, and afterwards I'll merge this. We can then decide when to make this the new default.

@benkirk
libMesh - C++ Finite Element Library member

This is merged as of 9d7303f, however it is not yet the default.

At present, you can configure using the new code via

    $ ./configure ... --enable-netcdf=new --enable-exodus=new --enable-nemesis=new

so @roystgnr it would be interesting to see what all those int64's do for you, which I think was the original motivation here.

@benkirk
libMesh - C++ Finite Element Library member

I'm going to make the 'new' flavors default, the 'old' will be optionally available.

@pbauman
libMesh - C++ Finite Element Library member
@benkirk
libMesh - C++ Finite Element Library member

I've done both, with no surprises.

@pbauman
libMesh - C++ Finite Element Library member
@jwpeterson
libMesh - C++ Finite Element Library member

As far as in-tree (uninstalled) builds are concerned, the new netcdf doesn't work out of the box, since its an automake package. Those who are interested in doing uninstalled builds can work around it by doing:

${LIBMESH_DIR}/libtool --mode=install install -c \
${LIBMESH_DIR}/contrib/netcdf/4.2.1.1/liblib/libnetcdf.la ${LIBMESH_DIR}/lib

But this doesn't feel like a great solution since you have to know the intricate details of netcdf's location within the contrib hierarchy.

@roystgnr
libMesh - C++ Finite Element Library member

How do we get netcdf v4 to build correctly when hdf5 isn't in the compiler's default search path? Our own hdf5.m4 is autodetecting my hdf5 module based on the environment variables it sets, but we don't seem to be passing the resulting HDF5_CPPFLAGS/CXXLIBS information to contrib/netcdf/v4/configure, and looking through their configure.ac I don't even see how we'd pass that information in.

@benkirk
libMesh - C++ Finite Element Library member

Can you uncomment the end of configure.ac line 332 and see if that does it for you?

That seems a little heavy handed, passing all our optional includes and libs, but is the generic approach. Note though this can creep into our AC_OUTPUT more than I'd like, and to cherry-pick the options I'm considering something along these lines:

http://gnu-autoconf.7623.n7.nabble.com/AC-CONFIG-SUBDIRS-right-away-td9738.html

@roystgnr
libMesh - C++ Finite Element Library member
@benkirk
libMesh - C++ Finite Element Library member

The immediate annoyance I noted was that sometimes AC_OUTPUT would get invoked on reconfigure and LIBS=... would get handed back to us, which of course is not a problem since they were ours to begin with, but made the perflog configure output look horrible. :-)

But yeah, the idea would be to do each subdir one at a time, exactly when needed, specifying only the arguments it needs. This shows up on the list as a highly desired feature for autoconf, so maybe if we do it right it'll go upstream and no longer be unsupported.

@benkirk
libMesh - C++ Finite Element Library member

@permcody requested we also build the Fortran bindings -- easy enough, but I'll defer until tomorrow or the next day when I have a couple hours to devote to "automakethink."

Just a note so I don't forget.

@benkirk benkirk added a commit to benkirk/libmesh that referenced this issue Apr 2, 2013
@benkirk benkirk implement ExodusII Fortran API (#35) 939d72c
@benkirk benkirk added a commit to benkirk/libmesh that referenced this issue Apr 8, 2013
@benkirk benkirk implement ExodusII Fortran API (#35) a18fed1
@benkirk
libMesh - C++ Finite Element Library member

I added the Fortran bindings, and things seem to be good with the new Nemesis/Exodus/Netcdf.

@benkirk benkirk closed this Apr 18, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment