LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Mailing List Archives
Re: [lammps-users] Implementation of a numerical Hessian via a new fix
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lammps-users] Implementation of a numerical Hessian via a new fix


From: Johannes P. Dürholt <johannes.duerholt@...455...>
Date: Sun, 3 Dec 2017 19:53:45 +0100

Hi Axel and Giacomo,

thanks to your suggestions I had again a look on the timings.

My question arose from the fact that when I was running 1632 (6*number of atoms as necessary for a double sided finite difference Hessian) of NVE of my system it took me around 13 seconds, and when I was calling 1632 "run 0 post no" it took around 23 seconds.

Thanks to Axels last post, I know now that I should use "run 0 pre no post no", which is much faster. But then a new problem arises: I get for every distortion the same energy and forces ...

In the manual I found the following sentence:

"If your input script changes the system between 2 runs, then the initial setup must be performed to insure the change is recognized by all parts of the code that are affected."

And this means that I have to run with "pre yes" or?

Or do I do something wrong/bad/stupid?

Best

Johannes


On 12/03/2017 07:09 PM, Axel Kohlmeyer wrote:


On Sun, Dec 3, 2017 at 12:12 PM, Giacomo Fiorin <giacomo.fiorin@...24...> wrote:
Hi, one thing that you may want to ensure is that you use NumPy array indexing (closely mimicking Matlab's):

matrix[irow,:] = vector[:]

where the 2nd dimension of "matrix" and "vector" have the same length.  This way the element-by-element assignment will be executed directly in C: unless you deal with really short arrays, the speed is indistinguishable.  A similar optimization, if you use NumPy functions, is to use the optional "out" parameter of those function.

As Axel said, for typical systems the force computation, which is O(N^2) or O(NlogN) at best, dominates over the cost of creating the Python objects around the LAMMPS arrays, which does not depend on N.

​...and since the displacements in finite difference calculations are small and no time integration is required​, one can also save significant overhead by skipping a lot of extra setup work (e.g. avoid re-initializing the neighbor lists) with "run 0 pre no post no" instead of "run 0".

axel.

 

Giacomo

On Sun, Dec 3, 2017 at 7:46 AM, Axel Kohlmeyer <akohlmey@...24...> wrote:


On Sat, Dec 2, 2017 at 4:11 PM, Johannes P. Dürholt <johannes.duerholt@...455...> wrote:
Hi Axel,

thanks for your answer. This is exactly what I do in the moment. 

I need the Hessian for Force Field fitting and have to evaluate it thousands of times in one run. So its computation is speed relevant. Doing it directly in a fix should speed up the process.

​have you made some timing test to determine, how much time you spend in python and how much in LAMMPS. under normal circumstances, the force computation in LAMMPS should be the dominant part, so amdahl's law will limit how much speed-up you can achieve, since that parts won't be changed.

axel.​

 

Best

Johannes


Am 02.12.2017 9:56 nachm. schrieb Axel Kohlmeyer <akohlmey@...24...>:


On Sat, Dec 2, 2017 at 1:43 PM, Johannes P. Dürholt via lammps-users <lammps-users@...42...e.net> wrote:
Dear users,

I want to implement the computation of a finite difference based Hessian in LAMMPS. My Idea is to write a new fix. The fix should use the methods initial_integrate and final_integrate. In the initial_integrate method the an atoms coordinate is displaced, and in the final_integrate method the actual finite differencing should be done. By storing the current atom and coordinate (x,y or z) as private variables of the fix class, it is always known which is the next atom to process.

Since this is the first time I write an extension to LAMMPS I want to ask two questions:
  • Does this approach make sense, or is there a more clever/easier way of doing this?
  • How do I have to setup the actual Hessian matrix  (2d array) so that I can access it after the computation of the Hessian? The ideal case would be to extract it directly with the extract_fix method of the python interface.
​if you are already planning to do the processing from the python interface, why not do the bulk of the steps in python and only ​run LAMMPS in between with "run 0" to compute the forces?

axel.


 
Best

Johannes Dürholt
-- 
Johannes P. Dürholt
Computational Materials Chemistry Group
Chair of Inorganic Chemistry II, NC 02/32
Ruhr-Universität Bochum
Universitätsstr. 150
D-44780 Bochum
Germany

Tel.: +49-234-32-24372
E-mail: johannes.duerholt@...455...

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
lammps-users mailing list
lammps-users@...655....net
https://lists.sourceforge.net/lists/listinfo/lammps-users




--
Dr. Axel Kohlmeyer  akohlmey@...24...  http://goo.gl/1wk0
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.




--
Dr. Axel Kohlmeyer  akohlmey@...24...  http://goo.gl/1wk0
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
lammps-users mailing list
lammps-users@...655....net
https://lists.sourceforge.net/lists/listinfo/lammps-users




--
Giacomo Fiorin
Associate Professor of Research, Temple University, Philadelphia, PA
Contractor, National Institutes of Health, Bethesda, MD



--
Dr. Axel Kohlmeyer  akohlmey@...24...  http://goo.gl/1wk0
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.

-- 
Johannes P. Dürholt
Computational Materials Chemistry Group
Chair of Inorganic Chemistry II, NC 02/32
Ruhr-Universität Bochum
Universitätsstr. 150
D-44780 Bochum
Germany

Tel.: +49-234-32-24372
E-mail: johannes.duerholt@...455...