VMD-L Mailing List
From: Ryan Woltz (rlwoltz_at_ucdavis.edu)
Date: Mon Aug 12 2024 - 14:42:56 CDT
- Next message: Bennion, Brian: "altloc pdb entries"
- Previous message: Sinclair, Matt: "Reminder: Hands-On Workshop on Computational Biophysics in Auburn, AL"
- In reply to: Vermaas, Josh: "Re: pbc box unwrapping/wrapping error infinite bond angles/box sides"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Hi Josh,
Thank you for your reply. I think you are right and I wanted to
respond just so future readers can see the conclusion to this problem and
pbc get and pbc set didn't really solve my issue but it helped and could
help others.
Here is what I've done since my last email. I set the box dimensions
for the first failed frame (106), which has an "inf" B side as seen
above, to the previous frame (105) box dimensions which are normal (i.e.
{149 148 150}). This worked for this frame. However, repeating this process
for the next failed frame (107) failed as well with the additional error:
vecsub: non-numeric in first argument
full output:
vmd > pbc set {150.054550 150.054550 149.230530} -all
vmd > animate goto 0
vmd > pbc unwrap -all -sel "protein"
Info) 0.1% complete (frame 1)
vecsub: non-numeric in first argument
vmd > molinfo 0 get frame
11
vmd > pbc get
{150.054550 150.054550 149.230530 90.000000 90.000000 90.000000}
Ultimately I think the problem is that a collection of frames in the
trajectories did not save completely because the vecsub seem to require
numeric values for x y z coordinates for each frame and atom. I checked
the {x y z} coords and some of these values are extremely large or
extremely small i.e. {-5.262689228402451e-5 4.1264534047513735e-6
-2.805381409591737e-36} {0.016464684158563614 2.576862909566023e+32
8.374346621336798e+27}. So maybe this frame has the incorrect scaling value
as a root cause? Maybe this vecsub doesn't like the "e" in that numeral and
just thinks it is "inf"? vecsub seems to want a numeric value thus the pbc
box size and angles also being "inf". Would you agree with this?
It feels random which frames in the simulation are bad and there is no
energy explosion in the .mdout so I think the calculations are still ok.
Also, it is only present in one conformation which had 5 simulations but
they were run at the same time on the same HPC. So I think the ultimate
problem based on your email and my testing is the files were not saved or
stored properly on the HPC as there were some storage drive issue emails
around that time but it didn't seem to affect my results at the time. I
also did a "du" on the trajectories and they all come out to the same size
so not sure what else I can check for corruption differences.
So for now my plan is to scrap this section of the simulation for the data
deposit due to corrupted data as this is only the equilibration. All the
analysis was done on the production stage and there are no faulty frames in
the production stage as I exported to a different HPC for the production.
I'm happy to keep working on this problem to solve it for future users. Do
you have any other alternatives to fixing frames with extremely high
coordinate values?
Thanks again for your reply it was very helpful,
Ryan
On Mon, Aug 12, 2024 at 7:42 AM Vermaas, Josh <vermaasj_at_msu.edu> wrote:
> Hi Ryan,
>
>
>
> You need to set the PBC box dimensions somehow. Most of the time in a
> trajectory, these come from the trajectory file itself, and this all
> happens transparently. You can see these dimensions with `pbc get -all` to
> see the box dimensions for all loaded frames. If it is only a few frames
> where the box is weird/nonsense, you can probably use `pbc set`with the
> appropriate arguments to correctly set the box dimensions in VMD (see
> https://www.ks.uiuc.edu/Research/vmd/plugins/pbctools/). Side lengths of
> zero and infinity are clearly signs that something is not right in the
> trajectory (or potentially in the file reader).
>
>
>
> -Josh
>
>
>
> *From: *<owner-vmd-l_at_ks.uiuc.edu> on behalf of Ryan Woltz <
> rlwoltz_at_ucdavis.edu>
> *Date: *Friday, August 9, 2024 at 8:15 PM
> *To: *VMD Mailing List <vmd-l_at_ks.uiuc.edu>
> *Subject: *vmd-l: pbc box unwrapping/wrapping error infinite bond
> angles/box sides
>
>
>
> Dear community,
>
>
>
> I'm having an issue that I can't really find a good solution to.
> I've tried qwrap pbc tools and I've seen something about mdanalysis fixing
> this issue but just can't the examples are not for the nc and parm7 files I
> have so I'm not sure how to use it. I'm pretty sure I fixed this issue 2
> years ago using some pbctools commands but I can't remember how. It might
> have been a pbc join command but the way I'm using it doesn't work like I'd
> like them to. I'm also on a publishing deadline so I don't have much more
> time to troubleshoot and was hoping someone can help with pbc join or some
> other command in vmd.
>
>
>
> The issue is for a few frames in my simulations the bond angles
> are infinite and one of the box sides in infinite. This makes pbc tool
> crash at that frame with this error:
>
>
>
> vmd > pbc unwrap -all -sel "protein"
> Info) 0.2% complete (frame 1)
> ERROR) Suspicious pbc side length (a=0.000000 b=-inf c=-0.000000). Have
> you forgotten to set the pbc parameters?
> ERROR) Suspicious pbc angle (alpha=363384373248.000000 beta=inf gamma=inf).
> domain error: argument not in valid range
>
>
>
> I think the solution is in pbc join or pbc box but I do not have
> enough experience or confidence to know how to use these commands.
>
>
>
> Can someone help guide me to a page or suggest a command to define
> the box with proper dimensions for the bad frames or another way to
> process, maybe with mdanalysis?
>
>
>
> Thank you,
>
>
>
> Ryan
>
- Next message: Bennion, Brian: "altloc pdb entries"
- Previous message: Sinclair, Matt: "Reminder: Hands-On Workshop on Computational Biophysics in Auburn, AL"
- In reply to: Vermaas, Josh: "Re: pbc box unwrapping/wrapping error infinite bond angles/box sides"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]