Wow - we'll certainly run the full suite of tests on Monday (and maybe create a
few new ones!).
Thanks for catching this and fixing it!
Derek
On Jun 16, 2011, at 7:35 PM, Roy Stogner wrote:
>
>
> On Thu, 16 Jun 2011, Derek Gaston wrote:
>
>> we use dphi and d2phi for 1D elements in 2D all t
On Thu, 16 Jun 2011, Derek Gaston wrote:
> we use dphi and d2phi for 1D elements in 2D all the time as well.
> Are you sure it's wrong...
Pretty sure. "dphi[i][p](1) = 0." doesn't leave a lot of room for
uncertainty.
> because we're definitely getting the
> right answers... even for analytic
Ok good! Because we use 2D in 3D all the time and actually now that I
think about it we use dphi and d2phi for 1D elements in 2D all the time as
well. Are you sure it's wrong... because we're definitely getting the right
answers... even for analytic solutions.
I don't have time to check f
On Thu, 16 Jun 2011, Roy Stogner wrote:
> Does libMesh not calculate dphi and d2phi properly for
> lower-dimensional elements embedded at odd angles in
> higher-dimensional spaces?
Things might not be as bad as I thought - it looks like the
2D-embedded-in-3D code was correct, just the 1D-embedde
So here's an embarrassing question from me:
Does libMesh not calculate dphi and d2phi properly for
lower-dimensional elements embedded at odd angles in
higher-dimensional spaces?
I always assumed that worked (despite having edited the code
myself...), and I even vaguely recall telling someone el
> That compiler is the Apple one... switching away from it is essentially
> impossible (I don't know of anyone, anywhere that has ever been able to get
> Fortrran and C++ to link together on OSX using non Apple GCC). The Intel
> compilers used to be an option... but they have their own issues (
hi all :)
it happened for me to need to evaluate the "volume" of Face elements in my
code through these functions:
Real Tri3::volume () const
Real Quad4::volume () const
...however, i noticed that the same function is not implemented for Tri6,
Quad8, Quad9 and so on... due to the fact that thes
Good information guys! Our Mac user base is large so we'd have to consider the
cost of maintaining fink packages on end-user machines... so we'd probably
rather not go that route but it's good to know somebody is doing that. If I'm
not mistaken, the "compile" time of Apple's branch of the GNU
On Jun 16, 2011, at 1:09 PM, Boyce Griffith wrote:
> On 6/16/11 2:00 PM, Derek Gaston wrote:
>>
>> You have to remember that we use Macs
>>
>> That compiler is the Apple one... switching away from it is essentially
>> impossible (I don't know of anyone, anywhere that has ever been able to
On 6/16/11 2:00 PM, Derek Gaston wrote:
>
> On Jun 16, 2011, at 11:46 AM, Roy Stogner wrote:
>
>> I'm just saying that, even if we do make the switch, you should
>> upgrade your compiler too. If it flubbed std::fill that badly then
>> there's probably lots of other stuff it's not optimizing as w
On Jun 16, 2011, at 11:46 AM, Roy Stogner wrote:
> I'm just saying that, even if we do make the switch, you should
> upgrade your compiler too. If it flubbed std::fill that badly then
> there's probably lots of other stuff it's not optimizing as well as it
> should be.
You have to remember that
Apologies if I sent out an earlier version of this email already; our
NFS server is going nuts today...
On Thu, 16 Jun 2011, John Peterson wrote:
> We've stuck with the std::fill method for std::complex for now... I
> think in 99% of implementations memset should work there too, but I'm
> not su
On Thu, 16 Jun 2011, Roy Stogner wrote:
On Thu, 16 Jun 2011, John Peterson wrote:
On Thu, Jun 16, 2011 at 10:43 AM, Roy Stogner
wrote:
What compiler and flags are you using? It looks like the real
optimization you need here is a change in one or both of those!
GCC 4.2.1, -O3
And now
On Thu, Jun 16, 2011 at 19:16, Roy Stogner wrote:
> The GNU STL implementation is a twisty maze of passages, all alike, so
> I may have missed something, but the only obvious specializations I
> see are the memset-based char one and the vector implementation.
>
Why don't you disassemble the func
On Thu, 16 Jun 2011, John Peterson wrote:
On Thu, Jun 16, 2011 at 10:43 AM, Roy Stogner wrote:
What compiler and flags are you using? It looks like the real
optimization you need here is a change in one or both of those!
GCC 4.2.1, -O3
And now we know which one you need to change. ;-
On Thu, Jun 16, 2011 at 10:43 AM, Roy Stogner wrote:
>
>
> On Thu, 16 Jun 2011, John Peterson wrote:
>
>> Some results on my workstation for doubles: memset is roughly 2 orders
>> of magnitude faster than std::fill when it is measurable.
>>
>> N Fill method Memset method
>> 100 0.0121
On Thu, 16 Jun 2011, John Peterson wrote:
> Some results on my workstation for doubles: memset is roughly 2 orders
> of magnitude faster than std::fill when it is measurable.
>
> NFill method Memset method
> 100 0.012151s0.000625s
Here's what I get with a few compiler/optimiza
Excellent. Any objections to including and making it std::memset
instead?
On 6/16/11 11:07 AM, "John Peterson" wrote:
> Hi,
>
> We were doing some profiling here recently and were surprised when
> DenseMatrix::zero() showed up as 11% in a particular application!
>
> (You'll have to ask Dere
Hi,
We were doing some profiling here recently and were surprised when
DenseMatrix::zero() showed up as 11% in a particular application!
(You'll have to ask Derek why he was calling DenseMatrix::zero() so
many times ;-P)
If you replace std::fill() in this method with a call to memset (which
is l
19 matches
Mail list logo
