Probably worth a libmesh_assert() to make sure we are still in some assumed range??
-Ben ----- Original Message ----- From: Rahul Sampath <[email protected]> To: Derek Gaston <[email protected]> Cc: [email protected] <[email protected]> Sent: Tue Feb 09 13:52:55 2010 Subject: Re: [Libmesh-users] Bug in ExodusII_IO::read Thank you. So to fix this is it sufficient to simply replace the line #227: mesh.boundary_info->add_node(node_list[node], nodeset_id); with: mesh.boundary_info->add_node((node_list[node] - 1), nodeset_id); in the file exodusII_io.C Regards, Rahul On Tue, Feb 9, 2010 at 2:21 PM, Derek Gaston <[email protected]> wrote: > Whoops! Good catch!! I had fixed this in a local version... but it never > made it back out to the main repo. It's committed now. > > Derek > > On Feb 9, 2010, at 11:38 AM, Rahul Sampath wrote: > >> Hi: >> >> I am sorry if I was not clear in my earlier e-mail. I generated a >> simple HEX8 mesh using Cubit. The geometry is a simple cube and I >> specify a simple node-based boundary condition on all surfaces (all >> displacements are 0.0 on all surfaces). I have attached the sample >> Cubit file, the mesh exported in ExodusII format and the ASCII form of >> the Exodus file generated using the publicly available ncdump program. >> The Exodus format uses a 1-based numbering for its nodes. Libmesh uses >> a 0-based numbering. So in the Libmesh function ExodusII_IO::read() >> you have to read the node ids (for element-to-node connectivities and >> boundary sets) from the exodus file in 1-based numbering subtract 1 >> from it and store it in the Libmesh data stuctures. The problem is >> that you are subtracting 1 only when reading the element-to-node map >> and not when reading node-based boundary conditions. >> >> The following is taken from the Libmesh source code: >> >> In the function ExodusII_IO::read() >> >> // Read nodeset info >> 00215 { >> 00216 exio_helper.read_nodeset_info(); >> 00217 >> 00218 for (int nodeset=0; nodeset<exio_helper.get_num_node_sets(); >> nodeset++) >> 00219 { >> 00220 int nodeset_id = exio_helper.get_nodeset_id(nodeset); >> 00221 >> 00222 exio_helper.read_nodeset(nodeset); >> 00223 >> 00224 const std::vector<int>& node_list = >> exio_helper.get_node_list(); >> 00225 >> 00226 for(unsigned int node=0; node<node_list.size(); node++) >> 00227 mesh.boundary_info->add_node(node_list[node], nodeset_id); >> 00228 } >> 00229 } >> 00230 >> >> In Line 222, exio_helper::node_list is populated from the input file >> and this uses 1-based numbering. In line 227 this is passed to the >> function boundary_info->add_node which expects 0-based numbering. >> As a result, when boundary_info->add_node calls SerialMesh::node_ptr >> the following assertion failed error is thrown: "i < this->n_nodes() " >> at line 108 of serial_mesh.C >> >> Could you kindly take a look into this problem. >> >> Thanks. >> >> Regards, >> >> Rahul >> >> On Mon, Feb 8, 2010 at 3:26 PM, Derek Gaston <[email protected]> wrote: >>> I don't think there is a bug with ExodusII_IO. Just make sure that your >>> mesh doesn't contain any blocks, sidesets or nodesets that are _0_. >>> >>> This is done on purpose so the numbering matches what gets generated with >>> Cubit. >>> >>> What are you using to generate your meshes? >>> >>> Derek >>> >>> This is >>> On Feb 8, 2010, at 12:14 PM, Rahul Sampath wrote: >>> >>>> Hi: >>>> >>>> I believe that there is a bug in the function ExodusII_IO::read(). I >>>> have attached a sample program and the input file to demonstrate this. >>>> The ASCII version of the exodus file was generated using the tool >>>> ncdump. You can see the ExodusII uses a 1-based numbering scheme. >>>> However, when trying to add nodes to boundary_info using nodesets the >>>> ExodusII_IO::read() function assumes a 0-based numbering scheme. As a >>>> result an assertion error is thrown at line 108 in serial_mesh.C in >>>> function SerialMesh::node_ptr, which is called from >>>> BoundaryInfo::add_node, which is in turn called from >>>> ExodusII_IO::read. >>>> >>>> Regards, >>>> >>>> Rahul >>>> <cubeMesh.txt>------------------------------------------------------------------------------ >>>> The Planet: dedicated and managed hosting, cloud storage, colocation >>>> Stay online with enterprise data centers and the best network in the >>>> business >>>> Choose flexible plans and management services without long-term contracts >>>> Personal 24x7 support from experience hosting pros just a phone call away. >>>> http://p.sf.net/sfu/theplanet-com_______________________________________________ >>>> Libmesh-users mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>> >>> >> <sampleCube.txt><sampleCube.e><testReadMesh.cc><sampleCube.cub> > > ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
