Under what conditions does this occur? I'm surprised if you're seeing
it for 2D meshes (where IIRC we build quadtrees instead of octrees)
and I'm surprised that I've never seen it for 1D meshes...
Sounds like a straightforward solution, though; someone want to glance
over and commit it?
---
Roy
On Sat, 18 Dec 2010, Jed Brown wrote:
On Fri, Dec 17, 2010 at 10:49, Jan Biermann wrote:
I just implemented two new solvers in Petsc that make use of
Krylov subspace recycling, which means that if you have to solve
a sequence of linear systems, the overall cost can be reduce
On Fri, 17 Dec 2010, John Peterson wrote:
> We would most likely wait to check-in until Roy has returned from
> holiday vacation and has had a chance to look over/comment on the
> patch, so there is no hurry.
Thanks. :-) I'm barely keeping up on my email at the moment; won't
have time to chec
On Fri, Dec 17, 2010 at 10:49, Jan Biermann wrote:
> I just implemented two new solvers in Petsc that make use of Krylov
> subspace recycling, which means that if you have to solve a sequence of
> linear systems, the overall cost can be reduced significantly (by 10 to
> 100).
Have you sent thes
Hi, Folks --
We recently ran into a floating point exception coming from
location_maps.C. The problem is that when LIBMESH_DIM is 3 but the mesh
has DIM < 3, _lower_bound[i] == _upper_bound[i] for some dimensions.
Because LocationMap::key() computes, e.g.,
zscaled = (p(2) - _lower_bound[2
On Fri, Dec 17, 2010 at 3:49 AM, Jan Biermann wrote:
> Dear developers,
>
> I just implemented two new solvers in Petsc that make use of Krylov subspace
> recycling, which means that if you have to solve a sequence of linear
> systems, the overall cost can be reduced significantly (by 10 to 100).
Dear developers,
I just implemented two new solvers in Petsc that make use of Krylov
subspace recycling, which means that if you have to solve a sequence of
linear systems, the overall cost can be reduced significantly (by 10 to
100). I also coded the respective interface in libmesh and now I
