On Mon, 2 Mar 2009, Tim Kroeger wrote:
Update: It doesn't crash any more. With the patch that I sent you in the
previous mail, it seems to work.
That's interesting. Did you ever track down the source of the
problem? The patch you provided looks like it could have fixed some
inaccuracy bugs with ghosted vectors, but I can't see what code path
in the old code might have triggered an actual crash.
The patch looks good on first read and run through. Could use a
little refactoring, but so could our whole PetscVector interface to
begin with. I'll commit it some time this week if I don't find any
subtle problems first.
Well, at least the first 8 time steps of my application do the same
as they did without the ghost dofs. And the memory requirements are
less than 50% of before (on 8 processors).
Really? That's very good to hear. Is that with SerialMesh?
However, (a) the results do not *exactly* coincide with the previous ones;
that it, I get e.g. a residual norm of 1.16562e-08 instead of 1.16561e-08
after 608 linear iterations (although using the same number of processors),
Hmm... maybe we still have some inaccuracy bugs in there? There
aren't any other confounding changes? If you configure using
--disable-ghosted you get back the old results?
and (b) I had to add a.close() between a=b and a.scale(), where a and b are
*System::solution of two different systems.
The systems are identical? Same mesh, same variable types added in
the same order?
Both facts surprise me. In particular, (b) surprises me for two reasons,
that is (b1) PetscVector::operator=(const PetscVector&) should not require
closing the vector afterwards,
I wouldn't think so either, but I'm not sure how best to divine PETSc
standards there. The VecCopy man page doesn't mention needing
VecAssembly afterwards, but then again neither do the VecSet* pages;
there's just the brief discussion in the user's manual.
and (b2) I wonder whether (and, if yes, why) you are using ghosted
vectors for System::solution; I thought you were using them only for
System::current_local_solution.
No, I'm not. I want to use ghosted vectors for System::solution (and
get rid of current_local_solution entirely) in the long run, but scan
for PARALLEL in system.C; there shouldn't be any ghosting there yet...
unless our massive overloading of init() is backfiring somehow.
What do you think? Does this look like more errors or not?
I don't know what to think yet... but I actually can't replicate
problem (b) myself with the attached vectest.C - I assume it bombs out
for you with the usual PETSc "object in wrong state" error?
---
Roy
// C++ include files that we need
#include <iostream>
#include <cmath>
// Basic include file needed for the mesh functionality.
#include "libmesh.h"
#include "numeric_vector.h"
const unsigned int dofsperproc = 1;
int main (int argc, char** argv)
{
// Initialize libMesh.
LibMeshInit init (argc, argv);
AutoPtr<NumericVector<Number> > vec1 = NumericVector<Number>::build();
AutoPtr<NumericVector<Number> > vec2 = NumericVector<Number>::build();
vec1->init(libMesh::n_processors() * dofsperproc, dofsperproc, false,
PARALLEL);
vec2->init(libMesh::n_processors() * dofsperproc, dofsperproc, false,
PARALLEL);
*vec1 = *vec2;
vec1->scale(1.0);
return 0;
}
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
