How do you find the number of non-zero elements in a Grid Function in Cactus?
-DG
— David Garrison, Ph.D. Faculty Senate President, Associate Professor of Physics University of Houston-Clear Lake Bayou 3531 Houston, TX 77058
Tel: 281-283-3796 Fax: 281-283-3709 http://sce.uhcl.edu/garrison
"If we knew what it was we were doing, it would not be called research, would it?" — Albert Einstein.
On Fri, Nov 20, 2015 at 04:41:48AM +0000, Garrison, David wrote:
How do you find the number of non-zero elements in a Grid Function in Cactus?
The best way would probably be to count them locally on each process, write the result in a distributed grid array, and do the sum there by syncing the array and counting locally (not sure if a reduction on such an array would work, it might).
Another, but more expensive way (in terms of memory size and memory accesses) would be to create another grid function, populate it with either 1 or 0 depending on the non-zero-property of the GF you are interested in, and calling the existing sum-reduction on it.
Frank
On Thu, Nov 19, 2015 at 11:05 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Fri, Nov 20, 2015 at 04:41:48AM +0000, Garrison, David wrote:
How do you find the number of non-zero elements in a Grid Function in
Cactus?
The best way would probably be to count them locally on each process, write the result in a distributed grid array, and do the sum there by syncing the array and counting locally (not sure if a reduction on such an array would work, it might).
There is no need for a distributed grid array. After counting locally, a "local reduction" (i.e. reduction of a local variable) gives you the overall result.
-erik
Another, but more expensive way (in terms of memory size and memory
accesses) would be to create another grid function, populate it with either 1 or 0 depending on the non-zero-property of the GF you are interested in, and calling the existing sum-reduction on it.
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Thu, Nov 19, 2015 at 11:33:28PM -0600, Erik Schnetter wrote:
There is no need for a distributed grid array. After counting locally, a "local reduction" (i.e. reduction of a local variable) gives you the overall result.
I've never tried to 'reduce' a grid scalar, interesting. I would imagine it would be done using an array under the hood (something has to count, after all), but it would be transparent to the user.
Frank
On Thu, Nov 19, 2015 at 11:05:24PM -0600, Frank Loeffler wrote:
The best way would probably be to count them locally on each process, write the result in a distributed grid array, and do the sum there by syncing the array and counting locally (not sure if a reduction on such an array would work, it might).
One complication here would be that, with AMR at least, you would need to take care of masking non-evolved points (ghost, boundary, coarse grid points inside fine grids, ...).
Another, but more expensive way (in terms of memory size and memory accesses) would be to create another grid function, populate it with either 1 or 0 depending on the non-zero-property of the GF you are interested in, and calling the existing sum-reduction on it.
Here you wouldn't need to care about masking, as the Carpet reduction would do that for you.
Frank
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Garrison, David