Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error after rescaling temperature #273

Closed
xig126 opened this issue Jan 23, 2021 · 7 comments
Closed

Error after rescaling temperature #273

xig126 opened this issue Jan 23, 2021 · 7 comments
Assignees

Comments

@xig126
Copy link

xig126 commented Jan 23, 2021

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
test_otf.run()
File "/home/repos/flare/flare/otf.py", line 300, in run
self.md_step() # update positions by Verlet
File "/home/repos/flare/flare/ase/otf.py", line 205, in md_step
self.md.step()
File "/home/bin/miniconda3/lib/python3.6/site-packages/ase/md/verlet.py", line 46, in step
f = atoms.get_forces(md=True)
File "/home/bin/miniconda3/lib/python3.6/site-packages/ase/atoms.py", line 754, in get_forces
forces = self._calc.get_forces(self)
File "/home/bin/miniconda3/lib/python3.6/site-packages/ase/calculators/calculator.py", line 659, in get_forces
return self.get_property('forces', atoms)
File "/home/bin/miniconda3/lib/python3.6/site-packages/ase/calculators/calculator.py", line 695, in get_property
self.calculate(atoms, [name], system_changes)
File "/home/repos/flare/flare/ase/calculator.py", line 93, in calculate
self.calculate_mgp(atoms)
File "/home/repos/flare/flare/ase/calculator.py", line 177, in calculate_mgp
rebuild_map.build_map(self.gp_model)
File "/home/repos/flare/flare/mgp/mapxb.py", line 539, in build_map
self.update_bounds(GP)
File "/home/repos/flare/flare/mgp/mapxb.py", line 513, in update_bounds
min_dist = self.search_lower_bound(GP)
File "/home/repos/flare/flare/mgp/mapxb.py", line 602, in search_lower_bound
training_data = _global_training_data[GP.name]
KeyError: 'default_gp'

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 !

@jonpvandermause jonpvandermause self-assigned this Jan 23, 2021
@jonpvandermause
Copy link
Collaborator

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

@xig126
Copy link
Author

xig126 commented Jan 24, 2021

Hi Jon,

Here's the script that I'm using. Thanks for your help.

test_al.py.zip

@xig126
Copy link
Author

xig126 commented Feb 6, 2021

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.

@jonpvandermause
Copy link
Collaborator

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 673e9ae) 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

@xig126
Copy link
Author

xig126 commented Feb 15, 2021

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 !

@YuuuXie
Copy link
Collaborator

YuuuXie commented Apr 8, 2021

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.

@YuuuXie
Copy link
Collaborator

YuuuXie commented Dec 4, 2022

Close stale issue

@YuuuXie YuuuXie closed this as completed Dec 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants