>> So it seems here that the problem is with the mesh that CUBIT is generating, >> do you agree? I agree that "side_ss1 = 5, 5, 5" doesn't make any sense, so >> I'm not sure what's going on there. > Definitely agree. > > We could possibly put in some kind of workaround if you can figure out > the "logic" behind these sideset IDs coming from Cubit. > > (If we mod it by n_sides or something, do we get the right ID?) >
It looks like the issue is that the element type in Cubit is TRISHELL3, which I guess is what Cubit gives you by default if you have TRI3 elements in 3D. Also, that's presumably explains why it had a side ID of 5. Can we detect if the element type in the exo file is TRI3 vs TRISHELL3? If so, it might be good to throw an error if TRISHELL3 is detected, instead of reading it in as TRI3? (Though I guess we get an error in debug mode already, as you pointed out) David ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
