We should definitely pass the device copy of prob_parm as that is likely to be needed by users. prob_parm is really intended to contain data used on device and the host version mostly just exists as a pass through to create the device copy.

We should either pass both host and device copies, which makes the API a bit ugly, or pass only the device copy, which may force users to do some operations in device code that would be more efficient on host. For example, if a binary flag indicates whether or not an operation should be carried out, it would be most efficient to do that check once and never launch a ParallelFor if the operation is not to be carried out, rather than launching the parallel for and doing an identical check at each grid point.

Leaning toward passing both host and device copies as the better option. It's a bit off label, but users may want to stick something in prob_parm to determine functionality that doesn't directly involve device code (e.g., a flag indicating whether or not to dump extra output files)

Leaning toward passing both host and device copies as the better option. It's a bit off label, but users may want to stick something in prob_parm to determine functionality that doesn't directly involve device code (e.g., a flag indicating whether or not to dump extra output files)

This is exactly the issue I'm running into. I need prob_parm as a flag prior to doing any device code.

It's just as much for me as a reminder!

I snuck in a minor change to the README that reflects @jrood-nrel recent update from c++17 to c++20.