ciao luca,
Changes in KSPACE/ewald.{h,cpp} introduced in revision 7782 of LAMMPS
subversion repository has broken the compatibility with USER-OMP package.
ewald_omp.cpp: In member function
‘virtual void LAMMPS_NS::EwaldOMP::compute(int, int)’:
ewald_omp.cpp:188: error: no matching function for call to
‘LAMMPS_NS::EwaldOMP::slabcorr(int&)’
ewald.h:54: note: candidates are: void LAMMPS_NS::Ewald::slabcorr()
make[1]: *** [ewald_omp.o] Error 1
I'm currently compiling subversion revision 7790.
a patch has been committed yesterday
and should be in the current svn.
PS: there is also a problem with USER-CUDA package for which a patch has
been posted recently. Can we setup a proper building test against all
packages before new features are introduced in the repository?
you may consider switching to the LAMMPS-ICMS git repository.
i usually don't push changes from my local repo to the external until
i've compiled the code and run a couple of sanity test scripts.
the issue of validation and (semi-automatic) quality control in
LAMMPS has been brought up a number of times in the past
and - of course - with the recent breaking of user packages.
for a number of organizational and technical reasons, it is not
easy to do this based on the original repository. it would be
conceivable to have a few people maintain a branch that
would not be updated until certain validation criteria are
met or do less frequent "releases" that will only be updated
for bug fixes without adding new features until a certain
amount of changes has accumulated or a certain period
of time has passed and then the next release would be
made. that version then could also be backed by a
bug tracking system and alike, as was suggested as well.
based of the public git repo and using one of the free hosting
sites, this would be technically very easy to set up.
an alternate scheme would be to have a "pre-merge" repo
with multiple feature branches where all "disruptive" changes
would be committed first before merged into the upstream
version. again, this is technically very easy to set up
with a distributed SCM like git and difficult with the
"one-way street" svn mirror setup.
there are people with different philosophies and opinions
on this at work here, the discussion is ongoing, and no
silver bullet has yet been found. i am certain that everybody
involved would welcome further constructive comments.
cheers,
axel.