On Mon, 13 Oct 2008, John Peterson wrote:
> On Mon, Oct 13, 2008 at 9:04 AM, Gong Ding <[EMAIL PROTECTED]> wrote: >> In function >> >> template <typename T> >> >> inline void gather(const unsigned int root_id, >> >> std::vector<std::complex<T> > &r) >> >> line 1454 to 1457 should be >> // now resize r to hold the global data >> >> // on the receiving processor >> >> if (root_id == libMesh::processor_id()) >> >> r.resize(globalsize/2); >> >> >> >> since mysize is doubled at line 1430 Let's see... mysize is doubled to get a size in terms of number of elements of T rather than number of elements of complex<T>. globalsize is still in terms of T, but r is a vector of complex<T>, so yes, it looks like you're right, that ought to be globalsize/2. I'll commit the fix momentarily. Thanks! > Hmm... > > I'm not sure I see how this function works. r and r_src are > vector<complex<T>> but we are MPI gathering them as datatype<T>, where > T=Real. Surely the layouts of an array of T and a vector<complex<T>> > are not the same in memory. No, but they're nearly interchangeable: a complex<T> is basically just a struct with two T's in it, and I believe an array ca of the former can be interpreted as an array ra of the latter where ca[n].real() == ra[2*n] and ca[n].imag() == ra[2*n+1]. I don't think the standard prohibits other in-memory representations of complex<>, but the only other space-efficient representation would be to put the imaginary part first, which would work just as well with this code. --- Roy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
