Sorry about the late reply.
I just wrote a small toy code to see if the coarsening and refining
produces the same distribution using ParMetis and it does !! I've
attached the code with the mail and feel free to test it with some of
your own mesh files to confirm.
Ben, thanks for the update on the
>> If this makes sense, I think I have a nice place to start working on this.
>> And as long as coarsen and refine are pseudo-inverse operations,
>
> Hmm... they still may not be. If you do a System::reinit() after
> coarsen/refine, the Mesh will also be repartitioned, and I don't know
> that our
On Wed, 12 Nov 2008, Vijay S. Mahadevan wrote:
> But really, do you think there is a need for redistribution of all the
> dofs ? I was thinking that each processor would handle coarsen/refine
> on its own and only the boundary elements need to update the data as
> to which other processor's ele
> Hmm... they still may not be. If you do a System::reinit() after
> coarsen/refine, the Mesh will also be repartitioned, and I don't know
> that our partitioners (the default, METIS/ParMETIS, in particular) are
> guaranteed to give you the same partitioning every time you give them
> the same mes
On Wed, 12 Nov 2008, Vijay M wrote:
> Yes, in order to avoid it, I'm going to make the conscious decision to start
> from a coarse mesh that resolves all the boundaries and material interfaces
> correctly and then use that as the coarsest mesh. Now, if I refine this
> uniformly twice and keep tha
very active level
of the mesh. Is this what you had in mind ?
> -Original Message-
> From: Benjamin Kirk [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 12, 2008 9:59 PM
> To: Vijay M
> Cc: [email protected]
> Subject: Re: [Libmesh-users] Multigri
t
> Subject: RE: [Libmesh-users] Multigrid techniques with libmesh
>
>
>
> On Wed, 12 Nov 2008, Vijay M wrote:
>
> >>> For example when I have an unstructured grid, and when I coarsen
> >>> uniformly twice and refine uniformly twice, would I get the e
>>> For example when I have an unstructured grid, and when I coarsen
>>> uniformly twice and refine uniformly twice, would I get the exact
>>> same mesh?!
One issue is we cannot coarsen below the initial, level-0 mesh.
So if you start with a mesh, uniformly refine twice, and then uniformly
coarse
On Wed, 12 Nov 2008, Vijay M wrote:
>>> For example when I have an unstructured grid, and when I coarsen
>>> uniformly twice and refine uniformly twice, would I get the exact
>>> same mesh?!
>>
>> No. For instance, the second mesh above is a uniform coarsening (so
>> far as such a thing exists)
> Not to be a MeshData hater, but I wonder if your purposes would be better
> served by the element subdomain flag? It is an unsigned char in each
> element you can use to mark elements for whatever purpose you wish... You
> could then have a function or table lookup that provides material proper
ed ? Or am I way off
in my understanding ?
> -Original Message-
> From: Roy Stogner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 12, 2008 7:02 PM
> To: Vijay S. Mahadevan
> Cc: [email protected]
> Subject: Re: [Libmesh-users] Multigrid techniques wi
in existing libmesh objects ?!
Again, I appreciate all the help Roy.
> -Original Message-
> From: Roy Stogner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 12, 2008 7:02 PM
> To: Vijay S. Mahadevan
> Cc: [email protected]
> Subject: Re: [Lib
>> Of course, you would also have to propagate the mesh_data (Or again,
>> am I the only one using this ?) which stores material
>> information/element or create a view of it also.
>
> You may be the only one using this. ;-) But yes, we'd want to handle
> its restriction as well.
If your primar
On Wed, 12 Nov 2008, Benjamin Kirk wrote:
> Ah... right again. Right now find_neighbors() blows away all neighbor
> information at the beginning, but I am about to change that for another
> reason... (finishing the nemesis stuff).
Run your changes by me? find_neighbors() is probably where we n
>> I was juist thinking about the dof indexing too...
>>
>> What about adding a system for each mg level?
>
> Oh, you don't mean adding a System, you mean adding a system index to
> each DofObject. That would certainly make space for the indexing, and
> it would probably make the indexing proces
On Wed, 12 Nov 2008, Vijay S. Mahadevan wrote:
> I am curious on the concept of the 'view' of a mesh.
Basically, we store hierarchic meshes like this:
*---*---*
*-*=*=*=*
*==*==*
Where the mesh is 1D, there are 5 active elements and 3 ancestor
elements.
We can
> We wouldn't be averse to making library
> changes to enable CPU-efficient geometric multigrid
That is good to know. I'll try my best to suggest ideas to make the
implementation of geometric multigrid as easy as possible, as I go
through the process of using libMesh data structures.
Like I menti
On Wed, 12 Nov 2008, Kirk, Benjamin (JSC-EG) wrote:
> I was juist thinking about the dof indexing too...
>
> What about adding a system for each mg level?
Oh, you don't mean adding a System, you mean adding a system index to
each DofObject. That would certainly make space for the indexing, and
some work...
-Ben
- Original Message -
From: Roy Stogner <[EMAIL PROTECTED]>
To: Vijay M <[EMAIL PROTECTED]>
Cc: [email protected]
Sent: Wed Nov 12 17:43:07 2008
Subject: Re: [Libmesh-users] Multigrid techniques with libmesh
On Wed, 12 Nov 2008, Vijay M
On Wed, 12 Nov 2008, Vijay M wrote:
> Of course, I do not have any multi-grid support in my framework yet and so
> was wondering if there was a cleaner and elegant way to perform geometric
> multigrid. My main problem is that since mesh is associated with the
> EquationSystem, when I coarsen the
rge.net
Subject: Re: [Libmesh-users] Multigrid techniques with libmesh
We're currently working on some papers in this area... but I don't have
anything to share yet.
Here's what I will say. If you are using a matrix or jacobian free method
and you specify your residual cor
> But you don't necessarily have to put the exact _right_ thing either.
> There is some grey area here... and what works for one system of equations
> won't work for another. In general, if you put something resembling the
> true jacobian in there... it will greatly help your linear solves.
is
> could be a problem.
>
> When you get back, please do detail on your findings and I would be very
> much interested to know about your experiences.
>
> Thanks.
> Vijay
>
> > -Original Message-
> > From: Roy Stogner [mailto:[EMAIL PROTECTED]
> &g
.
Thanks.
Vijay
> -Original Message-
> From: Roy Stogner [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 07, 2008 9:48 PM
> To: Derek Gaston
> Cc: [email protected]
> Subject: Re: [Libmesh-users] Multigrid techniques with libmesh
>
>
> On Fr
On Fri, 7 Nov 2008, Derek Gaston wrote:
> The answer to #2 is YES... We use Hypre with BoomerAMG to precondition
> our matrix free solves all the time. Just build petsc with Hypre
> support and pass the following on the command-line for your app:
>
> -snes_mf_operator -pc_type hypre -pc_hypre_ty
Just a quick reply until I get back to a computer on Monday...
The answer to #2 is YES... We use Hypre with BoomerAMG to precondition
our matrix free solves all the time. Just build petsc with Hypre
support and pass the following on the command-line for your app:
-snes_mf_operator -pc_type h
Hi there,
Before I even start, I know this is probably going to be a loaded
question, but nevertheless, any help would be appreciated.
Background: I'm working on solution to large scale PDE systems based
on libmesh for discretization and petsc for solution procedures. My
physics objects are deriv
27 matches
Mail list logo
