0

スラストで 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_iteratorandを使用して呼び出す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

質問:

  1. thrust::counting_iteratorファンクターオブジェクトのコンストラクターを介して出力配列へのポインターを使用して渡すことは、推奨されるアプローチですか?

  2. より一般的には、渡された引数が異なる長さのベクトルを示している場合、上記のmake_zip_iterator/パラダイムはどのように機能しますか?make_tuple

4

0 に答える 0