>> 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
On Fri, Aug 1, 2014 at 11:25 AM, David Knezevic
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 possi
>> 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
On Fri, Aug 1, 2014 at 11:06 AM, David Knezevic
wrote:
>
> On 08/01/2014 12:50 PM, John Peterson wrote:
>>
>> On Fri, Aug 1, 2014 at 10:28 AM, John Peterson
>> wrote:
>>>
>>> What I don't understand is why your original exodus file, which also
>>> has num_dim=3, actually displays correctly in par
On Fri, Aug 1, 2014 at 10:50 AM, John Peterson wrote:
> On Fri, Aug 1, 2014 at 10:28 AM, John Peterson wrote:
>>
>> What I don't understand is why your original exodus file, which also
>> has num_dim=3, actually displays correctly in paraview! This might
>> take a big longer to track down...
>
>
On Fri, Aug 1, 2014 at 10:28 AM, John Peterson wrote:
>
> What I don't understand is why your original exodus file, which also
> has num_dim=3, actually displays correctly in paraview! This might
> take a big longer to track down...
Here's something... your original file references side "5" of t
On Fri, Aug 1, 2014 at 9:27 AM, John Peterson wrote:
>
> Oh wait, on closer inspection elem_map is the identity. So, not sure
> what the problem might be...
Are you seeing something like the attached image when you try to view
the sidesets in paraview?
I have seen this issue before, and at the
On Fri, Aug 1, 2014 at 9:25 AM, John Peterson wrote:
> On Fri, Aug 1, 2014 at 9:17 AM, David Knezevic
> wrote:
>> Hi All,
>>
>> I've attached a simple 2D mesh with TRI3 elements that was made in CUBIT. It
>> has four sidesets (one for each boundary), and when I view the mesh in CUBIT
>> the sides
On Fri, Aug 1, 2014 at 9:17 AM, David Knezevic
wrote:
> Hi All,
>
> I've attached a simple 2D mesh with TRI3 elements that was made in CUBIT. It
> has four sidesets (one for each boundary), and when I view the mesh in CUBIT
> the sidesets look fine.
>
> But when I read this mesh into libMesh, it m
Hi All,
I've attached a simple 2D mesh with TRI3 elements that was made in
CUBIT. It has four sidesets (one for each boundary), and when I view the
mesh in CUBIT the sidesets look fine.
But when I read this mesh into libMesh, it mixes up the sidesets so that
the boundary IDs are on internal
10 matches
Mail list logo
