スラストで odeint を使用する場合、多くの初期条件の問題を並行して解決しながら、状態変数のヒストグラムを生成するオブザーバーを開発しています。
初期条件の問題は並行して実行され、device_vector に次のようなデータが入力されます。
Trajectory 0, Variable 0, Histogram Bin 0;
Trajectory 0, Variable 0, Histogram Bin 1;
...
Trajectory 0, Variable 1, Histogram Bin 0;
Trajectory 0, Variable 1, Histogram Bin 1;
...
Trajectory 1, Variable 0, Histogram Bin 0;
Trajectory 1, Variable 0, Histogram Bin 1;
...
または、より簡潔に言えば、配列のインデックスは次のように計算されます。
trajectoryIndex*N_BINS*N_VARS +varIndex*N_BINS +binIndex
...以降、このベクトルは変数ごとに 1 つのヒストグラムに縮小されます。
私が見てきた odeint + Thrust で使用されているパラダイムは、演算子のファンクターを、thrust のmake_zip_iterator
andを使用して呼び出すmake_tuple
ことです。したがって、次のようになります。
thrust::for_each(
thrust::make_zip_iterator(
thrust::make_tuple(
boost::begin( x ) + 0*m_N,
boost::begin( x ) + 1*m_N
),
thrust::make_zip_iterator(
thrust::make_tuple(
boost::begin( x ) + 1*m_N,
boost::begin( x ) + 2*m_N
),
observer_functor()
);
これは、ファンクターへの引数がすべて同じ長さの場合にうまく機能します。しかし、私の場合、上記のように入力されるヒストグラム データの device_vector はサイズが異なり、ファンクターに与えられた他の引数 (状態変数など) とは異なる方法でインデックスを付ける必要があります。
少し調べてみたところ、これを行う最善の方法は、ファンクターにヒストグラム マトリックスの入力に必要な軌跡インデックスを提供する Thrust ::counting_iteratorを渡すことだと思います。次に、(明らかに) なんらかの形でヒストグラム マトリックスへのポインターを提供して、データを入力できるようにする必要があります。おそらく、observer_functor にヒストグラム ベクトルへのポインターを提供するための最良の解決策は、オブザーバーのコンストラクターへの引数として提供することです (ここに投稿した別の質問の解決策と同様)。
渡された引数が異なる長さのベクトルを示している場合、上記のmake_zip_iterator
/パラダイムの配列がどのように機能するかについて、これらすべてが混乱を引き起こしました。make_tuple
質問:
thrust::counting_iterator
ファンクターオブジェクトのコンストラクターを介して出力配列へのポインターを使用して渡すことは、推奨されるアプローチですか?より一般的には、渡された引数が異なる長さのベクトルを示している場合、上記の
make_zip_iterator
/パラダイムはどのように機能しますか?make_tuple