Hello,
I've gone through most of the bootcamp and made a list of several questions, comments and issues. I could answer most of the questions as I was going through the exercises, but some still remain. Although I've implemented (or collaorated on) quite a few simulation codes, I picked up nice new ideas from the KIM API that I never realized before. This is just great!
I must apologize because some of my questions below contain criticism, while I'm still an openkim n00b. I hope the criticism is useful. After all, I'm very fond of the entire project and I hope it becomes a giant success in the near future.
Toon,
Thanks for your comments. No need to apologize. We are excited to receive feedback and suggestions. I'll comment on things below.
Questions
---------
1) Can one give an example of a test where it is really mandatory to specify the neighbor lists in order to compute a physical observable?
This is a good but complicated question. In spirit, you are correct; neighbor lists are purely for computational efficiency. However, by including them in the api we avoid many other difficulties. For example, without neighbor lists we would have to create and define many ways to describe boundary conditions (orthogonal periodic box, general periodic box, general space group crystal specification, twist bc's, etc., etc., etc.) Each special case would need to be identified, a standard description defined, and the community would need to agree on the definition and description. Then EACH model (or its associated Model Driver) in the KIM system would need to be modified to support the new bc.
By using the general idea of neighbor lists and "contributing particles" we have adopted an abstraction that allows for support of a very wide range of situations. We believe that this will ultimately lead to a situation where the majority of KIM Models work with a majority of KIM Tests.
Unless some tests really need the neighbor lists to compute some physical quantity, it would be a lot easier to handle them completely in the model realm. It is good that the kim project provides some infrastructure for handling neighbor lists, and parameters describing the boundary conditions are unavoidable parts of the API. My point is that the API would just become a lot more attractive if the neighbor-list code were factored out and provided to model writers as an independent library. It would also make the tests easier to write because they don't have to worry about neighbor lists anymore. Other codes (ASE, CP2K, ...) that have a clear separation between PES model (DFT, force field, ...) and application (MD, MC, static computations, ...) typically keep the neighbor lists on the model side of the fence.
The trouble here is that the Model really shouldn't have to worry about how neighbor lists are **updated**. In fact, the Model can't know the best way to update a neighbor list. For example, in an MD Test the atoms typically move only a little bit between energy/force calculations. So, often neighbor lists can be updated only every n steps of integration. In contrast, in a Monte Carlo simulation the type of MC move determines if neighbor lists need to be updated. Some moves my require all neighbor lists to be updated, whereas others my require only certain lists to be updated. In short, our view is that the Test is the only entity that really knows how to efficiently construct and update the neighbor lists.
With that said, we plan to provide (in the near future and as part of the api distribution) a basic set of neighbor list routines. We hope this will address your concerns (and similar comments we have heard from others) in this regard.
2) How does one make good use of PARAM_FIXED_* in the model descriptor file? Can one give a typical example of a situation where these parameters are acessed by a test?
There is no general way for a Test to do this (because each Model is free to define whatever PARAM_FIXED_* values they like). However, consider the following. The Model Driver "wonky_pair_potential". This Model Driver takes three parameters: A, B, and C. From these three parameters it defines the pair interaction as a very complicated (especially for efficiency of numerical evaluation) functional form. The Model Driver stores free parameters: PARAM_FREE_A, PARAM_FREE_B, PARAM_FREE_C. To improve its numerical efficiency, the Model Driver creates a numeric spline of its pair function and stores the energy/distance values for each knot in the spline as part of the vector parameters PARAM_FIXED_knot_dist and PARAM_FIXED_knot_energy.
Now, a Test that is designed to work with "wonky_pair_potential" can take advantage of the knot values by accessing the PARAM_FIXED_knot_* arrays directly, BUT it should not change these values. Instead it should change the value of PARAM_FREE_{A,B,C} and let the wonky_pair_potential code regenerate the appropriate PARAM_FIXED_knots values.
3) Are periodic models without neighborlists supported, e.g. when the model takes care of its own neighbor lists or when it uses completely different approaches to evaluate energy, forces, virial, ...?
No. If there is enough interest and a strong enough argument (against the sort of thing I say above) for such a situation, we would be willing to add a new NBC that would support the situation of interest...
4) In the tests based on MiniMol (see bootcamp), a .kim descriptor file is written on the fly. Is this considered as a proper way to implement tests? It seems a bit awkward.
This is the "best" way to create what we would call a "KIM simulator". That is, a general purpose test (for example LAMMPS). For Tests that are meant to be part of the openkim.org automatic computation pipeline, this approach is not appropriate (here a static .kim file is required).
I agree that this is some awkwardness to the approach, but the alternative is to devise a separate hand-shaking system and we have concluded that this would be more complicated than the current approach.
Comments
--------
1) The shape of the Hessian in standard.kim is a bit unfortunate. [numberOfParticles,3,numberOfParticles,3] is more convenient. With such shape, one can easily recast the array into the shape [3*numberOfParticles,3*numberOfParticles], keeping the matrix elements contiguous in memory. This is useful when one wants to perform a vibrational analysis, i.e. compute eigenvalues and eigenvectors of the mass-weighted Hessian with a library (LAPACK) that requires some degree of contiguity.
Agreed. We plan to revise this in the future. Likely we will want to devise a way to use a more efficient storage data structure (sparse matrix or other format). The original idea for the current choice came from a "data locality" argument. That is, typically a Model will compute the 3x3 block of stiffness associated with two separate particles and store these before computing similar blocks for other particles. With the current structure these 3x3 blocks are contiguous and hopefully this reduces memory access.
2) Bootcamp exercises: rehash is not needed (nor existing) on Linux. Please add a note for those who are not familiar with OSX.
Yes, thanks. Actually this is a csh internal command that only needs to be used if you are running csh, tcsh, etc. Thanks for the comment. We'll update the docs.
Technical issues
----------------
1) The compilation of the KIM API on a 32 bit system fails. See attached make.log.
This only fails because you have not set the KIM_SYSTEM32 environment variable as described in the documentation.
The problem arises with the latest release as well as with the latest version from github. I noticed that the file KIM_API_F.F90 contains many preprocessor instructions (in most but not all routines) to switch between 32 and 64 bit integers depending on system architecture. That approach is rather hard to maintain throughout the entire file, which is also the reason why the compilation fails. It would be easier to define integer and real kinds only once to reduce the number of preprocessor switches. See for example the file kinds.F from the CP2K project:
http://cp2k.svn.sourceforge.net/viewvc/cp2k/trunk/cp2k/src/kinds.F?revision=12197&view=markup
This seems like a good suggestion. We'll look into it.
2) I ran into a gfortran cray pointer bug during the third exercise of the bootcamp. In the example ex_model_Ar_P_MLJ_MI_OPBC_H_F.F90, the line 'model_cutoff = model_Pcutoff' is ignored by gfortran 4.6.3 (Ubuntu 12.04) with -O3. Reverting to -O0 fixes the problem, but it is obviously not the ideal solution. I'll check if this bug is still present in newer versions of gfortran. Does someone have a better solution?
Yes. Actually we are aware of this. It is a gfortran bug. See this thread (http://gcc.gnu.org/ml/fortran/2012-06/msg00077.html) on the gfortran mailing list. There was not much success in identifying a good solution. We hope to move to Fortran 2003's C bindings soon.
3) I ran into a linker problem when testing the openkim-python package. It requires KIM_DYNAMIC=yes. The link line for the fortran model shared object files should contain -lgfortran and -ldl in the end. These arguments are put too early and hence they don't get included in the .so file, as can be seen with the ldd command:
ldd ex_model_Ar_P_LJ.so
linux-vdso.so.1 => (0x00007fffeb7ff000)
/home/toon/unief/research/code/ext/openkim-api-v1.1.0/KIM_API/libkim.so (0x00007fcce89c9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcce86a8000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcce8491000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcce80d4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcce7dda000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcce8e16000)
The output shows that libgfortran is ignored by the linker. This is the original linker line:
g++ -shared -lgfortran -ldl -o ex_model_driver_P_LJ.so *.o -L/home/toon/unief/research/code/ext/openkim-api-v1.1.0/KIM_API/ -lkim
This is the fixed one:
g++ -shared -o ex_model_driver_P_LJ.so *.o -L/home/toon/unief/research/code/ext/openkim-api-v1.1.0/KIM_API/ -lkim -lgfortran -ldl
This issue is on my list of items to explore and fix. Thanks for the details.