On Thu, Jul 1, 2021 at 12:10 AM Shiji Zhao <shijiz.uci.edu> wrote:
> Dear Amber developers,
>
> I thought the original email failed to be sent to the maillist. Did you all
> receive the same content three times? That's a little awkward...
>
> Dr. Case and Dr. Swails, sorry that I copied the original line 73 of
> mdoutanalyzer/mdout.py to the previous email.What I mean is change it to:
>
> self.num_terms = int(self.num_steps / self.properties['ntpr']) + 1
>
> The reason is that the result of self.num_steps / self.properties['ntpr']
> may
> not be an integer, so that self.num_terms will be saved as a floating
> number. Consequently, a TypeError will be thrown when a float number is
> used to indicate the size of a numpy array.
>
Yes, this makes sense. This is actually one of those Python 2 -> 3 issues
where num_steps and ntpr were integers, so this would default to integer
division in Python 2. But my total number of steps was always set to a
multiple of ntpr so it also makes sense that I'd never see this issue.
>
> Regarding the questions of Dr. Swail, I actually use it after every MD run
> to check energy etc.
Woah! An actual user! Maybe we'll even hook Gustavo and Carlos ;). FWIW,
cpptraj can also parse mdout files also.
If enough people find it useful and the occasional bug is easy enough to
squash there's probably not much harm in keeping it in.
I'll commit your int-casting fix here (not sure about the draw() vs. show()
change -- I'd be wary of changing that given that show() had always worked
for me).
Thanks,
Jason
--
Jason M. Swails
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Jul 01 2021 - 19:00:02 PDT
