On Mon, 4 Aug 2008, Roy Stogner wrote:
> Also on the "stuff to fix before a new release" list: has anyone
> looked at example 10 lately? I knew it was triggering a bug in
> ParallelMesh, but apparently I should have been double-checking it
> with SerialMesh too: it's now mostly refining at each
On Mon, 4 Aug 2008, Benjamin Kirk wrote:
> Well, it looks like we have hit a wall and need a hack to get out of it.
>
> I agree that he pedantic error checking is a good thing, and that this is
> probably doing exactly what we want.
Well, for our purposes, my_bin isn't altered inside that loop,
> Or
> perhaps this needs to be done at the top of the file before the c++
> includes?
Of course, that is the only thing that makes sense... Duh.
Perhaps we can do that in the file, along with a hefty amount of comments??
-Ben
---
> And I don't see a good solution. We're not going to convince the
> libstdc++ people to take out a debugging check or even to make the
> debug-enabling macros more fine-grained. It makes no sense to disable
> the METHOD=dbg STL checks, since that's the point of using dbg instead
> of devel. We
On Mon, 4 Aug 2008, John Peterson wrote:
> __glibcxx_requires_partitioned(__first, __last, __val);
>
> In debug mode, this may be checking to see if the range is partitioned
> (sorted?) at each call to lower_bound, which could be an O(N)
> operation.
Sorted with respect to __val, I believe
On Mon, Aug 4, 2008 at 3:43 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Mon, 4 Aug 2008, John Peterson wrote:
>
>> I believe the complexity requirements for std::distance on a model
>> of forward iterator is O(N).
>
> That's right; you only get O(1) if you've got a RandomAccessIterator.
>
>>
On Mon, 4 Aug 2008, John Peterson wrote:
> I believe the complexity requirements for std::distance on a model
> of forward iterator is O(N).
That's right; you only get O(1) if you've got a RandomAccessIterator.
> I don't think we are using forward iterators here (we've just used
> that word as
> Specifically, look for the statement "global_ids.clear();" in
> mesh_communication_global_indices.C. The for loop immediately
> following is where all the CPU time is being sucked up. But I don't
> see what the problem is. Nothing inside a libmesh_assert() there is
> expensive. Putting std::
On Mon, Aug 4, 2008 at 3:02 PM, John Peterson <[EMAIL PROTECTED]> wrote:
>
> Thanks! I need to run to a meeting.. but as an aside, I believe the
> complexity requirements for std::distance on a model of forward
> iterator is O(N). I don't think we are using forward iterators here
> (we've just us
On Mon, Aug 4, 2008 at 2:49 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Mon, 4 Aug 2008, John Peterson wrote:
>
>> Any chance the call to std::distance is O(N) for some reason in debug
>> mode? For std::vectors I know this should be O(1), but maybe
>> something weird is happening in dbg mode
On Mon, 4 Aug 2008, John Peterson wrote:
> Any chance the call to std::distance is O(N) for some reason in debug
> mode? For std::vectors I know this should be O(1), but maybe
> something weird is happening in dbg mode.
Hmmm... maybe. std::distance is also used in the "build up lists of
reques
On Mon, Aug 4, 2008 at 2:16 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Mon, 4 Aug 2008, Roy Stogner wrote:
>
>> Also on the "stuff to fix before a new release" list: has anyone
>> looked at example 10 lately?
>
> One last problem that ex10 triggers: I used to be annoyed by how long
> comput
On Mon, 4 Aug 2008, Roy Stogner wrote:
> Also on the "stuff to fix before a new release" list: has anyone
> looked at example 10 lately?
One last problem that ex10 triggers: I used to be annoyed by how long
compute_sparsity() took, but at least that was just a minute, not an
hour. METHOD=dbg i
> Sounds good. I'd like to hear back from the users who are seeing
> sparse matrix assembly slowdowns with 0.6.2 before we release
> anything, though; if that's not already working correctly in SVN, we
> should fix it before making a new release.
Also on the "stuff to fix before a new release" l
On Fri, 1 Aug 2008, Benjamin Kirk wrote:
>> The hard (or at least tedious) part may be fixing our I/O classes to
>> write out and read in solutions with per-subdomain variables. I'm not
>> familiar with the nitty-gritty details of our output formats, but I
>> wouldn't be surprised if they didn'
> The hard (or at least tedious) part may be fixing our I/O classes to
> write out and read in solutions with per-subdomain variables. I'm not
> familiar with the nitty-gritty details of our output formats, but I
> wouldn't be surprised if they didn't all support such a thing.
I'm thinking for m
On Fri, 1 Aug 2008, Roy Stogner wrote:
> On Fri, 1 Aug 2008, Adam C Powell IV wrote:
>
>> This is a neat approach, which I could use myself in a separate problem.
>> One issue though: how do I get, say, T to be 0 on domain A, when it is
>> non-zero at nodes on the A-B boundary? Do you have any e
On Fri, 1 Aug 2008, Adam C Powell IV wrote:
> This is a neat approach, which I could use myself in a separate problem.
> One issue though: how do I get, say, T to be 0 on domain A, when it is
> non-zero at nodes on the A-B boundary? Do you have any examples?
No examples. I'd try to add a new c
18 matches
Mail list logo
