On Mon, 21 Sep 2009, Jan Biermann wrote:
> Thanks for getting that fixed so quick!
No problem - but if you could do a bit of 0.6.3->SVN head regression
testing, I'd appreciate it. I got everything compiling again, sure,
but I don't currently have a complex-valued Petsc build available to
test everything with, nor any real complex-dependent applications to
The compile-time problems shouldn't be repeated, at least. I'll be
sure to add a --enable-complex test run when we expand our BuildBot
configuration next month. That way the next time someone breaks
complex arithmetic support in the svn head we'll catch it and fix it
right away, not just when we prepare for a release or when a user of
it svn updates.
> Roy Stogner schrieb:
>> On Thu, 17 Sep 2009, Jan Biermann wrote:
>>> I have been using an old libmesh version until now because I didn't want
>>> to bother changing all my application code. But now the problem size
>>> becomes this big that I cannot get around the latest version (because I
>>> think you changed the mesh class for parallel computing, so not storing
>>> the entire mesh on every processor,right?)
>> No permanent change to the mesh class yet - the ParallelMesh does what
>> you're talking about, but it still has some bugs with adaptive
>> coarsening, and no schedule for when they might be fixed. If you're
>> not doing any adaptive coarsening then you can --enable-parmesh at
>> configure time to use it.
>> There is a permanent change in the SVN head to use "ghosted" instead
>> of global PETSc vectors for many applications, which should save you a
>> little RAM.
>>> But now that I want to install the latest version, I ran into some bugs
>>> where the code didn't want to compile for complex numbers but after fixing
>> Thanks for letting us know! I haven't tried --enable-complex on the
>> SVN head in a long while.
>> I've added a libmesh_not_implemented() to the Ensight output if people
>> try to write with LIBMESH_USE_COMPLEX_NUMBERS, and made a few changes
>> to make sure it compiles. EnsightIO is a relatively new class from
>> Ben Kirk; I'm not familiar with the format and I'm not sure when/if
>> we'll be able to add actual complex-number support to it.
>> I've changed fabs() to std::abs() in Derek's new NumericVector::abs()
>> functions, and v*v to libmesh_norm(v) in
>> Trilinos seems pretty incompatible with complex numbers unless there's
>> an EpetraVector option I'm missing, so I've changed our configure.in
>> to disable Trilinos support whenever complex-number support is
>>> I finally get an error that I don't understand:
>> We use Parallel::datatype<> to wrap a bunch of MPI calls into a much
>> nicer interface. Unfortunately, it looks like MPI_DOUBLE_COMPLEX is a
>> Fortran-only datatype, and MPI::DOUBLE_COMPLEX requires a C++ MPI2
>> standard whereas we've been trying to stay C MPI1 compatible, so we
>> have to write special template definition for Parallel operations
>> on std::complex data. If allgather code ever tried to use a
>> non-special template definition, this is the error you'd see.
>> Ben added a new Parallel::allgather() argument a while back, but he
>> did it properly on both the regular and complex versions - I'm not
>> sure what the problem here could be. I'll keep looking.