Closed HenningScheufler closed 7 months ago
It might be smart to indicate in the name of the field where the field is executed:
NeoFOAM::device_scalarField
NeoFOAM::host_scalarField
seperation of source and header requires additional libraries for g++ and probably clang++:
https://developer.nvidia.com/blog/separate-compilation-linking-cuda-device-code/
Feel free to change the installation procedure. My knowledge of cmake is far from perfect
A requirement for the installation procedure would be that it can be easily consumed by downstream libraries e.g. https://github.com/HenningScheufler/NeoFOAM_GPL. So if kokkos is not installed it should also be installed with neofoam.
For some reason kokkos does not work with fetchcontent maybe I did something wrong.
It might be smart to indicate in the name of the field where the field is executed:
NeoFOAM::device_scalarField NeoFOAM::host_scalarField
Or we go the Ginkgo way by implementing an executor, which would be a parameter to the field constructor.
auto dev_exec = NeoFOAM::device_executor::create();
auto host_exec = NeoFOAM::host_executor::create();
NeoFOAM::scalarField a("a",N, dev_exec); // a field on a device
NeoFOAM::scalarField b("b",N, host_exec); // a field on a the host
a+b // we have to decide if this works, if fields are on different executor, in Ginkgo b would be transfered to the device
It might be smart to indicate in the name of the field where the field is executed:
NeoFOAM::device_scalarField NeoFOAM::host_scalarField
Or we go the Ginkgo way by implementing an executor, which would be a parameter to the field constructor.
auto dev_exec = NeoFOAM::device_executor::create(); auto host_exec = NeoFOAM::host_executor::create(); NeoFOAM::scalarField a("a",N, dev_exec); // a field on a device NeoFOAM::scalarField b("b",N, host_exec); // a field on a the host a+b // we have to decide if this works, if fields are on different executor, in Ginkgo b would be transfered to the device
Would it not be possible/good idea then to implement priority into the executor?
auto dev_exec = NeoFOAM::device_executor::create(1); // priority 1
auto host_exec = NeoFOAM::host_executor::create(2); // priority 2
NeoFOAM::scalarField a("a",N, dev_exec);
NeoFOAM::scalarField b("b",N, host_exec);
a+b // transfers to b 2 > 1.
Although one would need to determine what happens if priorities are equal.
Hi and welcome @bevanwsjones, thanks for contributing to NeoFOAM, it is really appreciated.
It might be smart to indicate in the name of the field where the field is executed:
NeoFOAM::device_scalarField NeoFOAM::host_scalarField
Or we go the Ginkgo way by implementing an executor, which would be a parameter to the field constructor.
auto dev_exec = NeoFOAM::device_executor::create(); auto host_exec = NeoFOAM::host_executor::create(); NeoFOAM::scalarField a("a",N, dev_exec); // a field on a device NeoFOAM::scalarField b("b",N, host_exec); // a field on a the host a+b // we have to decide if this works, if fields are on different executor, in Ginkgo b would be transfered to the device
Would it not be possible/good idea then to implement priority into the executor?
auto dev_exec = NeoFOAM::device_executor::create(1); // priority 1 auto host_exec = NeoFOAM::host_executor::create(2); // priority 2 NeoFOAM::scalarField a("a",N, dev_exec); NeoFOAM::scalarField b("b",N, host_exec); a+b // transfers to b 2 > 1.
Although one would need to determine what happens if priorities are equal.
While an interesting idea, I fear this would add a lot of complexity. In complex code we could end up with a lot of transfers between host and device. I think for a start we should fail if a + b are on different executors.
features
ability to easily evaluate fields on the GPU:
tests
benchmarks