In addition to the discussion in #79, I think this will be useful for immersed boundary and wind turbines later, as both have domain sized coefficient arrays and ideally we should have host functions setting them and copying into GPU later. The host allocator will make this easier in my opinion.
And for the moment only the solver class uses the host_allocator, so it is only passed to solver_t. If we find use cases other places we can think about where to store this.
Any concerns about having a host_allocator? The only issue in my opinion is that because the uv and similar field pointers solver uses and the u_initu_out field pointers that are meant to be used only with host_allocator can be confusing, because both have the same type. If someone accidentaly calls a get_block on backend%allocator then this won't cause an error on CPUs (because both allocators are actually the same one, accessed by two different pointers, allocator and host_allocator), but will be a problem on GPUs.
Closes #79.
In addition to the discussion in #79, I think this will be useful for immersed boundary and wind turbines later, as both have domain sized coefficient arrays and ideally we should have host functions setting them and copying into GPU later. The host allocator will make this easier in my opinion.
And for the moment only the
solverclass uses thehost_allocator, so it is only passed tosolver_t. If we find use cases other places we can think about where to store this.Any concerns about having a host_allocator? The only issue in my opinion is that because the
uvand similar field pointers solver uses and theu_initu_outfield pointers that are meant to be used only with host_allocator can be confusing, because both have the same type. If someone accidentaly calls aget_blockonbackend%allocatorthen this won't cause an error on CPUs (because both allocators are actually the same one, accessed by two different pointers,allocatorandhost_allocator), but will be a problem on GPUs.