On Tue, 3 Apr 2012, Derek Gaston wrote:
Wow - _3_. That is crazy!
An assert is a good idea for now... maybe add this to the list of interfaces to
be deprecated? It would be easy to make a stub version that kept
the current calling sequence and had a libmesh_deprecated() call in it... then
Wow - _3_. That is crazy!
An assert is a good idea for now... maybe add this to the list of
interfaces to be deprecated? It would be easy to make a stub version that
kept the current calling sequence and had a libmesh_deprecated() call in
it... then called the new version...
Derek
On Tue, Apr
On 4/3/12 3:28 PM, "Roy Stogner" wrote:
>> Seems like we should just get the dimension of the element from
>> elem->dim()
>> That's what gave me pause in the first place...
>
> We ought to at least be asserting they're equal, huh. I might add
> that after I'm done putting together 0.7.3
On Tue, 3 Apr 2012, Derek Gaston wrote:
> Then why are we passing it in?
Hell if I know. "svn blame" says that the API dates from revision
*3*, so while I can confidently answer "we're passing it in for
backwards compatibility" now, I can't say whether it started as a
design mistake or just a n
Then why are we passing it in? Seems like we should just get the dimension
of the element from elem->dim()
That's what gave me pause in the first place...
Derek
On Tue, Apr 3, 2012 at 2:21 PM, Roy Stogner wrote:
>
> On Tue, 3 Apr 2012, Derek Gaston wrote:
>
> FEInterface::inverse_map() ta
On Tue, 3 Apr 2012, Derek Gaston wrote:
FEInterface::inverse_map() takes a "dimension" parameter what
dimension is that? Is that the dimension of the element or the
dimension of the mesh?
Looks like the dimension of the element. dim just gets used in a
switch statement to decide which F
FEInterface::inverse_map() takes a "dimension" parameter what dimension
is that? Is that the dimension of the element or the dimension of the mesh?
ie... if I have a 1D element in 3D space what dimension do I pass in to
inverse_map()?
Derek
---
