Actually, after looking at the amount of work required for a change
nobody is going to use, I'm just going to skip it. PointLocatorList
already breaks unless your mesh is the Voronoi diagram of the
elements' centroids and you have a fetish for using O(N) instead of
O(NlogN) algorithms; if any suc
>From now on, operator(Point &p) will search for an active element
containing p, not just the element nearest p, and if it doesn't find a
containing active element it will just return NULL. This is to make
it more consistent with PointLocatorTree, and to make it useful on
ParallelMesh.
This is a
We're doing some UQ work with libMesh now that involves more
complicated MPI setups. One of those (letting libMesh's COMM_WORLD be
a subset of the real COMM_WORLD) worked beautifully out of the box,
but another (doing parallel activity over yet-a-third communicator)
wasn't nicely encapsulated in
Hello all,
I thought most people on these lists would be interested in job postings in my
group at Idaho National Laboratory. We are looking for good computational
scientists of all levels... and particularly those with experience working with
libMesh!
If you are interested please go to the I
