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_ time it tries to refine.  I have
compiled in debug mode with tracefiles on.  Here is the error... and
the tracefile is below:

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
p1_97600:  p4_error: interrupt SIGx: 6


#########

Stack frames: 10
0: 0   ex10-dbg                            0x0008c489 _Z11print_traceRSo + 33
1: 1   ex10-dbg                            0x004d8987
_ZNK12ParallelMesh40libmesh_assert_valid_parallel_object_idsI4ElemEEvRK9mapvectorIPT_E
+ 4829
2: 2   ex10-dbg                            0x004bfe8f
_ZNK12ParallelMesh33libmesh_assert_valid_parallel_idsEv + 27
3: 3   ex10-dbg                            0x004c367a
_ZN12ParallelMesh27renumber_nodes_and_elementsEv + 28
4: 4   ex10-dbg                            0x003df05e
_ZNK17MeshCommunication22delete_remote_elementsER12ParallelMesh + 3542
5: 5   ex10-dbg                            0x004c19d4
_ZN12ParallelMesh22delete_remote_elementsEv + 64
6: 6   ex10-dbg                            0x003dd763
_ZN8MeshBase15prepare_for_useEb + 105
7: 7   ex10-dbg                            0x00485345
_ZN14MeshRefinement27refine_and_coarsen_elementsEb + 10839
8: 8   ex10-dbg                            0x000039a6 main + 6284
9: 9   ex10-dbg                            0x00001a92 start + 54



Derek

On Mon, Jun 23, 2008 at 4:56 PM, Derek Gaston <[EMAIL PROTECTED]> wrote:
> 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 instance of 'libMesh::LogicError'
>  what():  Error in libMesh internal logic
> #####
>
> I'm working on a stack trace - I'll send that when I get it.
>
> Secondly, I did some testing with example 10.  It looks like if you
> turn coarsening off, it runs fine in parallel.  However, if you change
> from refine_and_coarsen_elements() to uniformly_refine() it fails....
> so there is something odd about uniformly_refine()....
>
> More info when I get it.
>
> Derek
>
> On Mon, Jun 23, 2008 at 4:34 PM, Derek Gaston <[EMAIL PROTECTED]> wrote:
>> 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 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?  Or is it doing that block chunked I/O
>>> that Ben put into the code?  Somehow it's getting all of the elements
>>> into that Exodus file....
>>>
>>> Here's what I'm thinking I'd like to do: Let's say I have a coarse
>>> mesh in exodus format (all in one file) to start with.  I want to read
>>> this in (preferably in parallel, even if that means I need to do an
>>> offline filetype conversion first) then uniformly refine it to
>>> saturate all available memory... compute a solution... then write it
>>> out (hopefully a parallel write... but doesn't have to be).
>>>
>>> Is that doable now?
>>>
>>> Also, how much work do you think it would be to be able to read (and
>>> write) decomposed Exodus files?  The writing part sounds especially
>>> easy (I believe that decomposed Exodus files are just regular exodus
>>> files).
>>>
>>> The idea is that I'm going to be running a simulation that uses
>>> approximately 40 million elements on about 1,000 procs.  What I do
>>> doesn't have to be pretty... it just needs to work.  If the mesh I run
>>> on is just a cube... so be it... if it looks like a cylinder that
>>> would be a huge bonus.  I am open to all ideas.
>>>
>>> Thanks!
>>> Derek
>>>
>>
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to