On Fri, Feb 6, 2009 at 6:04 PM, Kirk, Benjamin (JSC-EG)
wrote:
> This is definitely one of those times I am glad this list is archived...
>
> The various combinations of potential values for
>
> -pc_hypre_boomeramg_strong_threshold
> -pc_hypre_boomeramg_grid_sweeps_down
> -pc_hypre_boomeramg_grid_
This is definitely one of those times I am glad this list is archived...
The various combinations of potential values for
-pc_hypre_boomeramg_strong_threshold
-pc_hypre_boomeramg_grid_sweeps_down
-pc_hypre_boomeramg_grid_sweeps_up
-pc_hypre_boomeramg_relax_type_all
-pc_hypre_boomeramg_relax_type
On Feb 6, 2009, at 4:29 PM, Roy Stogner wrote:
> Not necessarily separate classes, just the ability to have separate
> classes.
Agreed.
> AMG is still pretty black-box (that being the whole point) and can
> probably just be a type parameter to whatever numerics packages have
> that interface -
On Fri, 6 Feb 2009, Derek Gaston wrote:
> On Feb 6, 2009, at 3:47 PM, Roy Stogner wrote:
>> Supporting old APIs is always good. If you want to stick a deprecated()
>> warning in there now and plan to get rid of it in the future, though,
>> that's fine.
>>
>> In the near term, I'd like to hav
On Feb 6, 2009, at 3:47 PM, Roy Stogner wrote:
> Supporting old APIs is always good. If you want to stick a
> deprecated() warning in there now and plan to get rid of it in the
> future, though, that's fine.
>
> In the near term, I'd like to have a factory method that takes a
> Preconditione
Derek Gaston wrote:
> Ok - I went ahead and committed that so that I can work on the next
> step... which is allowing you to attach a Preconditioner to the linear
> solver. But now we need some discussion on that.
>
> First, do we want to support the old style of specifying a
> precondition
Ok - I went ahead and committed that so that I can work on the next
step... which is allowing you to attach a Preconditioner to the linear
solver. But now we need some discussion on that.
First, do we want to support the old style of specifying a
preconditioner type for a LinearSolver? Or
On Fri, Feb 6, 2009 at 2:45 PM, Derek Gaston wrote:
> So... I've got the initial Preconditioner class and a PetscPreconditioner
> class based on it all coded up and working with my current code. I've
> attached the diff with all of the changes. If no one sees anything big I'll
> go ahead and com
So... I've got the initial Preconditioner class and a PetscPreconditioner
class based on it all coded up and working with my current code. I've
attached the diff with all of the changes. If no one sees anything big I'll
go ahead and commit it then we can talk about the next move.
Currently, I hav
On Fri, 6 Feb 2009, Roy Stogner wrote:
> This particular fix worked for the problem at hand, but ex14 still
> isn't working past the first solve - I suspect it may be a flaw in the
> new projection case; I'll try to track it down this weekend.
ex14 is fixed now; I hadn't completely fixed the bug
On Fri, 6 Feb 2009, Derek Gaston wrote:
What do you guys think about a configure option for turning off bin/
apps compilation? I never use them...
Sure you do: you use them every time you compile a changed library
version, to make sure that those four applications still build and
link correc
What do you guys think about a configure option for turning off bin/ apps
compilation? I never use them... and they actually take quite a while to
link in debug mode
Lately I've found myself modifying the Makefile so they don't get built...
which means it should probably be a configure option.
On Fri, 6 Feb 2009, Tim Kroeger wrote:
On Thu, 5 Feb 2009, Roy Stogner wrote:
Hmmm... we don't want to change _is_closed (requiring the user to
close() after operator= would be an API change, which I'd like to
avoid as much as possible), but it looks like we need to do
*something* within oper
13 matches
Mail list logo
