fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Dec 19, 2005 at 11:05:20PM -0800, Theodore Omtzigt wrote:
> Anders:
> 
>  I had to adjust to the new build process of 0.5.11, but I got everything
> wiggling again. This time I get a different convergence failure:
> 
> *** Error: Krylov solver did not converge. [KrylovSolver.cpp:104: solve()]
>
> Remember, this is with a PETSc that does not use the Fortran BLAS libs, but
> uses a downloaded c-blas-lapack. I haven't figured out what that actually
> means, but it does seem to have a profound impact on the sw stack.

I also use the C versions so that shouldn't matter.

Can you check if you solve the correct system by printing out the
matrix and the vector? (A.disp(); b.disp();) That would show if the
problem is in building the system or in PETSc (or perhaps calling
PETSc correctly).

Can you run any of the demos in PETSc itself?
 
> Let me rebuild with a PETSc that uses the Fortran BLAS and see what I get:
> ................
> Arggggh, boogers, now I get the same error message with that version as
> well..... so my comment above is not proven yet. I need to figure out what
> all these messages imply and how to root cause them. Anyone have experience
> with that?
> 
> Theo
> 
> P.S. I see that the build process is moving further away from what is
> customary in the Windows world. I need to redo most of the build process
> anyway to get it included in a .NET world, so I don't know yet if this is
> problematic, but tricks like `dolfin-config --cflags` are just not very
> Windows friendly, nor are lots of shell scripted conditionals or pre and
> post build file moves like the "make install" target.
> 
>   I am a big fan of the jam/bjam cross platform build tools, mostly because
> I think Perforce and BOOST are well done, and these tools are very light
> weight and comprehend the windows world natively. Something that autoconf
> just doesn't. So for now, I'll hold of judgment until I get more familiar
> with the environment.

We modified the build process for DOLFIN 0.5.11 to follow the (Unix)
standard better. Before, we had sort of a home-grown solution, where
the demos could be compiled against the library without needing to
install the library. The new version requires the library to be
installed (make install) to compile the demos. This is the standard
that 99% of all Unix libraries follow: headers installed under
$prefix/include and libraries under $prefix/lib.

Then there is the problem of compiling and linking against a big
modular library consisting of a large number of smaller
libraries. Getting all the libraries -lfoo -lbar etc and in the
correct order can be difficult, especially if the library (in this
case DOLFIN) uses stuff from other libraries (like PETSc). Then these
libraries must also be listed.

To make life easier for a user, the big library must thus communicate
in some way the correct libraries to the user. We do this through the
dolfin-config script, which is automatically generated and installed
during a build of DOLFIN. This may not be a standard approach, but it
is common enough and it's modelled after what GTK and LibXML2 does.

PETSc uses a different approach and forces you to extract the includes
and libs through a Makefiles:

PETSC_CFLAGS=`make -s -C $PETSC_DIR getincludedirs PETSC_DIR=$PETSC_DIR`
PETSC_LIBS=`make -s -C $PETSC_DIR getlinklibs PETSC_DIR=$PETSC_DIR`

So, I wouldn't say dolfin-config is a trick. It's something I consider
to be close to standard and it's there to help the user. If you can
get your programs to compile in another way, you don't have to use it.

/Anders