flare icon indicating copy to clipboard operation
flare copied to clipboard

Error after rescaling temperature

Open xig126 opened this issue 4 years ago • 6 comments

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 !

xig126 avatar Jan 23 '21 14:01 xig126

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

jonpvandermause avatar Jan 23 '21 16:01 jonpvandermause

Hi Jon,

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

test_al.py.zip

xig126 avatar Jan 24 '21 00:01 xig126

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.

xig126 avatar Feb 06 '21 16:02 xig126

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

jonpvandermause avatar Feb 08 '21 20:02 jonpvandermause

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 !

xig126 avatar Feb 15 '21 19:02 xig126

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 avatar Apr 08 '21 15:04 YuuuXie

Close stale issue

YuuuXie avatar Dec 04 '22 16:12 YuuuXie