acesuit / acehal Goto Github PK

Due to the simplicity of BIC and from experience it seems there's always a nice minimum. In terms of basis optimisation I think it may make sense to start from low polynomial degree and increase such that when the BIC increases near the minimum we terminate and use BIC optimal basis. Does this make sense?

I think it simplifies and speeds up the optimisation considerably and naturally adds complexity by growing the ACE basis as a function of data.

@bernstei Thoughts?

Ultimately we'll want to be able to send our "shopping list" or fit configs to HAL and have it return a ACE model. This would require HAL to run DFT calculations on the unlabelled configurations and automatically determine the E0 too.

This aids usability and would allow users to send a few configurations of interest and receive a stable ACE model, only having to specify HAL_traj_params.

I should have mentioned this sooner, but you could consider replacing pyjulia with juliacall (https://cjdoris.github.io/PythonCall.jl/stable/juliacall/). I believe there is rough consensus that it is the better choice for new projects, but I don't have enough personal experience to say.

I thought of it when reading though #12.

Addition of swap MC steps using SwapMC. The MC accept/reject function can then be filtered out of CellMC and shared.

Occasionally the trian/test errors can look strange if a large force component greater than 'Fmax' is included in the train/test database. This can skew the error table considerably, while the actual model itself typically runs very well and has good generalisation on 'normal' forces.

@bernstei What are your thoughts on excluding these forces (and perhaps the total energy too) from training and test? It has confused me and I'm sure it may do so for others too.

Do we need to add control over the Agnesi transform, in particular over q, in the default basis?

log.txt

Use square brackets [] for indexing an Array.' occurred while calling julia code:
using ACE1x

            elements = basis_info["elements"]
            cor_order = basis_info["cor_order"]
            maxdeg = basis_info["maxdeg"]
            r_cut = basis_info["r_cut"]
            smoothness_prior_param = basis_info["smoothness_prior"]
            
            B = ACE1x.ace_basis(elements = Symbol.(elements), 
                        order = cor_order, 
                        totaldegree = maxdeg, 
                        rcut = r_cut)

            B_length = length(B)
            if isnothing(smoothness_prior_param)
                P_diag = nothing
            elseif smoothness_prior_param[1] isa String && smoothness_prior_param[2] isa Number && lowercase(smoothness_prior_param[1]) == "algebraic"
                P_diag = diag(smoothness_prior(B; p = smoothness_prior_param[2]))
            else
                throw(ArgumentError("Unknown smoothness_prior"))
            end

I have seen this error twice now and have attached the full log. It doesn't seem specific to the basis chosen and when I restarted HAL from the same configurations I couldn't reproduce it.

Do we still need these functions as the new defaults in ACE1pack already take care of this?

@bernstei

HAL iter 51 got config with criterion 0.07172618293682953 at time step None / 2000

If the final step is reached without triggering the tolerance it gets reported as None

Let HAL use Atoms.info to set parameters (overriding explicitly passed in arguments) for particular initial configs.

• traj_len
• temperature_K
• P_GPa

Anything else, @casv2 ?

• tau_rel?

Should we package those parameters into a dict, and have HAL receive that instead of individual arguments?