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, 30 May 2012, Kirk, Benjamin (JSC-EG311) wrote:
> I do know enough to say our bundled parmetis is quite crusty, and it
> may be worth upgrading that before getting too far inside it...
We're using 3.1 from 2003, the latest stable version is 4.0.2 from
2011... yeah, I'll try bumping us up
I do know enough to say our bundled parmetis is quite crusty, and it may be
worth upgrading that before getting too far inside it...
-Ben
On May 30, 2012, at 7:33 PM, "Roy Stogner" wrote:
>
> While trying to track down a bug in my next ParallelMesh patch, I ran
> into an apparent bug in our
While trying to track down a bug in my next ParallelMesh patch, I ran
into an apparent bug in our Parmetis support that dates back for I
don't know how far.
We already serialize and fall back on Metis when we have more elements
than processors, and according to our code comments N_e= 0"
Since n
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
*ping*
Will commit on Friday if I don't hear from anyone. Thanks.
On Thu, May 24, 2012 at 4:28 PM, Paul T. Bauman wrote:
> FEMSystem users,
>
> I've attached a patch that fixes a problem when numerical Jacobians are
> forced on the user side and verify_analytic_jacobians = 0.0. In particular,
>
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
20 matches
Mail list logo
