Error after rescaling temperature
Dear developer,
I'm trying to do an OTF training with a fcc Al (32 atoms) in a NVE ensemble. I rescaled the temperature to 1e4K after 5ps and got the following error after several steps:
Traceback (most recent call last):
File "Al_NVE_melt.py", line 165, in
The name of my gp model is ''default_gp'' and this key do exists in the imported _global_training_data. Do you have any idea why this error occurs ?
Thanks !
Hi xig126,
Thanks for raising this issue. Would you mind posting your script here? I'll try running it to see if I can pinpoint the bug (it looks like it may be a problem inside mapxb.py).
Thanks, Jon
Hi @jonpvandermause ,
I tried to look into the code and it seems a new empty '_global_training_data' dict is imported in mapxb.py when searching for new lower bound of the GP.
Also, I'm kind of confused of the whole structure of the code cause it seems a lot of methods/functions are named the same even though they are in different modules.
Do you have any update on this issue ?
Thanks.
Hi xig126,
Apologies for the delay, and thanks very much for sending your script. I ran into the same error as you on our master branch, but found no error on the development branch, so I think one of our recent commits (possibly 673e9ae82499637d4916121d8adfb53b013136c4) addressed this issue.
Could you please try running the code on the development branch and let me know if the issue is resolved? We'll be merging these commits into master in the next week or so.
As for the duplicate methods in the code: some of these (e.g. methods in the ASE OTF class) are child class methods that overwrite methods in the parent class, which means they have the same name but do different things. Of course it's possible that there is some unnecessary duplication in the code -- please let us know if you have concerns about specific methods, and we can take a look.
Thanks, Jon
Hi @jonpvandermause ,
Thanks for your help. I tried to run the code on development branch and the the issue is resolved.
However, it seems that there's another problem. I found that DFT calculation is only called at the very first step and then all the calculated 'Std. Dev (ev/A)' values are zero for the rest steps. I also observed an abrupt increase of temperature after several md steps. otf_run.out.zip
Do you have any idea why this occurred ? (Similar to #274 ?)
Thanks !
Hi @xig126, for the issue that std. dev are all zeros, I see from your script that you set
mgp_model = MappedGaussianProcess(grid_params, unique_species = [13], n_cpus = 1, var_map=None)
The problem is that you set var_map=None, so only the forces are mapped (and used), while the variances are not mapped so the mgp_model is always predicting 0 for the uncertainties. You can try setting var_map="pca" to get non-zero predictions.
Also, you can also try not using the mapping, setting
flare_calculator = FLARE_Calculator(gp_model,
par = True,
mgp_model = None,
use_mapping = False)
and run purely with GP and see if the otf training still blows up the temperature. Though I don't think the mapping should be a big issue.
Close stale issue