-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More flexible radial basis embedding #17
Conversation
Also, forces.jl has yet to be fixed currently
Looks like this PR is ready to be reviewed. Now the input radial could be an abstract chain, along with its radial specification. The chain itself and its specification are stored in a new structure called Radial_basis (we can at any time change it). The only requirement to the chain is that it should map a configuration |
Also, I enabled the rSH-based chain (for |
Thank you, Liwei. @CheukHinHoJerry - can you do a first review please. I'll then take another look before merging. |
Just to put a note here that 9321a06 resolved reverse over reverse of single species model. |
@CheukHinHoJerry -- can you quickly confirm what you had to change? Is it simply replacing the comprehension with a broadcast? |
Yes - more precisely, I changed from this: Radial_basis(Chain(trans = WrappedFunction(xx -> [f_trans(norm(x)) * f_cut(norm(x)) for x in xx]),
poly = lux(basis), ), spec) to this: Radial_basis(Chain(getnorm = WrappedFunction(x -> norm.(x)), trans = WrappedFunction(x -> f.(x)), poly = lux(basis), ), spec) and similarly this also works: Radial_basis(Chain(trans = WrappedFunction(x -> f.(norm.(x))), poly = lux(basis), ), spec) Still, I don't understand fully the reason behind this yet. |
I used two work around, which should be taken care by ACEsuit/Polynomials4ML.jl#67 (comment) and #18 |
This PR aims to enable a more general radial embedding, as is addressed in Issue #11