Move nlambda default behavior into base class

[jhp-lanl]

PR Summary

Does what it says...

PR Checklist

• N/A Adds a test for any bugs fixed. Adds tests for new features.
• Format your changes by using the make format command after configuring with cmake.
• N/A Document any new features, update documentation for changes made.
• Make sure the copyright notice on any files you modified is up to date.
• After creating a pull request, note it in the CHANGELOG.md file.
• LANL employees: make sure tests pass both on the github CI and on the Darwin CI

If preparing for a new release, in addition please check the following:

• Update the version in cmake.
• Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.
• Ensure that any when='@main' dependencies are updated to the release version in the package.py

[jhp-lanl]

Note: I didn't include a using statement in the SG_ADD_BASE_CLASS_USINGS macro because the intention is to hide the nlambda function from the base class when there are more than zero lambdas. With a using statement, the function becomes ambiguously defined rather than clearly shadowed.

We have more of these cases in the code where it might be useful to hide the base class version of a function, but we wouldn't be able to do so because of excessive using statements. That said, I think it's probably fine to just leave them until we want to hide or shadow the base class version with a different implementation in the derived class.

[Yurlungur]

Thanks for the cleanup! For the EOS's that still have an nlambda, we need to make sure the signature is identical. That is to say, they need to be static int nlambda() noexcept now.

[jhp-lanl]

I'll double check. Since I'm changing things, @Yurlungur what are your thoughts on just making these all constexpr static inline instead of using the PORTABLE_INLINE_FUNCTION decorator?

[Yurlungur]

If it works on device, I'm fine with that. If I recall, we were bitten by constexpr not working on device as we expected previously.

[jhp-lanl]

From my reading, if the expression is compile time constant, it should be inlined and will be available on device. I can't think of a reason why this function wouldn't be compile time constant.

[Yurlungur]

Well lets just give it a try and see if tests pass. (May need to add a test to stress this)

[jhp-lanl]

Well lets just give it a try and see if tests pass. (May need to add a test to stress this)

I ran into an issue with the Variant and the modifers. The main issue was that the EOS object isn't constexpr. In the modifier case, I could have called the static version from the type rather than the EOS object itself, but I felt like I was battling too much here.

[jhp-lanl]

Okay @Yurlungur I think everything should be the same now. I think I could have made static or constexpr static work, but it would have meant that the Variant versions would not be constexpr while the EOS objects would (and the modifers would have to use the type rather than the EOS object). I think I'll just stick with what works for now. Hopefully the compiler can still inline most of this

[Yurlungur]

Okay @Yurlungur I think everything should be the same now. I think I could have made static or constexpr static work, but it would have meant that the Variant versions would not be constexpr while the EOS objects would (and the modifers would have to use the type rather than the EOS object). I think I'll just stick with what works for now. Hopefully the compiler can still inline most of this

Sounds good. Too bad that ended up being a bit messy.

[jhp-lanl]

Okay I reversed myself and decided to just make constexpr work. Testing on the LANL CI right now

[jhp-lanl]

I had some issues with the python API, but that appears to be working with some minor changes. Will merge when all tests pass (maybe with the exception of the Ampere nodes since the queue times for those are pretty long today).

[jhp-lanl]

@Yurlungur tests pass. If you approve, feel free to merge

[Yurlungur]

LGTM