On May 16, 2012, at 4:15 PM, Roy Stogner wrote:
> On Wed, 16 May 2012, Derek Gaston wrote:
>
>> Why don't we _only_ renumber nodes and elements that are "beyond"
>> the initial mesh. What I mean by that is this:
>>
>> a: Read mesh containing elements 4,3,1,2 (out of order on purpose)
>> b: Refi
> Ok - I'm with you on thisŠ. but I think it will be user selectable. i.e
> if you pass in "true" to prepare_for_use() there won't be any renumbering of
> the initial mesh _ever_ (With SerialMeshŠ ParallelMesh can do what it needs
> to). It is a "use at your own risk" kind of featureŠ
>
> Th
On May 17, 2012, at 8:05 AM, Kirk, Benjamin (JSC-EG311) wrote:
> So if we went along these lines then perhaps a callback would be needed when
> a mesh is read to store the Node::Identifiers based on user-requested
> *original* node numbers, but then we'd be free to do whatever to them.
I like it.
>> So if we went along these lines then perhaps a callback would be needed when
>> a mesh is read to store the Node::Identifiers based on user-requested
>> *original* node numbers, but then we'd be free to do whatever to them.
>
> I like it.
>
> So you are saying we can basically store an arbitra
On Thu, 17 May 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Not necessarily - it may return only constant-type objects to the user. One
> idea is that it would just return the address of the node wrapped in an
> object that clarifies the intent. So in that case there is no more memory
> required i
On Thu, 17 May 2012, Kirk, Benjamin (JSC-EG311) wrote:
> How far do we need to go with supporing and maintaining an arbitrary initial
> numbering? I ask because it is perfectly conceivable that an input mesh
> might have only three nodes, numbered 100, 200, 300, and that means
> something to the
>> Not necessarily - it may return only constant-type objects to the user. One
>> idea is that it would just return the address of the node wrapped in an
>> object that clarifies the intent. So in that case there is no more memory
>> required in the underlying mesh than currently required.
>
> T
On Thu, 17 May 2012, Derek Gaston wrote:
On May 16, 2012, at 4:15 PM, Roy Stogner wrote:
On Wed, 16 May 2012, Derek Gaston wrote:
Why don't we _only_ renumber nodes and elements that are "beyond"
the initial mesh. What I mean by that is this:
a: Read mesh containing elements 4,3,1,2 (out
On May 17, 2012, at 8:41 AM, Kirk, Benjamin (JSC-EG311) wrote:
> Oh absolutely - more state would need to be handled when shipping objects
> around. I'm not too worried about that though - I'll try to think of a fix
> for that.
I guess this would be true only for ParallelMesh… because with Seria
On Thu, 17 May 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Oh absolutely - more state would need to be handled when shipping objects
> around. I'm not too worried about that though - I'll try to think of a fix
> for that.
Shouldn't the fix just be "state = object->id()"? If we're
maintaining ini
On May 17, 2012, at 8:42 AM, Roy Stogner wrote:
> SerialMesh::renumber_nodes_and_elements() "renumbers" all elements,
> true, but as long as they start out in proper order
> (_elements[i]->id() == i) they should stay the same up until the first
> hole is reached, which shouldn't happen until after
On Thu, 17 May 2012, Derek Gaston wrote:
You're right about Elements, Roy… I hadn't notice that. But for
nodes that's not the case (and that's where we're seeing problems).
The issue happens when the node numbering for an element in a read
in mesh doesn't match the libMesh ordering for nodes
Yep - I think that would do it!
Derek
On May 17, 2012, at 9:28 AM, Roy Stogner wrote:
>
> On Thu, 17 May 2012, Derek Gaston wrote:
>
>> You're right about Elements, Roy… I hadn't notice that. But for
>> nodes that's not the case (and that's where we're seeing problems).
>>
>> The issue happe
13 matches
Mail list logo
