A case where finetuna fails to reach a reasonable minimum

[gauthierlab]

Hello again! I've found a couple of cases where finetuna fails to reach a reasonable minimum. From my very brief use of it, the common theme seems to be weak binding metals with adsorbates that don't quite bind. It seems like finetuna can fail to localize a minimum with the molecule just above the surface and instead the molecule can float up through the periodic image leading to surfaces potentially blowing up.

I don't know how useful this is, but I've also included a zip file with one such case, *N2H on Ag (111). I'm running a regular VASP optimization to see how the cg optimizer handles this and will update when it's finished.
to_zulissi.zip

[12Chao]

I had a similar issue with CO2 on Cu(111) relaxation when I was testing for PR #51. It ended up with a structure being predicted by Finetuna cannot be calculated by the parent calculator, and thus causing a crash to the parent calculator.

For CO2 on Cu(111) relaxation calcualtion, it starts with a structure like this

and the parent calculator failed at a structure like this

However, it worked fine for another system (CH3 on Cu(111)) I tested on. The script I used to run the calculation is described in PR #51. The input and output trajectory, and log files are attached here. Any answers on what is causing this would be really appreciated. Thanks!
finetuna_qe_test_gpu.zip

[zulissi]

Yes, we've noticed the same thing but hadn't updated the defaults in the examples yet. If you have a weakly adsorbing situation (especially with dispersion on) or the calculation is very different from the training data (RPBE), querying one point in the beginning is much safer (and not a big difference in total number of calls. We also found query every 30 steps to be much more robust. These are the defaults in finetuna_wrap.py, but not the defaults yet elsewhere.

@gauthierlab try using ASE to write the VASP inputs, then use finetuna_wrap.py (https://github.com/ulissigroup/finetuna/blob/main/finetuna/vasp_wrapper/finetuna_wrap.py) to handle everything. That's what we've been doing for most of our recent calculations.

@gauthierlab @12Chao if using the example scripts try adjusting your learner_params to:

	learner_params={
	    "stat_uncertain_tol": 1000000,
	    "dyn_uncertain_tol": 1000000,
	    "dyn_avg_steps": 15,
	    "query_every_n_steps": 30, # 30 instead of 100 steps
	    "num_initial_points": 1, # Always sample the very first point with DFT
	    "initial_points_to_keep": [],
	    "fmax_verify_threshold": 0.03,
	    "tolerance_selection": "min",
	    "partial_fit": True,
	}

[LoryWangxx]

@gauthierlab @12Chao
just a minor thing- when you set num_initial_points to 1, i.e.: sample the initial point with DFT, you should also set initial_points_to_keep to [0], or simply comment it out, so that it is actually trained on the first point.

learner_params={
	    "stat_uncertain_tol": 1000000,
	    "dyn_uncertain_tol": 1000000,
	    "dyn_avg_steps": 15,
	    "query_every_n_steps": 30, # 30 instead of 100 steps
	    "num_initial_points": 1, # Always sample the very first point with DFT
            # "initial_points_to_keep": [0],
	    "fmax_verify_threshold": 0.03,
	    "tolerance_selection": "min",
	    "partial_fit": True,
	}

[jmusiel]

I just pushed an update that will default to using all the initial points if the list is empty, since this is kind of a confusing behavior. So it can remain unchanged if you just pull the latest version.

[jmusiel]

After testing it, it seems that setting the number of initial points to 1 seems to fix this convergence issue on the N2H on Ag 111 system, I will upload an example script for this system