Closed dknez closed 7 years ago
On Fri, Oct 13, 2017 at 9:14 AM, David Knezevic notifications@github.com wrote:
I have a simple exo 1D mesh with 6 elements that hits an assertion ("Assertion `_nodes[i]' failed.") when I try to read it in with mesh.read.
I've pasted the "ncdump" of the mesh below. Note that I can open the mesh in paraview with no issue, so I think the mesh is valid.
netcdf test_mesh { dimensions: len_line = 81 ; time_step = 1 ; num_qa_rec = 1 ; four = 4 ; len_string = 33 ; num_dim = 3 ; num_el_blk = 1 ; num_elem = 6 ; num_el_in_blk1 = 6 ; num_nod_per_el1 = 2 ; num_nodes = 7 ; variables: double time_whole(time_step) ; char qa_records(num_qa_rec, four, len_string) ; char coor_names(num_dim, len_string) ; char eb_names(num_el_blk, len_string) ; int elem_map(num_elem) ; int eb_status(num_el_blk) ; int eb_prop1(num_el_blk) ; eb_prop1:name = "ID" ; int connect1(num_el_in_blk1, num_nod_per_el1) ; connect1:elem_type = "BAR3" ; double coordx(num_nodes) ; double coordy(num_nodes) ; double coordz(num_nodes) ;
// global attributes: :api_version = 5.22 ; :version = 5.22 ; :floating_point_word_size = 8 ; :file_size = 1 ; :title = "mesh.exo" ; data:
time_whole = 0 ;
qa_records = "test", "1.0", "2017-10-11 11:16", "" ;
coor_names = "x", "y", "z" ;
eb_names = "" ;
elem_map = 1, 2, 3, 4, 5, 6 ;
eb_status = 1 ;
eb_prop1 = 1 ;
connect1 = 7, 5, 2, 4, 5, 3, 1, 2, 6, 7, 3, 1 ;
coordx = -588, -588, -588, -588, -588, -588, -588 ;
coordy = -342, -342, -342, -342, -342, -342, -342 ;
coordz = -39.3333333333333, -22.6666666666667, -56, -6, -72.6666666666667, -106, -89.3333333333333 ;
Hmm... BAR3 is treated as an EDGE3, should the connectivity array therefore have 3 entries (rather than the 2 shown) for each element?
-- John
What's the stack trace of the assertion?
Can you put the mesh itself online?
John: Good point! I guess the mesh is invalid.
Roy: I can email you the exo mesh if you like? I don't think I can attach it here, as far as I know.
If John's already hit on the right diagnosis then never mind. I was thinking more along the lines of "set up a branch which tries to read the mesh and fails", though, for future reference.
Yep, agreed. Thanks for the help!
It would be nice if we provided a better error message than just an assertion...
Also I'm curious how this mesh was created? It may be that we assumed BAR3 elements should be equivalent to EDGE3s but that's not the case?
It was a mesh made by an in-house tool (extracting a 1D mesh from a 3D mesh), so I consider it a bug in that tool that it created a mesh without enough nodes.
But still, I agree that a better error message would be helpful. It wasn't clear to me what was wrong based on the assertion. Also, in opt mode it was a segfault.
It would be nice if we provided a better error message than just an assertion...
IMHO it's actually a bug in libMesh that we use libmesh_assert rather than full libmesh_error in our I/O classes.
Assertions are for situations where, if we've written our code right, we know something should be true, so it's okay to skip double-checking in opt mode.
But we never know that a mesh file is perfectly formatted; who knows where it came from? I'm not expecting virus writers to start trying to infect computers via ExodusII malware any time soon, I admit, but it would be nice if doing so was impossible. We ought not to be worrying too much about performance in this context either, since the cost of hitting the file system will almost always vastly exceed the const of sanity-checking what we find there.
:+1:
IMHO it's actually a bug in libMesh that we use libmesh_assert rather than full libmesh_error in our I/O classes.
+1
I have a simple exo 1D mesh with 6 elements that hits an assertion ("Assertion `_nodes[i]' failed.") when I try to read it in with mesh.read.
I've pasted the "ncdump" of the mesh below. Note that I can open the mesh in paraview with no issue, so I think the mesh is valid.