sergio-santos-group / ProtoSyn.jl

A Julia-based framework for molecular modelling
https://sergio-santos-group.github.io/ProtoSyn.jl/stable/
GNU Affero General Public License v3.0
58 stars 7 forks source link

Inexact Error: trunc(Int64, NaN) when running example 6 steepest descent #50

Closed kool7d closed 1 year ago

kool7d commented 1 year ago

I am getting an error at the example 6 (steepest descent) step:

steepest_descent = ProtoSyn.Drivers.SteepestDescent(energy_function, callback, 500, 0.001, 0.1)
steepest_descent(pose)

It gives me what looks like one round. energy_function(pose) gives me a value, then I run steepest_descent(pose) and it shows an updated number. 0 1134.041 is what the output looks like before it errors. I check energy_function(pose) again and it is 1134.041. So I think one round is happening. Also, I remove the all-atom clash with really high energy and get the same error.

I am pretty sure I have the dependencies like torch and torchani installed correctly, and I get no warning about anything except SeqDes.

Anyways, the stacktrace looks like:

ERROR: InexactError: trunc(Int64, NaN)
Stacktrace:
 [1] trunc
   @ ./float.jl:781 [inlined]
 [2] ceil(#unused#::Type{Int64}, x::Float64)
   @ Base ./float.jl:358
 [3] hist_by_distance_by_elem(pose::Pose{Topology}, selection::PromoteSelection{ProtoSyn.Stateless}; cutoff::Float64, bin::Float64, elems::Vector{String}, dm::Matrix{Float64})
   @ ProtoSyn ~/.julia/packages/ProtoSyn/Yx5Xy/src/Core/Methods/histogram.jl:76
 [4] predict_igbr_nn_born_radii(pose::Pose{Topology}, selection::PromoteSelection{ProtoSyn.Stateless}; dm::Matrix{Float64}, models::ProtoSyn.Calculators.GB.GBModels)
   @ ProtoSyn.Calculators.GB ~/.julia/packages/ProtoSyn/Yx5Xy/src/Core/Calculators/gb.jl:78
 [5] calc_gb(A::Type{ProtoSyn.CUDA_2}, pose::Pose{Topology}, selection::TrueSelection{ProtoSyn.Stateless, ProtoSyn.Atom}, update_forces::Bool; born_radii::typeof(ProtoSyn.Calculators.GB.predict_igbr_nn_born_radii), ϵ_protein::Float64, ϵ_solvent::Float64, models::ProtoSyn.Calculators.GB.GBModels, cut_off::Float64)
   @ ProtoSyn.Calculators.GB ~/.julia/packages/ProtoSyn/Yx5Xy/src/Core/Calculators/gb.jl:161
 [6] (::ProtoSyn.Calculators.EnergyFunction)(pose::Pose{Topology}; update_forces_overwrite::Bool)
   @ ProtoSyn.Calculators ~/.julia/packages/ProtoSyn/Yx5Xy/src/Core/Calculators/energy_function.jl:223
 [7] (::ProtoSyn.Drivers.SteepestDescent)(pose::Pose{Topology})
   @ ProtoSyn.Drivers ~/.julia/packages/ProtoSyn/Yx5Xy/src/Core/Drivers/steepest_descent.jl:174
 [8] top-level scope
   @ ~/Documents/Prots2.jl/src/prototesting.jl:32
JosePereiraUA commented 1 year ago

So, this was an interesting one. I actually found 2 problems:

  1. So, the first one was actually on the recovery from previous steps. The copy function was being used instead of ProtoSyn.recoverfrom! (which makes sure the pose graph and state ids remain connected). I'm not sure but I think somehow this is what was causing the GB problem.

  2. The second one was a wrong negative sign when calculating forces in the distance-based flat-bottom potential restraint employed in the "all-atom clash restraint" component. Atoms were actually being pushed together instead of further apart.

All-in-all, the two fixes I've added should solve this issue. I've also went ahead and refurbished example 4. Take a look at commit 985e0986b80ea40556637df7533d3426449cf7ec, and give me some feedback.

JosePereiraUA commented 1 year ago

Seems like this issue has been resolved. Closing.