Dear libMesh team,
As I'm just so much in asking questions, here's another one: How will
the performance of EquationSystems::reinit() behave when ParallelMesh
is ready for use by user application? The reason for my question is
that for my code on a large number of processors,
EquationSystems:
On Wed, 16 Apr 2008, Tim Kroeger wrote:
> As I'm just so much in asking questions, here's another one: How will
> the performance of EquationSystems::reinit() behave when ParallelMesh
> is ready for use by user application?
At first, just as badly as before. System::project_vector() is still
on
> The tool I work on here at work can compare any two arbitrary
> solutions to each other... even with completely non-nested grids. The
> user gets to decide what kind of crime they want to commit though.
> Often (if the meshes are really dissimilar) we'll use an overkill
> rendezvous mesh to tra
On Wed, 16 Apr 2008, John Peterson wrote:
> In the nested case, differing p-levels would also be interesting.
> Should I then perform my integration over the mesh which has a single
> high-p element or over the one that chose to split it into multiple
> low-degree elements having small h?
You in
On Wed, Apr 16, 2008 at 9:27 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Wed, 16 Apr 2008, John Peterson wrote:
>
>
> > Just out of curiosity, what would be the "right thing" to do in order
> > to compare two meshes with different (still nested) refinement
> > patterns or two solutions on co
Dear Roy and all,
On Wed, 16 Apr 2008, Roy Stogner wrote:
> On Wed, 16 Apr 2008, John Peterson wrote:
>
>> It's not immediately obvious to me what such a comparison would
>> actually tell you in any case...
>
> Oh, well I just meant that *what* to do to integrate between two such
> grids was obvio
The tool I work on here at work can compare any two arbitrary
solutions to each other... even with completely non-nested grids. The
user gets to decide what kind of crime they want to commit though.
Often (if the meshes are really dissimilar) we'll use an overkill
rendezvous mesh to transfer both
On Wed, 16 Apr 2008, John Peterson wrote:
> Just out of curiosity, what would be the "right thing" to do in order
> to compare two meshes with different (still nested) refinement
> patterns or two solutions on completely non-nested grids?
Loop over one grid. On each element, if the other grid i
On Wed, Apr 16, 2008 at 8:15 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Wed, 16 Apr 2008, Tim Kroeger wrote:
>
> > Next question from me: Is there some easy way in libMesh to compare
> > computation results on different grids? I.e., I have two
> > EquationSystems instances that consist
Oops... I guess I didn't read the thread carefully enough. Thanks for
clearing that up!
-J
On Wed, Apr 16, 2008 at 9:00 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 16 Apr 2008, John Peterson wrote:
>
>
> > On Wed, Apr 16, 2008 at 8:52 AM, Derek Gaston <[EMAIL PROTECTED]> wrote:
> >
On Wed, 16 Apr 2008, John Peterson wrote:
> On Wed, Apr 16, 2008 at 8:52 AM, Derek Gaston <[EMAIL PROTECTED]> wrote:
>> On Wed, Apr 16, 2008 at 6:44 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>> > I wonder if we should do something to help catch such problems even in
>> > opt mode. Testing a w
On Wed, Apr 16, 2008 at 7:55 AM, John Peterson <[EMAIL PROTECTED]> wrote:
> A general ParallelMesh::check_parallel_consistency() function, or
> whatever you'd like to call it, seems like it would be appropriate.
> If nothing else it could be used during debugging to see just where
> the Mesh fi
On Wed, Apr 16, 2008 at 8:52 AM, Derek Gaston <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 16, 2008 at 6:44 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
> > I wonder if we should do something to help catch such problems even in
> > opt mode. Testing a whole SerialMesh for consistency might be
> >
On Wed, Apr 16, 2008 at 6:44 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
> I wonder if we should do something to help catch such problems even in
> opt mode. Testing a whole SerialMesh for consistency might be
> overkill for an "optimized" code, but we might take one message's
> latency hit to
On Wed, Apr 16, 2008 at 7:44 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 16 Apr 2008, Tim Kroeger wrote:
>
>
> > I wonder why my application code was running in earlier days. That was
> > indeed on a different cluster, but it was nevertheless a cluster.
>
> Parallelism bugs can de
On Wed, 16 Apr 2008, Tim Kroeger wrote:
> Next question from me: Is there some easy way in libMesh to compare
> computation results on different grids? I.e., I have two
> EquationSystems instances that consist of equal systems but live on
> different grids, where both grids are refinements of th
Dear libMesh team,
Next question from me: Is there some easy way in libMesh to compare
computation results on different grids? I.e., I have two
EquationSystems instances that consist of equal systems but live on
different grids, where both grids are refinements of the same initial
grid. For
Dear Roy,
On Wed, 16 Apr 2008, Roy Stogner wrote:
> I wonder if we should do something to help catch such problems even in
> opt mode. Testing a whole SerialMesh for consistency might be
> overkill for an "optimized" code, but we might take one message's
> latency hit to at least make sure that
On Wed, 16 Apr 2008, Tim Kroeger wrote:
> Ah, there we are. I always forgot that asserts do not hit in optimized mode.
> (Running in debug mode requires recompiling both libMesh and our institute
> software, since they share the same macros, so I avoid it whenever possible.)
Understandable;
Dear Roy,
On Tue, 15 Apr 2008, Roy Stogner wrote:
>> Question #2: Does one of you guys have an idea why this could happen
>> (other than my application code doing stupid things)?
>
> Not a clue. Even if your application code tried to renumber ids
> itself, this sort of crash could happen in opt
20 matches
Mail list logo
