No idea since I'm not really familiar with TUPA. You might have better
luck contacting the developers of that code.
Could be that perhaps TUPA is expecting coordinates in Angstroms, but
Gromacs TRR files have coordinates in nm? Or maybe TUPA expects the
unit cell to be X-aligned? Again, not being familiar with TUPA I can
only guess.
-Dan
On Thu, Nov 14, 2024 at 10:56 AM Guberman-Pfeffer, Matthew
<Matthew_Guberman-Pfe.baylor.edu> wrote:
>
> Hi Dan,
>
> I change the CPPTRAJ script to say:
> trajout prod_638rms.trr
>
> But when given to TUPA, I still get an erroneous electric filed magnitude (1995 MV/cm). Note that most frames have reasonable magnitudes, but for some, waters are ending up unphysically close to the atom selected as the probe (which was used for centering).
>
>
> Any suggestions for what I can do?
>
> Best,
> Matthew
>
> On Nov 14, 2024, at 9:10 AM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
> Hi Matthew,
>
> It appears you're using the NetCDF format, which as I mentioned before
> is problematic; I'll paste the relevant part here:
>
> Once you rotate the unit cell vectors the unit cell X-axis
> vector is no longer colinear, so the unit cell can no longer be
> described with just 3x lengths and 3x angles. The consequence of this
> is that imaging will no-longer work properly with that trajectory,
> which is why cpptraj prints the warning. If you want to keep the
> rotated unit cell vectors, the only solution at the moment is to use a
> trajectory format that stores the full unit cell vector coordinates
> (like TRR or XTC).
>
>
> So when you give the RMS-fit trajectory to TUPA in NetCDF format,
> you're giving it rotated coordinates but non-rotated unit cell
> vectors. Because they are out of alignment, imaging doesn't work
> properly and you get nonsense results. You need to use a trajectory
> format that stores the full unit cell vectors (as previously
> mentioned, TRR/XTC are your best bet, with a preference to TRR since
> that's a bit higher precision and you want to calculate energies).
>
> The Amber NetCDF trajectory format will need to be extended to store
> the full unit cell vectors. It's something that's been on my to-do
> list for a while. Note that it's not just a matter of cpptraj writing
> the full unit cell vectors to NetCDF trajectories, any programs also
> need to be updated to read the full unit cell vectors.
>
> -Dan
>
> On Thu, Nov 14, 2024 at 9:26 AM Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
>
> What trajectory format are you using for TUPA?
>
> -Dan
>
> On Wed, Nov 13, 2024 at 5:07 PM Guberman-Pfeffer, Matthew
> <Matthew_Guberman-Pfe.baylor.edu> wrote:
>
>
> Hi Dan,
>
> I’m encountering the following issue: I understand that the system becomes un-aligned with the x-axis after RMS fitting. Now I’m trying to use the TUPÂ program to compute the electric field, and when PBC conditions are applied by TUPÂ (which uses MDAnalysis) something goes wrong because the electric field becomes astronomical. If I turn off periodic conditions or delete the solvent, the problem goes away entirely. Curiously, the issue only happens for some (not all) frames) of the trajectory. The problem also does not happen if I do not RMS-fit, but I was told that the electric field is not physically meaningful in that case.
>
> I’m really perplexed and scrambling for an explanation/fix. Could the issue be the way the x-axis un-aligned system is being handled? What can you suggest?
>
> Best,
> Matthew
>
>
>
>
>
> On Nov 11, 2024, at 8:18 AM, Guberman-Pfeffer, Matthew <Matthew_Guberman-Pfe.baylor.edu> wrote:
>
> Hi Dan,
>
> Thanks for explaining the warning! Otherwise, did my cpptraj script for centering and RMS-fitting looked OK?
>
> Best,
> Matthew
>
>
>
> On Nov 11, 2024, at 8:04 AM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
> Hi,
>
> On Sun, Nov 10, 2024 at 11:45 PM Guberman-Pfeffer, Matthew via AMBER
> <amber.ambermd.org> wrote:
>
>
> Warning: Set 1; unit cell is not X-aligned. Box cannot be properly stored as Amber NetCDF trajectory.
>
>
> When you RMS-fit in cpptraj, the atom coordinates and unit cell
> vectors are rotated according to the calculated best-fit rotation. In
> the Amber NetCDF format (along with many other trajectory formats),
> unit cell vectors are stored as 3x lengths and 3x angles - 6 numbers
> total. The reason this works is that the unit cell is assumed to be
> X-aligned; i.e. the unit cell X vector is colinear with the global X
> axis vector (the Y and Z components of the X-axis vector coordinate
> are 0). Once you rotate the unit cell vectors the unit cell X-axis
> vector is no longer colinear, so the unit cell can no longer be
> described with just 3x lengths and 3x angles. The consequence of this
> is that imaging will no-longer work properly with that trajectory,
> which is why cpptraj prints the warning. If you want to keep the
> rotated unit cell vectors, the only solution at the moment is to use a
> trajectory format that stores the full unit cell vector coordinates
> (like TRR or XTC). If you don't care about the unit cell
> vectors/imaging, you can just remove the unit cell information with
> the 'nobox' keyword of 'trajout'.
>
> Hopefully this makes sense.
>
> -Dan
>
>
>
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Nov 14 2024 - 08:30:01 PST
