[…]
I tried to find what you define “documentation of the individual style” but what I found it is exclusively related to potentials and their related coefficients.
Any suggestion where to search for the info I am looking for?
the ultimate documentation is always the source code.
For example I feel uneasy to bother Prof. Jorgensen about OPLS atoms 1-4 sequencing rules, also because I doubt he was not he himself twho implemented this potential in Lammps. Does anybody know where to find the gentlemen who developed these potentials in Lammps and their comments?
for contributed code, the contributor should be listed in the corresponding source code.
If I look at the contents of src/MOLECULE/dihedral_opls.cpp, I find in the DihedralOPLS::compute() function:
for (n = 0; n < ndihedrallist; n++) {
i1 = dihedrallist[n][0];
i2 = dihedrallist[n][1];
i3 = dihedrallist[n][2];
i4 = dihedrallist[n][3];
type = dihedrallist[n][4];
// 1st bond
vb1x = x[i1][0] - x[i2][0];
vb1y = x[i1][1] - x[i2][1];
vb1z = x[i1][2] - x[i2][2];
// 2nd bond
vb2x = x[i3][0] - x[i2][0];
vb2y = x[i3][1] - x[i2][1];
vb2z = x[i3][2] - x[i2][2];
vb2xm = -vb2x;
vb2ym = -vb2y;
vb2zm = -vb2z;
// 3rd bond
vb3x = x[i4][0] - x[i3][0];
vb3y = x[i4][1] - x[i3][1];
vb3z = x[i4][2] - x[i3][2];
// c0 calculation
sb1 = 1.0 / (vb1xvb1x + vb1yvb1y + vb1zvb1z);
sb2 = 1.0 / (vb2xvb2x + vb2yvb2y + vb2zvb2z);
sb3 = 1.0 / (vb3xvb3x + vb3yvb3y + vb3z*vb3z);
From this it looks like this dihedral style uses the atoms in the expected order (i1 is the first, i4 the fourth) and the bond vectors are computed in the normal way.
As mentioned before, the ultimate confirmation is with setting up a test input (just write a data file with 4 atoms and a dihedral and an input file using only the dihedral style) and then print the energy from that. If you edit the position of the atoms a few times you can then compute their dihedral angle and compute the energy that you should get with the results from the LAMMPS calculation. If they match you will be as certain as one could be that everything is working correctly.
It would probably take you less time than writing multiple emails and waiting for people to respond.
[…]
One last comment, Axel, if I may, without any intention to be inappropriate.
When I wrote my first computer program in fortran IV, some 40 years ago, a code to be fed on a large humming machine with some kilos of punched cards, my tutor told me that the most precise the documentation of the program was, the better. This for possible future users and in particular for the author himself.
I learned this lesson by hearth and I tried to apply it everywhere in my professional life. Therefore I strongly think that making an exhaustive documentation of any given code /program is not a matter for “swiss administrators or accountants”, but the precise duty of scientists and engineers.
You are preaching to the choir, but this is different from the real life situation. It seems that you have been very fortunate to have had a proper and responsible tutor. If you have been following this mailing list for some time, you should have seen that this is rarely the case these days and also how often I am advising people to ask their advisers/tutors to just do their job and properly tutor their advisees. But bad advising and instead relying on students tutoring themselves based on whatever documentation and help from online resources like this mailing list they can get. It is sometimes heartbreaking to see the level of desperation that some people have and turn them down, but the option to try and tutor these people is not sustainable. There is not enough available time to just do all the software development and maintenance. The pandemic has been good for LAMMPS development since there was more time available (my number of contributions to the LAMMPS code and documentation in the last 24 months is more than double of what it was in the year before).
There is one more aspect to this. Assuming we have a contribution from a well tutored and trained person, there also is always the problem that that person may not document explicitly what they consider “obvious”. For a long time now - and based on my own experience of learning to use different kinds of software - I believe that writing the documentation should not be left to the developer of a method, but should be done (or at least properly revised) by a user (or multiple).
Few developers have a sense of what is needed, since they know all the details of the implementation they just did. For me personally revising documentation and fixing bugs that I encountered and then contributing those changes back to the project were always things that I was compelled to do to “pay back” the people that put in all the effort to write the software and documentation and are giving away for free. Sadly, that view is not very common (anymore?) and it is sometimes frustrating to be confronted by users that - unlike you - demand to be spoon fed the information they require without first exhausting all means available to them to gather information that is available.
Admittedly, this is the opinion of a rather old gentleman. Maybe today times have changed and the rules have been somehow relaxed.
I am not exactly a “grashopper” myself and been around the block a few times…
I think “the rules” were always not as strongly enforced as you have experienced. I have seen a lot of people having “in house codes” that were just a bunch of fortran files that were pieced together differently for each project and not maintained in a specific way using source code management software, but people just took copies from some other group member (and thus those may contain code at different degrees of completeness due to when the copy was taken).
For LAMMPS the intent has always been (and still is) to be very welcoming to contributions (most of LAMMPS is contributed code), but the realities of maintaining are rather large code base have forced us (aided by the personal preferences) to be more strict in the requirement and establish a strict testing regime to minimize “collateral damage”. Originally, contributed code was only tested to see if it compiles (on the desktop of the developer adding it to the package) and it was required that it contains documentation files for the commands. There were also packages with a USER- prefix where the compilation requirement was not enforced.
Since we moved to GitHub and started using automated integration testing, we have systematically worked to make the entire more consistent and portable and have recently reached the point where we became comfortable dropping the USER- prefix for packages (We now recommend to use it for packages that are not bundled with LAMMPS and maintained externally).
So I firmly believe that what is in the LAMMPS source distribution now, is in a much better shape than what was there, say, 10 years ago, but we have still a long way to go to reach the goals that you were formulating (and are not likely to ever reach them if the rate of contributions remains growing as it has over that time).
HTH,
Axel.