NaN problem

[casv2]

┌ Warning: automatic inverse not implemented, inverse will return NaN
└ @ ACE1.Transforms ~/.julia/packages/ACE1/G18CB/src/polynomials/transforms.jl:270
I’m getting this warning and got
JULIA: InexactError: trunc(Int64, NaN)

My residuals look fine. Should I be using a different transform? These are with ACE1pack defaults, but the transform problem points towards ACE1.Transforms

[casv2]

It’s seemingly related to specific design matrices and dependent on the solver, smoothness prior and weights… Weird…

[cortner]

That warning is due to a left-over job for me. Some transforms don't have analytic inverses so I need to implement numerical inverses. This is not needed for model evaluation and also the 2-b basis doesn't care. For the many-body basis you need that either q = p or q = 2*p -- these are the special cases for which there is an analytic inverse.

If this has become urgent then I'll fix it asap.

[casv2]

I'm not sure I'm getting these, it's an Int64?

JULIA: InexactError: trunc(Int64, NaN)
Stacktrace:
  [1] trunc
    @ ./float.jl:805 [inlined]
  [2] floor
    @ ./float.jl:367 [inlined]
  [3] newf
    @ ~/.julia/packages/StaticArrays/pTgFe/src/broadcast.jl:185 [inlined]
  [4] macro expansion
    @ ~/.julia/packages/StaticArrays/pTgFe/src/broadcast.jl:140 [inlined]
  [5] __broadcast
    @ ~/.julia/packages/StaticArrays/pTgFe/src/broadcast.jl:128 [inlined]
  [6] _broadcast
    @ ~/.julia/packages/StaticArrays/pTgFe/src/broadcast.jl:124 [inlined]
  [7] copy
    @ ~/.julia/packages/StaticArrays/pTgFe/src/broadcast.jl:62 [inlined]
  [8] materialize
    @ ./broadcast.jl:860 [inlined]
  [9] position_to_cell_index
    @ ~/.julia/packages/NeighbourLists/UvQ2u/src/cell_list.jl:48 [inlined]
 [10] _celllist_(X::Vector{StaticArraysCore.SVector{3, Float64}}, cell::StaticArraysCore.SMatrix{3, 3, Float64, 9}, pbc::StaticArraysCore.SVector{3, Bool}, cutoff::Float64, TI::Type{Int64})
    @ NeighbourLists ~/.julia/packages/NeighbourLists/UvQ2u/src/cell_list.jl:126
 [11] _pairlist_(X::Vector{StaticArraysCore.SVector{3, Float64}}, cell::StaticArraysCore.SMatrix{3, 3, Float64, 9}, pbc::StaticArraysCore.SVector{3, Bool}, cutoff::Float64, TI::Type, fixcell::Bool)
    @ NeighbourLists ~/.julia/packages/NeighbourLists/UvQ2u/src/cell_list.jl:294
 [12] #PairList#1
    @ ~/.julia/packages/NeighbourLists/UvQ2u/src/cell_list.jl:6 [inlined]
 [13] neighbourlist(at::Atoms{Float64}, rcut::Float64; recompute::Bool, key::String, storelist::Bool, int_type::Type, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ JuLIP ~/.julia/packages/JuLIP/ALlQ0/src/atoms.jl:198
 [14] neighbourlist(at::Atoms{Float64}, rcut::Float64)
    @ JuLIP ~/.julia/packages/JuLIP/ALlQ0/src/atoms.jl:188
 [15] alloc_temp(V::PolyPairPot{Float64, ACE1.OrthPolys.TransformedPolys{Float64, ACE1.Transforms.AnalyticTransform{Float64}, ACE1.OrthPolys.OrthPolyBasis{Float64}, PolyEnvelope{Float64}}, 2, 0}, at::Atoms{Float64})
    @ JuLIP.Potentials ~/.julia/packages/JuLIP/ALlQ0/src/Potentials.jl:168
 [16] #8
    @ ./none:0 [inlined]
 [17] iterate
    @ ./generator.jl:47 [inlined]
 [18] collect(itr::Base.Generator{UnitRange{Int64}, JuLIP.Potentials.var"#8#9"{PolyPairPot{Float64, ACE1.OrthPolys.TransformedPolys{Float64, ACE1.Transforms.AnalyticTransform{Float64}, ACE1.OrthPolys.OrthPolyBasis{Float64}, PolyEnvelope{Float64}}, 2, 0}, Atoms{Float64}}})
    @ Base ./array.jl:724
 [19] energy(V::PolyPairPot{Float64, ACE1.OrthPolys.TransformedPolys{Float64, ACE1.Transforms.AnalyticTransform{Float64}, ACE1.OrthPolys.OrthPolyBasis{Float64}, PolyEnvelope{Float64}}, 2, 0}, at::Atoms{Float64}; kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ JuLIP.Potentials ~/.julia/packages/JuLIP/ALlQ0/src/Potentials.jl:194
 [20] energy
    @ ~/.julia/packages/JuLIP/ALlQ0/src/Potentials.jl:194 [inlined]
 [21] (::JuLIP.MLIPs.var"#26#27"{Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, Atoms{Float64}})(calc::PolyPairPot{Float64, ACE1.OrthPolys.TransformedPolys{Float64, ACE1.Transforms.AnalyticTransform{Float64}, ACE1.OrthPolys.OrthPolyBasis{Float64}, PolyEnvelope{Float64}}, 2, 0})
    @ JuLIP.MLIPs ./none:0
 [22] MappingRF
    @ ./reduce.jl:95 [inlined]
 [23] _foldl_impl(op::Base.MappingRF{JuLIP.MLIPs.var"#26#27"{Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, Atoms{Float64}}, Base.BottomRF{typeof(Base.add_sum)}}, init::Base._InitialValue, itr::Vector{Any})
    @ Base ./reduce.jl:62
 [24] foldl_impl
    @ ./reduce.jl:48 [inlined]
 [25] mapfoldl_impl
    @ ./reduce.jl:44 [inlined]
 [26] #mapfoldl#244
    @ ./reduce.jl:162 [inlined]
 [27] mapfoldl
    @ ./reduce.jl:162 [inlined]
 [28] #mapreduce#248
    @ ./reduce.jl:289 [inlined]
 [29] mapreduce
    @ ./reduce.jl:289 [inlined]
 [30] #sum#251
    @ ./reduce.jl:503 [inlined]
 [31] sum
    @ ./reduce.jl:503 [inlined]
 [32] #sum#252
    @ ./reduce.jl:532 [inlined]
 [33] sum
    @ ./reduce.jl:532 [inlined]
 [34] #energy#25
    @ ~/.julia/packages/JuLIP/ALlQ0/src/mlips.jl:172 [inlined]
 [35] energy(sumip::JuLIP.MLIPs.SumIP{Any}, at::Atoms{Float64})
    @ JuLIP.MLIPs ~/.julia/packages/JuLIP/ALlQ0/src/mlips.jl:172
 [36] invokelatest(::Any, ::Any, ::Vararg{Any}; kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ Base ./essentials.jl:716
 [37] invokelatest(::Any, ::Any, ::Vararg{Any})
    @ Base ./essentials.jl:714
 [38] _pyjlwrap_call(f::Function, args_::Ptr{PyCall.PyObject_struct}, kw_::Ptr{PyCall.PyObject_struct})
    @ PyCall ~/.julia/packages/PyCall/twYvK/src/callback.jl:28
 [39] pyjlwrap_call(self_::Ptr{PyCall.PyObject_struct}, args_::Ptr{PyCall.PyObject_struct}, kw_::Ptr{PyCall.PyObject_struct})

Occasionally and I don't know why, I'm just using all the ACE1x.ace_basis defaults

[cortner]

That's in the neighbourlist- could be caused by illegal memory access. If you can come up with a way to reproduce this we can debug

[casv2]

I think it's because the config it's evaluated on a config that is just particularly insane, I guess it's really a bug in the swap_MC P+R mentioned above. However, it would be nice to perhaps do this a bit more gracefully, but I don't think this is urgent or an ACE1 bug at all.