Aha! Right, I had used an old one of mine (libMesh-0.7.0+) as a basis, but then got the error it didn't recognize the libmesh-0.7, so I switched it to the Deal one. But libMesh-0.7.2 works! I get a different error, but it at least seems to read it! =)
Is there a good recent write up of the different formats? The one that keeps coming up in google searches and from the main libmesh wiki page is from 2005. Thanks! Andrea On Fri, Oct 7, 2011 at 12:04 PM, Roy Stogner <[email protected]> wrote: > > This looks kind of like a hybrid between the "DEAL 003:003" headered > file format used in our lshaped.xda example and the "libMesh-0.7.0+" > headered file format that we wrote (up until making a change to > "libMesh-0.7.2" recently to accomodate per-subdomain variable > metadata). > > And while we can read one or the other, I don't think we can read > anything "in-between". > --- > Roy > > On Fri, 7 Oct 2011, Andrea Hawkins-Daarud wrote: > >> Hello- >> >> I'm currently trying to write a xda file given a set of nodes and >> element connectivities. I'm not positive I have the header right (it's >> trying to mimic the l-shaped.xda in the examples), but given the >> following input file >> >> DEAL 003:003 >> 1 # number of elements >> 4 # number of nodes >> . # boundary conditions >> , #subdomain id specification file >> n/a #processor id specification file >> n/a # p-level specification file >> 1 #n_elem at level 0 >> 5 0 1 4 3 2 >> 0 0 0 >> 0 1 0 >> 1 1 0 >> 1 0 0 >> >> the mesh read functionality dies with the following error: >> >> Reading in and building the mesh >> Assertion `mp_in.good()' failed. >> [0] src/mesh/xdr_mesh.C, line 74, compiled Oct 7 2011 at 11:37:22 >> terminate called after throwing an instance of 'libMesh::LogicError' >> what(): Error in libMesh internal logic >> Aborted >> >> with the traceback showing >> Stack frames: 10 >> 0: libMesh::print_trace(std::ostream&) >> 1: libMesh::libmesh_terminate_handler() >> 2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb9926) [0x7fbdc85ef926] >> 3: /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb9953) [0x7fbdc85ef953] >> 4: /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb9a5e) [0x7fbdc85efa5e] >> 5: libMesh::XdrMESH::header(libMesh::XdrMHEAD*) >> 6: libMesh::LegacyXdrIO::read_mesh(std::string const&, >> libMesh::LegacyXdrIO::FileFormat, libMesh::MeshData*) >> 7: libMesh::LegacyXdrIO::read_ascii(std::string const&, >> libMesh::LegacyXdrIO::FileFormat) >> 8: libMesh::LegacyXdrIO::read(std::string const&) >> 9: libMesh::XdrIO::read(std::string const&) >> >> >> Did I just really screw up the xda file? Also, worth noting, the xda >> file was written with Matlab. Does matlab format files it writes in a >> weird way because I'm also having trouble with an ASCII vtk file (from >> matlab) and paraview? Note, what is above was copy and pasted from a >> vim instance. >> >> Thanks! >> Andrea >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2dcopy2 >> _______________________________________________ >> Libmesh-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> >> > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
