Nevermind. That was in my original distribution, so VOTCA was inverting it.
How can you measure the dihedral distribution during the IBI without having a discontinuity at the end? Otherwise the dpot would try to include this discontinuity. Do you measure just a bit less than 3.1415? On Tuesday, March 7, 2017 at 10:35:54 AM UTC-5, Joshua Moore wrote: > The current calculation is causing a discontinuity in the dihedral at the > ends, and I think this is occasionally leading to issues in the simulation, > at least I think this is the reason. Please see attached. > > Do we need to add back in the end calculation as you were mentioning? > Maybe that was needed. > > Thanks. > > Josh > > > > > > On Saturday, March 4, 2017 at 11:45:23 PM UTC-5, Christoph Junghans wrote: > >> 2017-03-04 11:26 GMT-07:00 Joshua Moore <[email protected]>: >> > 1) Angles >> > >> > I realized I was not using the development version. Sorry about this. >> This >> > issue seems to have been corrected in the development version. I'm >> still >> > not exactly what the change was to fix this, but it is correct in the >> > development version. >> > >> > 2) Dihedrals >> > >> > I found two issues >> > >> > a) In potential_to_lammps.sh, there was a scaling to degrees for the >> "scale" >> > step. This seems to be the cause of it dropping points in the >> smoothing >> > step. If you remove this being applied to the $bondtype="dihedral", >> this >> > issue goes away. >> The issue is that the table beginning and ending should be converted >> to degrees as well in the case of dihedral potentials. For the "angle" >> type this issue doesn't appear as the table always goes from 0 to 180 >> (both in degrees already.) >> >> > >> > However, there was a second issue related to the units LAMMPS expects >> for >> > the dihedral. I originally thought the default was radians, but it >> appears >> > it is degrees. We need to add this to table_to_tab.pl so that LAMMPS >> knows >> > the table is in radians. Then remove the previous check for dihedrals >> when >> > it is scaling. >> > >> > } elsif ($type eq "dihedral" ) { >> > printf(OUTFILE "VOTCA"\n"); >> > printf(OUTFILE "N %i RADIANS\n\n",$#r+1); >> > . >> > . >> > . >> > >> > LAMMPS seems to be finicky for the derivative for the dihedrals, and I >> think >> > the amount of noise in the distribution is causing an issue for short >> runs >> > and LAMMPS is complaining that the dihedral table has inconsistent >> forces. >> > I'm assuming VOTCA is generating these from a spline? The issue seems >> to be >> > alleviated with longer runs. However, LAMMPS has an option to leave >> off the >> > forces for the dihedral table and let LAMMPS calculate them. I'll look >> into >> > this some more to see if this helps. >> > >> > I'll work on a pull request if you agree. >> Thanks Josh! Your pull request at >> <https://github.com/votca/csg/pull/202> seems to fix the two issues >> above. >> >> Christoph >> >> > >> > Thanks. >> > >> > Josh >> > >> > >> > >> > >> > >> > On Friday, March 3, 2017 at 9:34:52 PM UTC-5, Joshua Moore wrote: >> >> >> >> Hello, >> >> >> >> I am seeing some issues with angle and dihedral translation issues. >> >> >> >> 1) Angles >> >> >> >> In the attached ANGLE_ISSUE.PNG, I illustrate the issue. >> >> >> >> On step000, the initial angle potential is inverted correctly from the >> >> angle distribution. The unit conversion appears to be correct. On >> step001, >> >> it also is translated corrected during the scale, smoothing, >> extrapolation, >> >> interpolation, and shifting steps. However, it appears when the >> LAMMPS >> >> table file is written for the angle, something goes wrong. Here I >> compare >> >> to the initial inversion by hand which is shifted in step000, which >> accounts >> >> for the difference. The smoothing, extrapolation, interpolation steps >> fall >> >> on top of one another, and the shifting step is shifted of course. >> >> >> >> Again here the issue appears to be the lammps table writing step, >> although >> >> I haven't been able to find the issue in the code. Any ideas? >> >> >> >> 2) Dihedrals >> >> >> >> See attached DIHEDRAL_ISSUE.PNG >> >> >> >> Here, there may very well be a LAMMPS table writing issue as with the >> >> angles, but on step001 the first issue that occurs is on the smoothing >> >> steps, where it drops most of the data points and fits only 11 points. >> This >> >> is the cause for the difference. This is then populated through to >> the next >> >> steps including writing the LAMMPS table file. Although the smooth, >> >> extrapolation, interpolation, and shifting steps are in radians, the >> scaling >> >> step writes the file in degrees, although it appears this is not >> >> subsequently used. This scaling step is correct in the translation of >> the >> >> potential and the number of points. The next step I think after this >> is the >> >> smoothing step which again drops most of the points and appears to be >> the >> >> major issue here. >> >> >> >> I think the dihedral issue might be a general issue in VOTCA and not >> >> necessarily a problem with interfacing with LAMMPS? >> >> >> >> >> >> Thanks in advance. >> >> >> >> Josh >> >> >> >> >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "votca" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to [email protected]. >> > To post to this group, send email to [email protected]. >> > Visit this group at https://groups.google.com/group/votca. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Christoph Junghans >> Web: http://www.compphys.de >> > -- You received this message because you are subscribed to the Google Groups "votca" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/votca. For more options, visit https://groups.google.com/d/optout.
