Is there a simple way to send a 2d vector in C++, say vector<vector<int>> A(size,vector<int>(size)) from one node to another using MPI? If not, what would be the least complicated way to do this? Would it be easier to send a 2d array rather than a 2d std::vector ?
Related
I am trying to simulate some plasma phenomena, which translates into simulating the dynamics of a huge number of particles. The usual approach is to cluster a number of particles into some "macroparticle", so that instead of having to loop over N particles, the program loops over some n < N, assuming the dynamics of the N/n particles in the n macroparticles is exactly the same.
However, even doing this in some occasions I need to work with 1e22 macroparticles. I need to store the position of those 1e22 particles in some array of the form
std::vector<double> pos(Npart)
where Npart is part of the input. Since there is no C++ type that can store such a big integer number in Npart I am wondering what are the usual strategies used in these problems. Maybe defining many arrays with less particles? What is a good practice here?
I am using a R/C wrapper to call a set of subroutines in a Fortran module. I want to get the outputs as arrays of 2D and 3D in R. However, I am having troubles defining the 3D output in the wrapper. So far I did not manage to define the output for a 3D array, since allocMatrix takes only three arguments (for 2D arrays/matrices):
SEXP output = PROTECT( allocMatrix(REALSXP, nt, 5) );
// 2nd argument to allocMatrix is number of rows, 3rd is number of columns
Does anyone know if it is possible or how to define the output as a 3D array in the wrapper?
I'm working on a Mac running Fortran 90, GNU Fortran, and the C compiler that comes with Xcode.
Any help/suggestion would be much appreciated.
I'm writing a bunch of recursive graph algorithms where graph nodes have parents, children, and a number of other properties. The algorithms can also create nodes dynamically, and make use of recursive functions.
What are the right data structures to use in this case? In C++ I would've implemented this via pointers (i.e. each node has a vector<Node*> parents, vector<Node*> children), but I'm not sure if Julia pointers are the right tool for that, or if there's something else ... ?
In Julia state-of-the-art with this regard is the LightGraphs.jl library.
It uses adjacency lists for graph representation and assumes that the data for nodes is being kept outside the graph (for example in Vectors indexed by node identifiers) rather than inside the graph.
This approach is generally most efficient and most convenient (operating Array indices rather than references).
LightGraphs.jl provides implementation for several typical graph algorithms and is usually the way to go when doing computation on graphs.
However, LightGraphs.jl,'s approach might be less convenient in scenarios where you are continuously at the same time adding and destroying many nodes within the graph.
Now, regarding an equivalent of the C++ approach you have proposed it can be accomplished as
struct MyNode{T}
data::T
children::Vector{MyNode}
parents::Vector{MyNode}
MyNode(data::T,children=MyNode[],parents=MyNode[]) where T= new{T}(data,children,parents)
end
And this API can be used as:
node1 = MyNode(nothing)
push!(node1.parents, MyNode("hello2"))
Finally, since LightGraphs.jl is a Julia standard it is usually worth to provide some bridging implementation so your API is able to use LightGraphs.jl functions.
For illustration how it can be done for an example have a look for SimpleHypergraphs.jl library.
EDIT:
Normally, for efficiency reasons you will want the data field to be be homogenous across the graph, in that case better is:
struct MyNode{T}
data::T
children::Vector{MyNode{T}}
parents::Vector{MyNode{T}}
MyNode(data::T,children=MyNode{T}[],parents=MyNode{T}[]) where T= new{T}(data,children,parents)
end
With FFTW and MPI, given a two-dimensional array that is the transform of a real function, represented in complex space, is it possible to output the real-space array transposed?
For example, suppose there is a 2x4 array in real space. If the code calls fftw_mpi_plan_dft_r2c_2d, then it will output a 2x3 complex array. If the flag FFTW_MPI_TRANSPOSED_OUT is added, then the output is a 3x2 complex array, the transpose of the former array. I can easily produce this behavior.
My question: is it possible to go the other way? Starting with a 2x3 complex array that is the complex-space transform of a 2x4 real-space array, is it possible to use fftw_mpi_plan_dft_c2r_2d with suitable arguments to produce the transposed, 4x2 real-space array?
Note, this is in 2D. In 3D, everything works fine, indicating that in 2D it may have to do with the last dimension representing only half of the complex plane conflicting with FTTW's expectation of the layout of the complex transpose.
In C++ in order to create a vector that has 10 vectors of integers I would do the following:
std::vector< std::vector<int> > test(10);
Since I thought Thrust was using the same logic with the STL I tried doing the same:
thrust::host_vector< thrust::host_vector<int> > test(10);
However I got too many confusing errors. I tried doing:
thrust::host_vector< thrust::host_vector<int> > test;
and it worked, however I can't add anything to this vector. Doing
thrust::host_vector<int> temp(3);
test.push_back(temp);
would give me the same errors(too many to paste them here).
Also generally speaking when using Thrust, does it make a difference between using host_vector and the STL's vector?
Thank you in advance
Thrust's containers are only designed for POD (plain old data) types. It isn't possible to create multidimensional vectors by instantiating "vectors of vectors" in thrust, mostly because of the limitations on the GPU side which make it impossible to pass and use in the device code path.
There is some level of compatibility between C++ standard library types and algorithms and the thrust host implementation of those STL derived models, but you should really stick with host vectors when you want to work both with the host and device library back ends.