On Wed, 25 Jun 2008, Benjamin Kirk wrote:
> It can't be a bug in my redistribution, since it is never called!
> So obviously that is the problem. Repartitioning is performed, but the mesh
> is not redistributed. This causes Roy's assertion above to break.
Oh, that would definitely break things
Assertion `min_procid != libMesh::processor_id() || obj' failed.
[1] src/mesh/parallel_mesh.C, line 546, compiled Jun 23 2008 at 17:21:20
terminate called after throwing an instance of 'libMesh::LogicError'
what(): Error in libMesh internal logic
> In case my sparse terse comments in the code a
> But as a temporary workaround, would you go to partitioner.C and
> uncomment the "don't repartition in parallel" code on lines 47-48?
> I'm not yet sure whether there's a bug in Ben's redistribution code or
> whether that's just triggering a bug in my core or refinement code,
> but I at least can
On Jun 23, 2008, at 8:55 PM, Roy Stogner wrote:
> But as a temporary workaround, would you go to partitioner.C and
> uncomment the "don't repartition in parallel" code on lines 47-48?
That does seem to work for now. Is there a way to just turn off
repartitioning altogether? I don't need it a
On Mon, 23 Jun 2008, Derek Gaston wrote:
> Spoke too soon. It turns out that ex10 is failing with parallel mesh
> and refinement. To reproduce edit ex10.C and comment out the
> coarsen_fraction() and max_h_level() calls. Now compile and run with:
>
> mpirun -np 3 ./ex10-opt -n_timesteps 25 -in
The I/O is only parallelized for writing of XDA/XDR files at present. It is
blocked, and it is performed processor-wise. So you can write a serialized
mesh file from a parallel, distributed mesh. For all other mesh types the mesh
is serialized to all processors, and processor 0 performs the
Spoke too soon. It turns out that ex10 is failing with parallel mesh
and refinement. To reproduce edit ex10.C and comment out the
coarsen_fraction() and max_h_level() calls. Now compile and run with:
mpirun -np 3 ./ex10-opt -n_timesteps 25 -init_timestep 0
It fails for me during the _second_ t
A little more info.
Firstly, I recompiled in debug mode and I get this out when it tries
to uniformly refine:
#
Assertion `min_procid != libMesh::processor_id() || obj' failed.
[3] src/mesh/parallel_mesh.C, line 546, compiled Jun 23 2008 at 16:41:23
terminate called after throwing an instanc
Hmmm... uniformly refining a ParallelMesh that has had
delete_remote_elements() called on it is giving me a segfault. Is it
supposed to work?
Derek
On Mon, Jun 23, 2008 at 4:15 PM, Derek Gaston <[EMAIL PROTECTED]> wrote:
> Guys,
>
> What do I need to do to actually use ParallelMesh with parallel
Guys,
What do I need to do to actually use ParallelMesh with parallel I/O?
So far I've done --enable-parmesh and used delete_nonlocal_elements
(after doing a build_cube)... then I've computed a solution and
written a single exodus file. In writing that Exodus file is it
serializing the mesh first
10 matches
Mail list logo
