I use Exodus to read in the mesh and Nemesis to write the output data.

I have long been using ParallelMesh with AMR without problems, but lately my 
ParallelMesh with Tet4 elements, refined through a couple of AMR steps, has 
been throwing exceptions. But that is a matter of separate discussion. 

For now, I have replaced the ParallelMesh with a SerialMesh and am trying to do 
the same thing: read in using ExodusII_IO, AMR, and the output using Nemesis. 
All of this is on two processors. 

Now, in the last step, I am getting the error that I described in my previous 
email, which I am trying to decipher. 

Manav


On May 10, 2014, at 11:00 AM, Derek Gaston <fried...@gmail.com> wrote:

> I'm not sure how (or why?) you're using SerialMesh with Nemesis... Nemesis is 
> for reading Parallel Meshes...
> 
> What exactly are you trying to do here?
> 
> Derek
> 
> 
> 
> On Sat, May 10, 2014 at 8:52 AM, Manav Bhatia <bhatiama...@gmail.com> wrote:
> Hi,
> 
>       I am curious if SerialMesh with AMR uses the RemoteElem.  In the 
> following function (from elem.C), I have marked the lines of interest with 
> “****”.
> 
>       This method gets called by line 2180 of nemesis_io_helper.C, which 
> wants to find active elements with a common side, but also on the local 
> processor. But, the method in elem.C does not seem to make a distinction 
> about elements that may have a different pid assigned, but may not be remote 
> elems. Elem::is_remote() is false by default.
> 
>       Eventually, error on line 2211 of nemesis_io_helper.C is thrown.
> 
>       Maybe it would make sense to add a check for (processor_id != 
> this->processor_id) in Elem::is_remote()? Any thoughts?
> 
> Thanks,
> Manav
> 
> 
> void Elem::active_family_tree_by_side (std::vector<const Elem*>& family,
>                                        const unsigned int s,
>                                        const bool reset) const
> {
>   // The "family tree" doesn't include subactive elements
>   libmesh_assert(!this->subactive());
> 
>   // Clear the vector if the flag reset tells us to.
>   if (reset)
>     family.clear();
> 
>   libmesh_assert_less (s, this->n_sides());
> 
>   // Add an active element to the family tree.
>   if (this->active())
>     family.push_back(this);
> 
>   // Or recurse into an ancestor element's children.
>   // Do not clear the vector any more.
>   else
>     for (unsigned int c=0; c<this->n_children(); c++)
>   **** if (!this->child(c)->is_remote() && this->is_child_on_side(c, s))  
> *****
>         this->child(c)->active_family_tree_by_side (family, s, false);
> }
> 
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Libmesh-users mailing list
> Libmesh-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
> 

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to