libatoms / quip Goto Github PK

A python code that uses purely ASE constructs (no explicit invocation of any quippy functionality) when operating on an atoms object that started as an ase.atoms but was converted to a quippy.atoms via
walkers = [quippy.Atoms(at) for at in walkers]
will leak memory in operations like
at.info['ns_energy'] = energy
(explicitly doing float(energy) doesn't help)
also leaks in
at.set_cell(new_cell, scale_atoms=True)

Reported by Max Veit:

This bug also results in a segmentation fault, but thankfully these are
the last of the segfaults I've come across so far.

Modifying an Atoms object within a dynamics hook (a function passed to
'DyamicalSystem.run()' that executes at a set interval) causes a
segmentation fault on the next dynamics step. It doesn't matter whether
the 'Atoms.remove_atoms()' or the 'DynamicalSystem.remove_atoms()'
function is used; each causes a segfault if it's called inside the hook.
The attached examples 'dynamics-hook-segv.py' and
'dynamics-althook-segv.py', respectively, demonstrate the error using
the above atom modification functions. Another interesting error arises
if the hook throws a particular exception after modifying the atoms. In
the attached example 'dynamics-hook-smash.py', Python exits with the
ominous message 'stack smashing detected' before triggering a segfault.

I'm aware that modifying Atoms objects inside a dynamics hook is
probably nonstandard usage; it would be more common to run dynamics,
stop, mutate the atoms, and run dynamics again. But even in this case
the user needs to take care: If the 'Atoms.remove_atoms()' function is
used instead of 'DynamicalSystem.remove_atoms()' (the latter apparently
updates the degrees of freedom correctly), again a segfault results, as
the attached example 'dynamics-between-segv.py' demonstrates.

To run the examples, place the file 'dodecane-bigcell.xyz' (same
structure as last time) in the same directory as the Python examples.
I'm also using a DFTB potential to run the dynamics so you'll need to
place a DFTB parameter file in the same directory as the Python examples
and name it 'dftb_params.xml'. The DFTB parameters can be found in the
ThirdParty directory; I used
"$QUIP_ROOT/ThirdParty/DFTB-parameters/self_consistency.DFTB.pbc-0-1.xml".
I haven't tested these examples with other potentials, though that could
also be useful.

Traceback (most recent call last):
File "run-model-test.py", line 42, in
import test # import and run the current test
File "../tests/liquid/test.py", line 58, in
dyn_equil = quippy.Dynamics(bulk, 1.0*ase.units.fs, trajectory=None)
File "/usr/local/quip/2015-06-03/mkl/lib64/python/quippy/dynamicalsystem.py", line 159, in init
if abs(self.atoms.mass/MASSCONVERT - self.atoms.get_masses()) > 1e-3:
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

AtomsWriter("stdout") used to work, and defaulted to extxyz format. Now it is unable to figure out what format to use, so it fails. I suspect this has to do with integration of ASE's I/O routines.

tin 1001 : python
Python 2.7.10 (default, Nov 19 2015, 09:31:54)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

from quippy import AtomsWriter
aw = AtomsWriter("t.xyz")
aw = AtomsWriter("stdout")
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/quip/2015-12-17/mkl/lib/python/quippy/io.py", line 587, in AtomsWriter
raise ValueError("Don't know how to write Atoms to format %r" % format)
ValueError: Don't know how to write Atoms to format 'stdout'

Hello,

I am trying to understand how exactly the energy of a group of atoms is calculated given an input of the atomic structure and the potential. From what I understand, after the potential is defined (pot = Potential(...)), this is executed as the pot.calc(a,'energy=energy') method (or something similar).

Would you be able to please point me to which exact file has this subroutine with the actual lines that do this calculation at the lowest level?

Thanks,
Anne

I have some configurations that have picked up a 'cutoff_factor' that are causing issues when converting into quippy Atoms:

>>> from ase.lattice.bulk import bulk
>>> from quippy import Atoms
>>> b = bulk('Fe')
>>> b.info['cutoff_factor'] = 1.2
>>> a = Atoms(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/tdd20/.local/lib64/python2.7/site-packages/quippy/atoms.py", line 406, in __init__
    self.copy_from(symbols)
  File "/home/tdd20/.local/lib64/python2.7/site-packages/quippy/atoms.py", line 734, in copy_from
    self.set_cutoff_factor(other.info['cutoff_factor'],
  File "/home/tdd20/.local/lib64/python2.7/site-packages/quippy/atoms.py", line 779, in __getattr__
    raise AttributeError('Unknown Atoms attribute %s' % name)
AttributeError: Unknown Atoms attribute set_cutoff_factor

The call is in:

quippy/quippy/atoms.py
733:                if 'cutoff_factor' in other.info:
734:                    self.set_cutoff_factor(other.info['cutoff_factor'],
735:                                           other.info.get('cutoff_factor_break'))

There are a few other spots still trying to call that method (I was confused because there is one in test that wasn't failing but that test it disabled):

% ag set_cutoff_factor
src/Potentials/IPModel_BOP.f95
766:!!$       call set_cutoff_factor(aa, a%cutoff)

tests/test_electrostatic_embed.py
123:       cluster2.set_cutoff_factor(1.2)
145:       cluster.set_cutoff_factor(1.2)

quippy/examples/quartz-strain.py
131:   aqc.set_cutoff_factor(1.2)

quippy/quippy/crack.py
760:    tmp_atoms.set_cutoff_factor(nneightol)

quippy/quippy/plot3d.py
56:    at.set_cutoff_factor(cutoff_factor)

quippy/quippy/cp2k.py
410:    at_avg.set_cutoff_factor(1.2)

quippy/quippy/atoms.py
734:                    self.set_cutoff_factor(other.info['cutoff_factor'],

Can these just be removed?

Reported by Gabor:

quip cij fails with Invalid linminroutine: default. If I give linmin_method=NR_LINMIN then it works. changing to minim_method=precond doesn't work either. I can see in line 416 of quip.f95 where the "default" is supposed to be dispatched, but it doesn't work.

First, was this method (in Atoms_types.f95, or the Python-wrapped version in quippy.atoms.Atoms) ever designed to be called again on an Atoms object after atoms were removed from it (using remove_atoms())? If not, this would be useful for me to have; any idea of how difficult it would be to support this usage?

Reported by Ole Schütt: I found that for some reason one can not build QUIP in parallel with "make -j".

Part of the problem seems to be the implicit state associated with copying the Makefile for the current target into the build/ directory.

I've come across a bug that only came up when I was running with quip md (the Fortran md program) but not when running with quippy.DynamicalSystem - turns out, the two methods have a different default cutoff_skin (0.0 Å in quippy, 0.5 Å in quip). I'm still working on reproducing the (fairly spectacular) bug caused by the quip cutoff skin, but in the meantime:

I think it would be a good idea to unify defaults (and maybe trickier things, like available thermostats and minimization methods) across quippy and quip, if only for the sake of reproducibility when moving from one system to the other. My expectation was that I could translate the parameters from a quip md script, put them into the python system, and have the exact same simulation. But because of the discrepancy in the defaults, that expectation was (in this case, jarringly) violated.

I remember that there used to be a make target that would pull together all the f90doc output of the source into a pdf. Some of this info is made available in the quippy docs, but there is a lot of documentation in QUIP that is now only accessible by looking at the source code.

I think it would be worth trying to integrate the libatoms/QUIP documentation into the Sphinx docs for quippy and getting it all online. Including things like docs for all the different xml formats (i.e. issue #50) would make life easier for newcomers too.

I'm not sure if this is best described as a QUIP or ASE I/O issue, but if you use the ASE extxyz writer to create a file for an atoms object that has an info entry which has value None, QUIP (e.g. convert.py) can't read it. The info entry becomes a bare word in the comment line (KEmax below), which is apparently not parseable.

tin 1027 : cat t.py

#!/usr/bin/env python

import ase, ase.io

a = ase.Atoms('CO', positions=[(0, 0, 0), (0, 0, 1)])

a.info['KEmax'] = None

ase.io.write("tt.xyz", a, format="extxyz")

tin 1028 : python t.py
tin 1029 : cat tt.xyz

2
Lattice="1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0" Properties=species:S:1:pos:R:3:Z:I:1 KEmax pbc="F F F"
C      0.00000000       0.00000000       0.00000000        6 
O      0.00000000       0.00000000       1.00000000        8 

tin 1030 : convert.py tt.xyz -

Usage: convert.py [options] ( <input file> [ <output file> ] | <input file> [ <input file> ... ] [ (-o|--output) <output file> ] )

convert.py: error: Traceback (most recent call last)
  File "/usr/local/quip/src/QUIP/src/libAtoms/xyz.c", line 732 kind IO
    Badly formed key/value pair KEmax                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         ```

Hello,
I am haing errors when trying to run the "make" command to install QUIP and quippy in Ubuntu. Is there a preferred Linux operating system that it was made to be used in aside from Ubuntu? Alternatively, is there anything I am doing wrong trying to compile it in Ubuntu? I took the following steps as said in the documentation:

1. In the "arch" folder: export **QUIP_ARCH=linux_x86_64_ifort_icc**

2. In the QUIP main folder: **make config**

3. In the QUIP main folder: **make**

And am recieving this error after the make command:

**Using QUIP_ARCH=linux_x86_64_ifort_icc, MODULES= libAtoms Potentials Utils Programs FilePot_drivers Structure_processors, QUIP_ROOT=/home/anne/Desktop/QUIP
cp Makefile.fox src/fox/Makefile.QUIP
make -C src/fox -I/home/anne/Desktop/QUIP -I/home/anne/Desktop/QUIP/arch -I/home/anne/Desktop/QUIP/build/linux_x86_64_ifort_icc -f Makefile.QUIP
make[1]: Entering directory '/home/anne/Desktop/QUIP/src/fox'
if [[ -e arch.make ]]; then make distclean; fi && rm -rf objs.linux_x86_64_ifort_icc && FCFLAGS="-fPIC" FC="ifort" CC="icc" /bin/bash ./configure --disable-dom && make && mv objs objs.linux_x86_64_ifort_icc
/bin/sh: 1: [[: not found
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for linker flag to name executables... configure: error: Could not determine flag to name executables
See `config.log' for more details.
Makefile.QUIP:29: recipe for target 'foxlibs' failed
make[1]: *** [foxlibs] Error 1
make[1]: Leaving directory '/home/anne/Desktop/QUIP/src/fox'
Makefile:116: recipe for target 'src/fox/objs.linux_x86_64_ifort_icc/lib/libFoX_common.a' failed
make: * [src/fox/objs.linux_x86_64_ifort_icc/lib/libFoX_common.a] Error 2

Python 2.6 has been end of life for three and a half years. I propose removing it from the testing and no longer making an effort to support it. Code can then use new features as and when needed.

All of the packages that quippy uses have moved on:

• pip now complains when using 2.6
• f90wrap minimum version is 2.7
• ase are drop support for 2.6
• numpy has dropped support for 2.6

Many features of 2.7 will make porting to Python 3 less painful.

The only place that one is likely to still see Python 2.6 as the default these days is in CentOS/RedHat 6 (which will apparently be supported until 2020!), but I suggest directing those users to Anaconda.

currently the string method only works with a fixed step size steepest descent minimizer, which sucks big time. we should implement the conjugate gradient version. I tried the simple two-point-descent algorithm but, unsurprisingly, it didn't work because projecting out the parallel component screwed up the rank-1 estimate of the hessian. maybe there is a way to do it though?

If you have an Atoms object with masses that don't match the default for the atomic numbers, creating a DynamicalSystem from that atoms object resets the masses to those from PeriodicTable.f95 ElementMass[] for that atomic number. See the following script.

import quippy, sys, ase

at = quippy.Atoms(ase.io.read(sys.argv[1]))
at.write("stdout")

at.add_property('mass', 0.0)
at.mass[:] = at.get_masses()*quippy.MASSCONVERT

print "at.mass ", at.mass
ds=quippy.DynamicalSystem(at)
print "ds.atoms.mass ", ds.atoms.mass

Example input:

2
Lattice="6.0 0.0 0.0     0.0 6.0 0.0     0.0 0.0 6.0" Properties=species:S:1:pos:R:3:momenta:R:3:force:R:3:masses:R:1
O 0.0 0.0 0.0 0.1 0.0 0.0     0.0 0.0 0.0   1.0
O 2.0 0.0 0.0 -0.1 0.0 0.0     0.0 0.0 0.0   1.0

Example output:
tin 1122 : ./test_mass.py t.extxyz

2
cutoff=-1.00000000 nneightol=1.20000000 pbc="T T T" Lattice="6.00000000       0.00000000       0.00000000       0.00000000       6.00000000       0.00000000       0.00000000       0.00000000       6.00000000" Properties=species:S:1:pos:R:3:masses:R:1:momenta:R:3:force:R:3:Z:I:1
O               0.00000000      0.00000000      0.00000000      1.00000000      0.10000000      0.00000000      0.00000000      0.00000000      0.00000000      0.00000000       8
O               2.00000000      0.00000000      0.00000000      1.00000000     -0.10000000      0.00000000      0.00000000      0.00000000      0.00000000      0.00000000       8
at.mass  [ 103.64272176  103.64272176]
ds.atoms.mass  [ 1658.2213769  1658.2213769]

Dear Sirs,

I want to use ASE calculator with QUIP's DFTB through ForceMixingPotential(). At the beginning of this try, simple energy calculator with Potential(calculator=EMT) was tested but I got a error below.

Could you give me advises or pointers?

Thank you very much

tetsu911

from ase.build import bulk
from quippy.potential import Potential
from ase.calculators.emt import EMT
c = bulk('C', a=3.57, cubic=True)
tersoff_pot = Potential('IP Tersoff')
c.set_calculator(tersoff_pot)
c.get_potential_energy()
emt_pot = Potential(calculator=EMT)
c.set_calculator(emt_pot)
c.get_potential_energy()

WARNING: Potential_calc: cutoff of Atoms object (-1.00000000000000000) < Potential cutoff (3.10000000000000009) - increasing it now
WARNING Callbackpot_calc: "energy" requested but not returned by callback
capi_return is NULL
Call-back cb_qp_callback_in_qp_potential_set_callback__user__routines failed.
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/IPython/core/interactiveshell.py", line 2869, in run_code
exec(code_obj, self.user_global_ns, self.user_ns)
File "", line 10, in
c.get_potential_energy()
File "/usr/local/lib/python2.7/dist-packages/ase/atoms.py", line 676, in get_potential_energy
energy = self._calc.get_potential_energy(self)
File "/usr/local/lib/python2.7/dist-packages/ase/calculators/calculator.py", line 422, in get_potential_energy
energy = self.get_property('energy', atoms)
File "/usr/local/lib/python2.7/dist-packages/ase/calculators/calculator.py", line 461, in get_property
self.calculate(atoms, [name], system_changes)
File "/usr/local/lib/python2.7/dist-packages/quippy/potential.py", line 366, in calculate
self.calc(self.quippy_atoms, args_str=dict_to_args_str(calc_args))
File "/usr/local/lib/python2.7/dist-packages/quippy/potential.py", line 255, in calc
args_str, error)
File "/usr/local/lib/python2.7/dist-packages/quippy/oo_fortran.py", line 852, in
wrapmethod = lambda name: lambda self, *args, **kwargs: self._runroutine(name, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/quippy/oo_fortran.py", line 570, in _runroutine
res = fobj(*newargs, **newkwargs)
File "/usr/local/lib/python2.7/dist-packages/quippy/potential.py", line 271, in callback
Potential.callback_mapat.params['label']
File "/usr/local/lib/python2.7/dist-packages/quippy/potential.py", line 47, in callback
at.params['energy'] = at.get_potential_energy()
File "/usr/local/lib/python2.7/dist-packages/ase/atoms.py", line 676, in get_potential_energy
energy = self._calc.get_potential_energy(self)
TypeError: unbound method get_potential_energy() must be called with EMT instance as first argument (got Atoms instance instead)

This is in my template cell file:

---------- cut here ---------
kpoints_mp_spacing 0.020

symmetry_generate

%BLOCK SPECIES_POT
Al 2|1.2|23|26|29|20U:21U:30:31(qc=8)
%ENDBLOCK SPECIES_POT
----------- cut here ------------

This is a really weird bug. Take the small xyz file below, and try to relax it including the lattice. it will fail. If you remove the "force" property from the input file, which should have absolutely nothing to do with the calculation, then it works. If the lattice is not relaxed, then it also works. the command line below has the LJ potential, but the bug exists for all potentials.

here is the command line:

/Code/QUIP/build/darwin_x86_64_gfortran/quip at_file=tmp.xyz param_file=/Code/QUIP/share/Parameters/ip.parms.LJ.xml E F V init_args={IP LJ} calc_args={force_using_fd virial_using_fd} relax relax_tol=1e-14

and here is the input file structure :

4
Lattice="3.01484186 -0.00000000 0.00000000 -0.00000107 4.40909241 -0.00000073 0.00000059 -0.00000000 4.02186270" Properties=species:S:1:pos:R:3:force:R:3
Ag 0.12280690 3.26263582 0.78350571 0 0 0
Ag 2.88503883 1.05808959 2.79443636 0 0 0
Ag 1.33694608 1.05808980 0.78350545 0 0 0
Ag 1.67089963 3.26263560 2.79443662 0 0 0

Sorry that this only just got discovered. I'm also trying to fix the Intel test server as it seems to be unable to send emails anymore.

========== last 20 lines of /opt/quip/report.ifort-11.1.069.linux_x86_64_ifort_gcc.ALL.QUIP_build.faillog ==========                                        
  subroutine c_dictionary_add_key                                                                                                                           
  subroutine c_extendable_str_concat                                                                                                                        
make[1]: Leaving directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_gcc'                                                                                
make[1]: Entering directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_gcc'                                                                               
ifort   -fpp -fixed -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_gcc/finclude -I/usr/include -O3 -vec-report0 -fPIC -DPOTENTIAL_NO_DEFAULT_PRIVATE -DDUMP_CORE_ON_ABORT -DGETARG_F2003 -DFORTRAN_UNDERSCORE -DF2008 -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_gcc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c /scratch/quip/QUIP/src/libAtoms/lbfgs.f -o lbfgs.o                                                                                                                                                       
ifort  -fpp -free -warn unused -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_gcc/finclude -I/usr/include -O3 -vec-report0 -fPIC -DPOTENTIAL_NO_DEFAULT_PRIVATE -DDUMP_CORE_ON_ABORT -DGETARG_F2003 -DFORTRAN_UNDERSCORE -DF2008 -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_gcc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c -Tf /scratch/quip/QUIP/src/libAtoms/error.f95 -o error.o                                                                                                                                      
ifort  -fpp -free -warn unused -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_gcc/finclude -I/usr/include -O3 -vec-report0 -fPIC -DPOTENTIAL_NO_DEFAULT_PRIVATE -DDUMP_CORE_ON_ABORT -DGETARG_F2003 -DFORTRAN_UNDERSCORE -DF2008 -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_gcc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c -Tf /scratch/quip/QUIP/src/libAtoms/System.f95 -o System.o                                                                                                                                    
/scratch/quip/QUIP/src/libAtoms/System.f95(1912): error #6185: This constant is out-of-range in a format list.   [0]                                        
       write(tmp,'(g0.17)') r                                                                                                                               
--------------------^                                                                                                                                       
/scratch/quip/QUIP/src/libAtoms/System.f95(2978): remark #7712: This variable has not been used.   [COMM]                                                   
  subroutine parallel_print(lines, comm, verbosity, file)
-----------------------------------^
/scratch/quip/QUIP/src/libAtoms/System.f95(1990): remark #7712: This variable has not been used.   [COMM]
  subroutine get_mpi_size_rank(comm, nproc, rank)
-------------------------------^
compilation aborted for /scratch/quip/QUIP/src/libAtoms/System.f95 (code 1)
make[1]: *** [System.o] Error 1
make[1]: Leaving directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_gcc'
make: *** [libAtoms] Error 2


========== last 20 lines of /opt/quip/report.ifort-11.1.069.linux_x86_64_ifort_icc.ALL.QUIP_build.faillog ==========
  subroutine c_dictionary_add_key
  subroutine c_extendable_str_concat
make[1]: Leaving directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc'
make[1]: Entering directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc'
ifort   -fpp -fixed -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c /scratch/quip/QUIP/src/libAtoms/lbfgs.f -o lbfgs.o
ifort  -fpp -free -warn unused -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c -Tf /scratch/quip/QUIP/src/libAtoms/error.f95 -o error.o
ifort  -fpp -free -warn unused -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c -Tf /scratch/quip/QUIP/src/libAtoms/System.f95 -o System.o
/scratch/quip/QUIP/src/libAtoms/System.f95(1912): error #6185: This constant is out-of-range in a format list.   [0]
       write(tmp,'(g0.17)') r
--------------------^
/scratch/quip/QUIP/src/libAtoms/System.f95(2978): remark #7712: This variable has not been used.   [COMM]
  subroutine parallel_print(lines, comm, verbosity, file)
-----------------------------------^
/scratch/quip/QUIP/src/libAtoms/System.f95(1990): remark #7712: This variable has not been used.   [COMM]
  subroutine get_mpi_size_rank(comm, nproc, rank)
-------------------------------^
compilation aborted for /scratch/quip/QUIP/src/libAtoms/System.f95 (code 1)
make[1]: *** [System.o] Error 1
make[1]: Leaving directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc'
make: *** [libAtoms] Error 2


========== last 20 lines of /opt/quip/report.ifort-11.1.069.linux_x86_64_ifort_icc_mpi.ALL.QUIP_build.faillog ==========
  subroutine c_dictionary_initialise
  subroutine c_dictionary_finalise
  subroutine c_dictionary_get_n
  subroutine c_dictionary_get_key
  subroutine c_dictionary_query_key
  subroutine c_dictionary_query_index
  subroutine c_dictionary_add_key
  subroutine c_extendable_str_concat
make[1]: Leaving directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc_mpi'
make[1]: Entering directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc_mpi'
mpif77    -fpp -fixed -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc_mpi/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D_MPI -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc_mpi"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c /scratch/quip/QUIP/src/libAtoms/lbfgs.f -o lbfgs.o
mpif90   -fpp -free -warn unused -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc_mpi/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D_MPI -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc_mpi"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c -Tf /scratch/quip/QUIP/src/libAtoms/error.f95 -o error.o
mpif90   -fpp -free -warn unused -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc_mpi/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D_MPI -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc_mpi"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c -Tf /scratch/quip/QUIP/src/libAtoms/System.f95 -o System.o
/scratch/quip/QUIP/src/libAtoms/System.f95(1912): error #6185: This constant is out-of-range in a format list.   [0]
       write(tmp,'(g0.17)') r
--------------------^
compilation aborted for /scratch/quip/QUIP/src/libAtoms/System.f95 (code 1)
make[1]: *** [System.o] Error 1
make[1]: Leaving directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc_mpi'
make: *** [libAtoms] Error 2


========== last 20 lines of /opt/quip/report.ifort-11.1.069.linux_x86_64_ifort_icc_openmp.ALL.QUIP_build.faillog ==========
make[1]: Entering directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc_openmp'
ifort   -fpp -fixed -fPIC -openmp -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc_openmp/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D_OPENMP -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc_openmp"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c /scratch/quip/QUIP/src/libAtoms/lbfgs.f -o lbfgs.o
fpp: warning: macro redefined: _OPENMP
ifort  -fpp -free -warn unused -fPIC -openmp -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc_openmp/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D_OPENMP -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc_openmp"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c -Tf /scratch/quip/QUIP/src/libAtoms/error.f95 -o error.o
fpp: warning: macro redefined: _OPENMP
ifort  -fpp -free -warn unused -fPIC -openmp -fPIC -I/scratch/quip/QUIP/src/libAtoms -I/scratch/quip/QUIP/src/fox/objs.linux_x86_64_ifort_icc_openmp/finclude -I/usr/include -O3 -g -traceback -DDUMP_CORE_ON_ABORT  -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D_OPENMP -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,8822f23-dirty"' -D'GAP_VERSION=1486072683' -D'QUIP_ARCH="linux_x86_64_ifort_icc_openmp"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_FX -DHAVE_GAP_FILLER -DHAVE_GAP -DHAVE_TB -DHAVE_QR -DHAVE_LOTF -DHAVE_CP2K -DHAVE_ONIOM -DHAVE_LOCAL_E_MIX -DHAVE_THIRDPARTY  -c -Tf /scratch/quip/QUIP/src/libAtoms/System.f95 -o System.o
fpp: warning: macro redefined: _OPENMP
/scratch/quip/QUIP/src/libAtoms/System.f95(1912): error #6185: This constant is out-of-range in a format list.   [0]
       write(tmp,'(g0.17)') r
--------------------^
/scratch/quip/QUIP/src/libAtoms/System.f95(2978): remark #7712: This variable has not been used.   [COMM]
  subroutine parallel_print(lines, comm, verbosity, file)
-----------------------------------^
/scratch/quip/QUIP/src/libAtoms/System.f95(1990): remark #7712: This variable has not been used.   [COMM]
  subroutine get_mpi_size_rank(comm, nproc, rank)
-------------------------------^
compilation aborted for /scratch/quip/QUIP/src/libAtoms/System.f95 (code 1)
make[1]: *** [System.o] Error 1
make[1]: Leaving directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc_openmp'
make: *** [libAtoms] Error 2

We call split_string in teach_sparse.f95:
call split_string(descriptor_str,':','{}',main_teach_sparse%descriptor_str(:),main_teach_sparse%n_coordinate,matching=.true.)

This finds the delimiters correctly (i.e. it will not consider other ":"-s nested in descriptors as delimiters), but in the process it removes nested "{}"-s, within the correctly found fields. That causes problems later, when other parts of the code try to interpret the fields.

In theory, the Sum potential should support things like differences as well by simply scaling one of the potentials by -1. In practice, it's not so easy; many potentials don't, in fact, support the E_scale parameter (among them FilePot and GAP), and passing do_rescale_E E_scale=-1.0 either in a Sum or in a simple Potential init args string is silently ignored.

I'm proposing to add separate scaling factors, e.g. E_scale_pot1 and E_scale_pot2, to the init args of the Sum potential in Potential_Sum_routines.f95. I'm not sure whether it's appropriate to reuse the E_scale name, though, since I'm still not sure exactly what it's for -- in Potential.f95, there's even some sort of connection to a target volume or bulk modulus, when all I want is to multiply the energy by a simple scale factor.

First, I learned a 2-body potential (GAP) with "teach_sparse" for the H2 molecule with potential form "distance_Nb" with "order=2".
Then I wanted to use this potential to calculate the energy for other distances, but quip crashes when the distance is larger than the cutoff set for the learning.

Seems like it is trying to make something in the Fortran main() too.

quip_wrapper_simple_example_C.o: In function `main':
/scratch/quip/QUIP/src/Programs/quip_wrapper_simple_example_C.c:6: multiple definition of `main'
/opt/intel/Compiler/11.1/069/lib/intel64/for_main.o:/export/users/nbtester/efi2linux_nightly/branch-11_1/20100204_010000/libdev/frtl/src/libfor/for_main.c:(.text+0x0): first defined here
/opt/intel/Compiler/11.1/069/lib/intel64/for_main.o: In function `main':
/export/users/nbtester/efi2linux_nightly/branch-11_1/20100204_010000/libdev/frtl/src/libfor/for_main.c:(.text+0x38): undefined reference to `MAIN__'
make[1]: *** [quip_wrapper_simple_example_C] Error 1
make[1]: Leaving directory `/scratch/quip/QUIP/build/linux_x86_64_ifort_icc_mpi'
make: *** [Programs] Error 2

This fairly standard tool checks Python code for a number of common syntax derps and logic errors (such as undefined names and missing imports, things that wouldn't be obvious at first glance). It's no substitute for better test coverage but it catches the small errors much more quickly.

By default, the pylint tool spews lots of information about minor stylistic nonconformities as well, but maybe we can run it in errors-only mode at first. It seems there's also a way to suppress the few spurious errors it reports for quippy modules.

The bin/gapversion.sh script only tests gp_predict.f95 in the src/GAP directory. I assume it should also include some of the other files descriptors.f95, descriptors_wrapper.f95 and make_permutations_v2.f95, or is there some reason why it skips those?

This would be in addition to the specific formats which are currently delegated to the ASE reader (e.g .db, .json).

Currently this only happens when System.f95 is rebuilt, which is not very often. We should make a separate module which is always recompiled.

It would be nice if it did, for compatibility with ASE.

Thanks to Pétur Bryde for reporting

======================================================================
FAIL: test_to_atoms_frac_pos (test_castep.TestCastepCell)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/petur/prog/QUIP/tests/test_castep.py", line 198, in test_to_atoms_frac_pos
    self.assertEqual([x.split() for x in c['POSITIONS_FRAC']], [x.split() for x in c2['POSITIONS_FRAC']])
  File "/home/petur/prog/QUIP/tests/quippytest.py", line 62, in assertEqual
    self.fail('%s != %s' % (a,b))
AssertionError: [['O', '0.414382', '0.259186', '0.792179'], ['O', '-0.259186', '0.155196', '1.458845'], ['O', '-0.155196', '-0.414382', '1.125512'], ['O', '0.259186', '0.414382', '-0.792179'], ['O', '-0.414382', '-0.155196', '-0.125512'], ['O', '0.155196', '-0.259186', '-0.458845'], ['Si', '0.474452', '0.000000', '0.666667'], ['Si', '0.000000', '0.474452', '0.333333'], ['Si', '-0.474452', '-0.474452', '0.000000']] != [['O', '0.414382', '0.259186', '0.792179'], ['O', '-0.259186', '0.155196', '1.458845'], ['O', '-0.155196', '-0.414382', '1.125512'], ['O', '0.259186', '0.414382', '-0.792179'], ['O', '-0.414382', '-0.155196', '-0.125512'], ['O', '0.155196', '-0.259186', '-0.458845'], ['Si', '0.474452', '-0.000000', '0.666667'], ['Si', '-0.000000', '0.474452', '0.333333'], ['Si', '-0.474452', '-0.474452', '0.000000']]

======================================================================
FAIL: testminim (test_potential.TestPotential_ElasticMinim)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/petur/prog/QUIP/tests/test_potential.py", line 5064, in testminim
    self.assertArrayAlmostEqual(self.at.lattice, self.lat_ref)
  File "/home/petur/prog/QUIP/tests/quippytest.py", line 91, in assertArrayAlmostEqual
    self.fail('Maximum abs difference between array elements is %e at location %r' % (absdiff.max(), loc))
AssertionError: Maximum abs difference between array elements is 4.937909e-07 at location [3, 3]

======================================================================
FAIL: test_md_velo.sh (test_shell_scripts.Test_TopLevel)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/petur/prog/QUIP/tests/test_shell_scripts.py", line 47, in run_script
    self.fail()
AssertionError: None

This is low-priority, sure, but it'll need to be fixed if we want Python 3 compatibility (as all strings are unicode by default in py3k). Unicode strings break a variety of constructors for quippy objects; for example, the following code:

from __future__ import unicode_literals
import quippy

pot = quippy.Potential('IP GAP', param_filename='../dimers/gp-merig-ljrep-2b.xml')

throws a TypeError, more specifically,

TypeError: No matching routine found in interface __init__

while replacing it with the following works fine:

pot = quippy.Potential(b'IP GAP', param_filename='../dimers/gp-merig-ljrep-2b.xml')

so it looks like filenames are unaffected.
The error does occur in param strings as well, though; the following again raises the error:

pot = quippy.Potential(b'IP LJ', param_str=u"""
<LJ_params n_types="1" label="default">
<per_type_data type="1" atomic_num="18" />
<per_pair_data type1="1" type2="1" sigma="4.0" eps6="1.0" eps12="1.0" cutoff="6.0" energy_shift="T" linear_force_shift="F" />
</LJ_params>""")

The simplest fix would be to convert all offending strings to bytes in Python 3, str in Python 2; there's some advice here on making it work in both so we don't have to maintain two separate codebases.

There are many cases where one might want to use a potential with a zero cutoff. For instance, in FilePot.f95, the function cutoff() always returns zero. This causes problems whenever quippy.Potential.update() is called, since that function sets the attached Atoms object's cutoff to the value of self.cutoff(), which is zero. Two lines later it calls atoms.calc_connect(), which throws an error due to the check in Connection::connection_calc_connect() that the cutoff not be zero.

I only recently noticed this because of the combination of using a FilePot and calling a function (atoms.set_calculator(pot)) that triggers quippy.potential.update(). There are a few fixes I can think of:

• Don't throw an error if Connection::calc_connect() is called with a zero cutoff. This would make me happy because I've come into numerous other situations where, for one reason or another, the cutoff is set to zero but calc_connect() is still erroneously called. However, I'm assuming that error was there for a reason, so there may be other unforeseen consequences of demoting this error to a warning.
• Don't call calc_connect() in quippy.potential.update() if the cutoff is zero. This is a simple fix, but there may be other places in quippy where calc_connect() is erroneously called on a zero cutoff.
• Don't change the cutoff in quippy.potential.update() if the the attached Atoms's cutoff is greater than the Potential's cutoff (indicating that the Atoms cutoff was manually set earlier).

Any input would be appreciated.

I'm reading an xyz from another user's directory, where I have read but not write permissions. Mostly the xyz reader handles that OK, creating .idx files in my current directory, but in one case there's already an idx file in the same directory as the xyz file, but I have read permission only for the xyz. This fails with an error
Index file /home_cluster1/ksalerno/repo/protein/single-ubq/nve-ni8-nmce40960-nwalkers2304-at8-4/rundir/poly-ubq-ni8-nmce40960-nwalkers2304-at8-nve-lammps-n1.traj.0.extxyz.idx cannot be opened
There's probably a check for an existing idx file which should be replaced with a check for an existing and readable idx file.

Current issues with our run_suffix scheme:

1. Should we replace =mm= and =qm= with =fast= and =slow=?
2. What else (if anything) will have to be changed to be consistent?
   other `metapotentials' should also append stuff to =run_suffix=,
   e.g. castep_driver and vasp_driver
3. If an EVB Potential is used to make two separate =run_suffix=
   values, =cp2k_driver= will save two sets of wavefunctions
   (increasing disk usage, and slowing things down a bit if, for
   example, there's an EVB outside the QM region of a QM/MM). Do
   we care? Could be addressed similar to cp2k_state_change()

Some operating systems (like Arch Linux) have Python 3 as their default, meaning python refers to the Python 3 executable. The file quippy/setup.py is written in Python 2 and contains things like unparenthesized print statements that cause Python 3 to fail.

I would like to change the change the rules in the makefiles quippy/Makefile and tests/Makefile to use the executable python2 intstead of python, since (I think) even on Python-2-only systems, the executable python2 is still present. Would this change cause problems for anyone?

I'm using the neighbour functions to only return neighbours within a certain distance using the max_dist parameter of Connection::(n_)neighbour(s). If the effective cutoff (including cutoff_skin) is greater than that distance, instead of getting only the neighbours within that distance, I occasionally also get zero indices and (much worse) missing neighbours. I'm using the following, completely logical paradigm, which is what the documentation would seem to suggest:

n = at.n_neighbours(idx, max_dist=d)
for i in range(n):
    print(at.neighbour(idx, i+1, max_dist=d)

Since the internal neighbour list is apparently not sorted by distance - at least, that's what I'm inferring, since the above loop seems to return them in no particular order - this means that the above iteration over a subset of the neighbours can actually miss some neighbours that were, in fact, within the range max_dist.

To reproduce, use the following code:

#vim set encoding=utf-8
"""Reproduce the quippy neighbour inconsistency with max_dist"""

from quippy import Atoms, Potential

at = Atoms('methane-box.xyz')
at.set_cutoff(1.5, 0.5)

pot = Potential('IP LJ', param_filename='lj_bogus.xml')

pot.calc(at, energy=True, force=True)

idx_test = 296
print("Number of neighbours of atom {:d} is {:d}".format(
      idx_test, at.n_neighbours(idx_test)))
print("Neighbours of atom {:d} are: ".format(idx_test) +
      ', '.join(str(at.neighbour(idx_test, i+1))
                for i in range(at.n_neighbours(idx_test))))

print("---- Now with max_dist ----")

print("Number of neighbours of atom {:d} _within 1.5 Å_ is {:d}".format(
      idx_test, at.n_neighbours(idx_test, max_dist=1.5)))
print("Neighbours of atom {:d} _within 1.5 Å_ are: ".format(idx_test) +
      ', '.join(str(at.neighbour(idx_test, i+1, max_dist=1.5))
                for i in range(at.n_neighbours(idx_test, max_dist=1.5))))

with the geometry
methane-box.xyz (be sure to remove the .txt extension).

The potential itself isn't important as long as it has a cutoff of 1.5 Å - try the following bogus LJ parameters, saved into lj_bogus.xml:

<!-- Some made-up params to vaguely keep a methane molecule together -->
<!-- DO NOT USE for any sort of production simulation! -->
<LJCONF>
    <Potential label="ljconf" init_args="IP LJ"/>
    <LJ_params n_types="2" only_inter_resid="T" label="ljconf-lj">
    <per_type_data type="1" atomic_num="1" />
    <per_type_data type="2" atomic_num="6" />
    <per_pair_data type1="1" type2="2" sigma="0.971" eps6="5.0" eps12="5.0" cutoff="1.5" energy_shift="T" linear_force_shift="T" />
    </LJ_params>
</LJCONF>

Travis builds all configurations for all pushes. During peak times, this can take nearly four hours, which is not ideal for checking in small changes. Break the builds into two sets:

Regular builds (9 total configurations ~ 30 mins on a good day):

• Python 2.7
• Default GCC 4.6
• VANILLA, ALL_NOEXTERNAL, and ALL configurations
• gfortran, gfortran_openmp, gfortran_openmpi

'Weekly' builds:

• Python 2.7, 2.6
• Default GCC 4.4, 4.6, (4.9?), 5
• VANILLA, ALL_NOEXTERNAL, and ALL configurations
• gfortran, gfortran_openmp, gfortran_openmpi

Weekly builds could be triggered and separated by restarting the last build on Sunday night and putting logic to skip certain builds if it is not overnight on Sunday.

Could also force building of all configurations if the last build failed?

@albapa I'm not sure if you can just remove the allocatable?

/home/travis/build/libAtoms/QUIP/src/libAtoms/LinkedList.f95:48.33:
     integer, allocatable :: data
                                 1
Error: Allocatable component at (1) must be an array
make[1]: *** [LinkedList.o] Error 1
make: *** [libAtoms] Error 2

It's incredibly frustrating as a new user of a potential to try to figure out what XML format will initialize it properly. For instance, with a FilePot, it currently seems impossible to specify a set of calc_args that will be used on every call, even though it seems there should be a straightforward way to do this in XML.

We need better documentation for how to go about setting up an XML parameter file for a potential in general, and some of the more complicated potentials specifically. The examples in share/Parameters are quite minimal and don't provide much useful info on how these things are actually parsed.

Normally I'd volunteer to write some of this documentation, but I still have no idea how the parsing for a general Potential xml stanza works.

This has occurred when a very large real was passed to the concatenation operator.[1]

I guess the return value is too long and some kind of corruption happens. Annoying because I can't run the quip program on my Mac

[1] e.g. in src/libAtoms/Connection.f95 line 1073, my_max_pos_change = huge(1.0_dp) in some cases. Even though this line is not even printed at normal verbosity levels, the string is still created and crashes.

This is because the clean target has clean-quippy as a dependency, which itself fails if numpy cannot be imported, which setup.py tries to do.

I think we should not depend on python at all to do a make clean, so we should only attempt to do a clean-quippy as a subtask of clean, rather than a dependency.

ParamReader has a hard-coded constraint of MAX_N_FIELDS, in src/libAtoms/ParamReader.f95. Now increased to 1000, this might still become a problem for very long descriptor_strings with multiple descriptors and many arguments for each. Ideally the number of fields should be dynamically allocated. There might be a related issue with fixed-length strings used throughout ParamReader.

After comparing Daniele Dragoni's commandline for phonons with mine, it seemed like the behaviour phonon_supercell is causing issues. Running the following with recent versions of quippy gives nonzero values for phonons at gamma when phonon_supercell and phonon_supercell_fine differ:

#!/usr/bin/env python

from quippy import phonons
from quippy.potential import Potential
from quippy import bcc1

bulk = bcc1(1.43325007*2, 26)
pot = Potential("IP FS")
pot.minim(bulk, 'cg', 1e-7, 100, do_lat=True)

fine = phonons.Phonon_fine()

steps = 7
sc = 10
sc_fine = 2+(steps*2)

fine.calc(pot, bulk, dx=0.01, phonon_supercell=(sc, sc, sc), 
          phonon_supercell_fine=(sc_fine, sc_fine, sc_fine),
          phonons_path_start=(0.0, 0.0, 0.0), 
          phonons_path_end=(0.5, -0.5, 0.5), phonons_path_steps=steps)

print(sc, fine.q[1], 1000*fine.frequency[1])
print(sc, fine.q[2], 1000*fine.frequency[2])
# (10, FortranArray([ 0.,  0.,  0.]), FortranArray([ 0.68543577,  0.68543577,  0.68543577]))
# (10, FortranArray([ 0.        ,  0.        ,  0.27399202]), FortranArray([ 1.82271397,  1.82271397,  2.40645046]))

sc = sc_fine
fine.calc(pot, bulk, dx=0.01, phonon_supercell=(sc, sc, sc), 
          phonon_supercell_fine=(sc_fine, sc_fine, sc_fine),
          phonons_path_start=(0.0, 0.0, 0.0), 
          phonons_path_end=(0.5, -0.5, 0.5), phonons_path_steps=steps)

print(sc, fine.q[1], 1000*fine.frequency[1])
print(sc, fine.q[2], 1000*fine.frequency[2])
# (16, FortranArray([ 0.,  0.,  0.]), FortranArray([ -2.73119306e-07,  -9.48351971e-08,   2.18828150e-07]))
# (16, FortranArray([ 0.        ,  0.        ,  0.27399202]), FortranArray([ 1.70025326,  1.70025326,  2.37435406]))

It's not a proper bisect, but using a version of quippy compiled in October last year gives the expected results:

(10, FortranArray([ 0.,  0.,  0.]), FortranArray([ -3.96692927e-07,  -2.63923001e-07,   1.37793968e-07]))
(10, FortranArray([ 0.        ,  0.        ,  0.27399202]), FortranArray([ 1.70025326,  1.70025326,  2.37435406]))

(16, FortranArray([ 0.,  0.,  0.]), FortranArray([ -2.65801279e-07,  -1.24993193e-07,   2.24881096e-07]))
(16, FortranArray([ 0.        ,  0.        ,  0.27399202]), FortranArray([ 1.70025326,  1.70025326,  2.37435406]))

Slightly related to this, the documentation for the two parameters is not very clear:

phonon_supercell type=INTEGER dim=3 current_value='1 1 1'
supercell in which to do phonon computation

phonon_supercell_fine type=INTEGER dim=3 current_value='1 1 1'
supercell in which to do phonon computation

Tom

Reported by Noam Bernstein:

If you convert from ase to quippy and back, the info field is not written in the extxyz:

cat t.py

import ase, ase.io, sys, quippy

at1 = ase.io.read("t.extxyz", 0)

at1.info['test'] = "bob"

print "print ase.Atoms with ase.io.write"
ase.io.write(sys.stdout, at1, format='extxyz')

at1q = quippy.Atoms(at1)
print "convert ase.Atoms to quippy.Atoms, print with ase.io.write"
ase.io.write(sys.stdout, at1q, format='extxyz')

at1 = ase.Atoms(at1q)

print "convert ase.Atoms to quippy.Atoms, convert back, print with ase.io.write"
ase.io.write(sys.stdout, at1, format='extxyz')

python t.py

ase.Atoms with ase.io.write
2
Lattice="2.0 0.0 0.0 0.0 2.0 0.0 0.0 0.0 2.0" Properties=species:S:1:pos:R:3:Z:I:1 test=bob pbc="T T T"
Si      0.00000000       0.00000000       9.00000000       14 
Si      1.00000000       1.00000000       1.00000000       14 
convert ase.Atoms to quippy.Atoms, print with ase.io.write
2
Lattice="2.0 0.0 0.0 0.0 2.0 0.0 0.0 0.0 2.0" Properties=species:S:1:pos:R:3:Z:I:1 test=bob pbc="T T T"
Si      0.00000000       0.00000000       9.00000000       14 
Si      1.00000000       1.00000000       1.00000000       14 
convert ase.Atoms to quippy.Atoms, convert back, print with ase.io.write
2
Lattice="2.0 0.0 0.0 0.0 2.0 0.0 0.0 0.0 2.0" Properties=species:S:1:pos:R:3:Z:I:1 pbc="T T T"
Si      0.00000000       0.00000000       9.00000000       14 
Si      1.00000000       1.00000000       1.00000000       14```

I'm installing the latest lammps at TACC on our KNL machine, and of course want to include a recent version of kim (1.7.3) because some of our users are developing MSMEAM code with this version of kim. When I build the latest quip version (from github) in lammps and include kim in the build it doesn't compile because quip is expecting a "KIM_API" module (as found in earlier versions of kim) not the "KIM_API_F03" module of the latest release.
Are you developing, or could you please develop, a branch which will accommodate kim_1.7.3's latest changes?
Thanks,
Kent Milfeld

ifort -fpp -free -warn unused -fPIC -I/work/00770/milfeld/knl_lammps/lammps-17Nov16/lib/quip/src/libAtoms -I/work/00770/milfeld/knl_lammps/lammps-17Nov16/lib/quip/src/fox/objs.linux_x86_64_ifort_icc_serial/finclude -I/opt/apps/intel17/netcdf/4.3.3.1/x86_64/include kim-api-v1-build-config --includes -O3 -xMIC-AVX512 -fp-model fast=2 -qno-offload -qoverride-limits -diag-disable=7712 -g -traceback -DDUMP_CORE_ON_ABORT -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,4a32314-dirty"' -D'GAP_VERSION=1480975044' -D'QUIP_ARCH="linux_x86_64_ifort_icc_serial"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_NETCDF -DNETCDF4 -DHAVE_KIM -DHAVE_PRECON -DHAVE_QR -c -Tf /work/00770/milfeld/knl_lammps/lammps-17Nov16/lib/quip/src/Potentials/IPModel_KIM.f95 -o IPModel_KIM.o
/work/00770/milfeld/knl_lammps/lammps-17Nov16/lib/quip/src/Potentials/IPModel_KIM.f95(59): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [KIM_API]
use KIM_API

Is there a recommended revision to checkout from the git repo for stable use?

integer, intent(out), dimension() :: mainlog_ptr, errorlog_ptr ------------------------------------^ /home/erdavids/src/git/QUIP.intel/src/libAtoms/System.f95(2093): error #6364: The upper bound shall not be omitted in the last dimension of a reference to an assumed size array. [MAINLOG_PTR] mainlog_ptr = transfer(mainlog_p, mainlog_ptr) ----^ /home/erdavids/src/git/QUIP.intel/src/libAtoms/System.f95(2093): error #6364: The upper bound shall not be omitted in the last dimension of a reference to an assumed size array. [MAINLOG_PTR] mainlog_ptr = transfer(mainlog_p, mainlog_ptr) --------------------------------------^ /home/erdavids/src/git/QUIP.intel/src/libAtoms/System.f95(2095): error #6364: The upper bound shall not be omitted in the last dimension of a reference to an assumed size array. [ERRORLOG_PTR] errorlog_ptr = transfer(errorlog_p, errorlog_ptr) ----^ /home/erdavids/src/git/QUIP.intel/src/libAtoms/System.f95(2095): error #6364: The upper bound shall not be omitted in the last dimension of a reference to an assumed size array. [ERRORLOG_PTR] errorlog_ptr = transfer(errorlog_p, errorlog_ptr) ----------------------------------------^``

If an atomic config generated using ASE with a stress is written as an extxyz, it has a 6 element stress field written, rather than a 9-element as quippy expects. This extxyz file can therefore not be read in by quip (as an xyz).

P.S. - it would be nice if convert.py, and others, recognized extxyz as a valid suffix.

Traceback (most recent call last):
File "run-model-test.py", line 42, in
import test # import and run the current test
File "../tests/liquid/test.py", line 32, in
dyn_heat = quippy.Dynamics(bulk, 0.5*ase.units.fs, initialtemperature=5000.0, trajectory=None)
File "/usr/local/quip/2015-06-03/mkl/lib64/python/quippy/dynamicalsystem.py", line 186, in init
if not all(abs(self._ds.atoms.velo) < 1e-3):
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

Removing the initialtemperature specification allows this statement to work fine.

Simone Sturniolo in STFC tried to use pip (as in pip install from local folder, see here) to install quippy but failed. The reason is in line 44 in setup.py:

quip_root = os.path.abspath(os.path.join(os.getcwd(), '../'))
When it is run via pip it uses a temporary directory so everything is messed up. Just wondering: would it be acceptable if we get QUIP_ROOT from the environment (and throw an error if it's not there) and use it.

Python 3 has been around for over 8 years now. Although 2.7 will be supported until at least 2020, there is a movement within the scientific stack to drop support well before then: http://www.python3statement.org. I think that quippy needs to be updated for Python 3 support as soon as possible.

I think the main steps will probably be:

• Move to an external version of f90wrap. This already has Python 3 support, but I don't know how much it the version in QUIP has been customised, so it is probably not straightforward, or even the best solution.
• Check the remaining code for compatibility. This will be tedious, but not difficult.

Last time I attempted to do something like this it ended up with a infinitely recursive dictionary, so I feel like it will need a bit more intimate knowledge of the inner workings than I currently have.

This could also be an opportunity to gut obsolete code or get some of the more general stuff moved to ase.

Any comments, or volunteers?