On Fri, Aug 1, 2014 at 11:25 AM, David Knezevic
<dkneze...@seas.harvard.edu> wrote:
>
>>> 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?
I don't think we can, based on the header of your Exodus file, which says:
int connect1(num_el_in_blk1, num_nod_per_el1) ;
connect1:elem_type = "TRI3" ;
I've seen this problem with SHELL4 in the past (we don't support
SHELL4 for the same reason) but I didn't think it was the same issue
because your file says it has TRI3's.
--
John
------------------------------------------------------------------------------
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
