Update batched matrix inversion and update frontier recipe

[ye-luo]

Proposed changes

Resolves #4741 by deleting the non-pivoting code path that needs kernels.
The non-pivoting case was needed likely by the legacy CUDA which was deleted.

What type(s) of changes does this code introduce?

• Refactoring (no functional changes, no api changes)

Does this introduce a breaking change?

• No

What systems has this change been tested on?

epyc-server

Checklist

• Yes. This PR is up to date with current the current state of 'develop'

[ye-luo]

@jakurzak I was reading #3341 (comment). What is the current behavior of hipblas?getrfBatched() and hipblas?getriBatched()? Are they unconditionally hitting the non-pivoting case or they behave like cuBLAS selecting code path depending on whether the pointer is nullptr? In the former case, the current code is good. In the latter case, we may further simplify the code in QMCPACK.

[ye-luo]

Test this please

[prckent]

The problem with asserts is that they are only active in debug builds. We don't have any ROCm debug builds in testing. Throw an exception instead?

[ye-luo]

The problem with asserts is that they are only active in debug builds. We don't have any ROCm debug builds in testing. Throw an exception instead?

Agreed. It is pure C++ now and thus exception is better. I was concerned of C++ and HIP interaction.

[ye-luo]

Test this please.

[prckent]

Simpler.

rtd build for nexus docs is sick but this PR does not touch any docs. Hopefully a transient problem.