pelesh

Possible solution could be to create policy specification containers like this: ```c++ // hiopExecPolicies.hpp #include #ifdef HIOP_USE_RAJA #ifdef HIOP_USE_GPU struct hiopCudaPolicies { hiopExecutionPolicies() = default; using hiop_raja_exec = RAJA::cuda_exec; using...

> I think these are great ideas, but what's the point of `policy_namespace`? Is this foreshadowing some `hiopForAll` function that doesn't use a raja policy? Yes, indeed. This could allow...

Addressing #240 could simplify creating class templates for RAJA linear algebra objects.

I believe something like this could work: Keep pure virtual base class as is: ```c++ // hiopVector.hpp class hiopVector { public: hiopVector(){} virtual ~hiopVector(){} virtual void add_const(double c) = 0;...

> One thing to keep in mind is that we may still need to specialize/subclass the hiopVectorRaja (same for the matrices classes) to provide platform-dependent implementation for (supposedly small number...

Similar issue is addressed in #522 for newell.

@nychiang, as far as I know we used a combination of clang C++ and gcc Fortran compilers to build HiOp with Fortran interface. My understanding is that ROCm bitcode library...

> @pelesh : is this PR still under development or it only waits for you review? Not quite ready to be merged yet.

It might be a good idea to consider vector views that do not own the data, but are used for user/application to read/write from appropriate locations. In the example you...

The way I see it, implementing vector view could be as easy as adding another constructor or two to the existing vector class plus a flag indicating if the object...