On Thu, May 31, 2012 at 12:01 PM, John Peterson wrote:
> Has anything else changed since our last discussion yesterday?
>
No, I'm just being paranoid using my commit access on trunk and potentially
pissing people off that can revoke it. :)
> Is it possible for you to piggy-back on the PECOS bui
On Thu, 31 May 2012, John Peterson wrote:
> On Wed, May 30, 2012 at 9:40 PM, Paul T. Bauman wrote:
>> Updated patch/files here: http://users.ices.utexas.edu/~pbauman/fe_abstract
>>
>> I'd be grateful if someone would give them one more go before I commit.
>
> Has anything else changed since our
On Wed, May 30, 2012 at 9:40 PM, Paul T. Bauman wrote:
> Updated patch/files here: http://users.ices.utexas.edu/~pbauman/fe_abstract
>
> I'd be grateful if someone would give them one more go before I commit.
Has anything else changed since our last discussion yesterday?
Is it possible for you t
Updated patch/files here: http://users.ices.utexas.edu/~pbauman/fe_abstract
I'd be grateful if someone would give them one more go before I commit.
Thanks.
Paul
--
Live Security Virtual Conference
Exclusive live event wil
On Wed, May 30, 2012 at 3:36 PM, Roy Stogner wrote:
>
> On Wed, 30 May 2012, John Peterson wrote:
>
>> On Wed, May 30, 2012 at 3:01 PM, John Peterson
>> wrote:
>>
>>> Your second patch isn't really a great fix, since technically things
>>> should be initialized in the constructor in the order the
On Wed, May 30, 2012 at 4:36 PM, Roy Stogner wrote:
> Calling those constructors explicitly shouldn't change the generated
> code at all - doing so just wards off complaints from -Weffc++.
>
In that case, I'll leave them in and reorder the declarations to prevent
any "order warnings".
Any object
On Wed, 30 May 2012, John Peterson wrote:
On Wed, May 30, 2012 at 3:01 PM, John Peterson wrote:
Your second patch isn't really a great fix, since technically things
should be initialized in the constructor in the order they are
declared in the class, but, thinking about it for a moment, this
On Wed, May 30, 2012 at 3:01 PM, John Peterson wrote:
> On Wed, May 30, 2012 at 2:29 PM, Paul T. Bauman wrote:
>>
>> On Wed, May 30, 2012 at 3:23 PM, John Peterson wrote:
>>>
>>> Here's one error:
>>>
>>> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h: In
>>> constructor ‘libMesh::FEBas
On Wed, May 30, 2012 at 4:01 PM, John Peterson wrote:
> Your second patch isn't really a great fix, since technically things
> should be initialized in the constructor in the order they are
> declared in the class,
You're right, of course.
> but, thinking about it for a moment, this
> constru
On Wed, May 30, 2012 at 2:29 PM, Paul T. Bauman wrote:
>
> On Wed, May 30, 2012 at 3:23 PM, John Peterson wrote:
>>
>> Here's one error:
>>
>> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h: In
>> constructor ‘libMesh::FEBase::FEBase(unsigned int, const
>> libMesh::FEType&)’:
>> /Users/p
On Wed, May 30, 2012 at 3:23 PM, John Peterson wrote:
> Here's one error:
>
> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h: In
> constructor ‘libMesh::FEBase::FEBase(unsigned int, const
> libMesh::FEType&)’:
> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h:593: error:
> expect
On Wed, May 30, 2012 at 2:15 PM, John Peterson wrote:
> On Wed, May 30, 2012 at 1:45 PM, Paul T. Bauman wrote:
>>
>> Other comments before I commit?
>
> I'm rebuilding our stack now and will run our tests if you can wait a bit...
Here's one error:
/Users/petejw/projects/libmesh_git/include/fe/f
On Wed, May 30, 2012 at 3:15 PM, John Peterson wrote:
> On Wed, May 30, 2012 at 1:45 PM, Paul T. Bauman
> wrote:
> >
> > Other comments before I commit?
>
> I'm rebuilding our stack now and will run our tests if you can wait a
> bit...
>
Definitely not a problem. Take as long as you need. Thank
On Wed, May 30, 2012 at 1:45 PM, Paul T. Bauman wrote:
>
> Other comments before I commit?
I'm rebuilding our stack now and will run our tests if you can wait a bit...
--
John
--
Live Security Virtual Conference
Exclus
On Wed, May 30, 2012 at 2:40 PM, Roy Stogner wrote:
>
> On Wed, 30 May 2012, John Peterson wrote:
>
> It might be possible to have a more complete separation between the
>> mapping aspects of the FE class and the approximation space aspects,
>> i.e. have an "FEMap" base class and corresponding hi
On Wed, 30 May 2012, John Peterson wrote:
> It might be possible to have a more complete separation between the
> mapping aspects of the FE class and the approximation space aspects,
> i.e. have an "FEMap" base class and corresponding hierarchy?
I personally would be thrilled if we could general
On Wed, May 30, 2012 at 1:10 PM, Paul T. Bauman wrote:
> On Wed, May 30, 2012 at 1:57 PM, John Peterson wrote:
>>
>> One question about the design here: H(div) elements will presumably
>> require a different type of mapping [0] than what FEBase currently
>> does with Lagrange.
>>
>> So, should t
On Wed, May 30, 2012 at 1:57 PM, John Peterson wrote:
> One question about the design here: H(div) elements will presumably
> require a different type of mapping [0] than what FEBase currently
> does with Lagrange.
>
> So, should the geometry mapping stuff really be moved up into
> FEAbstract, o
On Wed, May 30, 2012 at 11:19 AM, Paul T. Bauman wrote:
> All,
>
> I've attached a patch and two files for step 0 on this (drop fe_abstract.h
> and fe_abstract.C in include/fe and src/fe respectively - svn cp doesn't
> really yield proper patches). You can also find them here if the list
> filters
On Thu, 10 May 2012, Derek Gaston wrote:
As long as we're on this subject let me throw a few things out there
Between illness and work and the renumbering discussion I let this
slip...
What I've run into though is that there is no good way to get gradient
evaluation vectorized because w
On 05/10/2012 09:28 PM, Paul T. Bauman wrote:
On Thu, May 10, 2012 at 8:21 PM, David Knezevic
mailto:dkneze...@seas.harvard.edu>> wrote:
I'm curious, what type of vector-valued elements are on the drawing
board? Nedelec? Raviart-Thomas?
Nedelec ASAP and RT will likely follow shortly
On Thu, May 10, 2012 at 8:21 PM, David Knezevic
wrote:
>
> I'm curious, what type of vector-valued elements are on the drawing
> board? Nedelec? Raviart-Thomas?
>
Nedelec ASAP and RT will likely follow shortly thereafter.
Best,
Paul
--
On 05/10/2012 06:37 PM, Roy Stogner wrote:
> Paul Bauman has an application that's motivating him to put
> vector-valued FE capabilities into libMesh, and I've got a
> shame-this-wasnt-done-years-ago that's motivating me to help, so we're
> hashing out design ideas now.
I'm curious, what type of v
As long as we're on this subject let me throw a few things out there
I've recently spent a good amount of time optimizing our variable value /
gradient / second derivative evaluation code. I've been trying to get as
much of it to vectorize as possible using the Intel compiler. This is
import
On 5/10/12 7:05 PM, Roy Stogner wrote:
>
> On Thu, 10 May 2012, Boyce Griffith wrote:
>
>> Is it feasible to template over the return type in FEBase and then
>> have the derived classes pick either scalar or vector versions?
>
> Hmm... yes, actually. We'd need some kind of traits classes to tell
On Thu, 10 May 2012, Roy Stogner wrote:
> So, 2.: Do we create FEAbstract, which doesn't include *phi* data or
> get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do
> we just add get_vec_*phi* methods (and vec_*phi data) to FEBase?
>
> With the latter option, we'd have a bunch
On Thu, 10 May 2012, John Peterson wrote:
On Thu, May 10, 2012 at 4:37 PM, Roy Stogner wrote:
So, 2.: Do we create FEAbstract, which doesn't include *phi* data or
get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do
we just add get_vec_*phi* methods (and vec_*phi data) to
On Thu, 10 May 2012, Boyce Griffith wrote:
> Is it feasible to template over the return type in FEBase and then have the
> derived classes pick either scalar or vector versions?
Hmm... yes, actually. We'd need some kind of traits classes to tell
the code that GradientOf::type is Gradient and
G
On Thu, May 10, 2012 at 4:37 PM, Roy Stogner wrote:
>
> So, 2.: Do we create FEAbstract, which doesn't include *phi* data or
> get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do
> we just add get_vec_*phi* methods (and vec_*phi data) to FEBase?
The former sounds pretty good.
On Thu, 10 May 2012, Kirk, Benjamin (JSC-EG311) wrote:
> I always cache a reference to the shape function vectors I need
> outside the element loop so in this case I can't imagine there is a
> difference between an inline and virtual function call.
You'd be surprised - in my degenerate "icpc fig
I always cache a reference to the shape function vectors I need outside the
element loop so in this case I can't imagine there is a difference between an
inline and virtual function call.
-Ben
On May 10, 2012, at 5:37 PM, "Roy Stogner" wrote:
>
> Paul Bauman has an application that's motiv
Paul Bauman has an application that's motivating him to put
vector-valued FE capabilities into libMesh, and I've got a
shame-this-wasnt-done-years-ago that's motivating me to help, so we're
hashing out design ideas now.
Two design decisions that've come up, submitted for general commentary:
1.:
32 matches
Mail list logo
