Hi Carlos -
I think we are in violent agreement here ;-) When I first read your first
email, I was looking at the deeper floating point representation issue, not
realizing 1) that there was conversion to a 4 byte internal representation
in ptraj which makes the issue worse (until I saw Tom's code snippet), and
2) when you said "exact", you really just wanted the precision to be close
enough you didn't see the difference in the printouts. I think the issue is
very adequately resolved by Tom doing the fix, and in my opinion, these
methods are all so fuzzy, getting hung up on exact numbers is probably a
waste of time. I probably belabored the point a bit too much because I
think there is a tendency to disregard a bunch of problems that occur with
floating point numbers - computer scientist types, myself included, tend to
hate having to use them. So, happiness is everyone agreeing that your
problem is fixed :-)
Best Regards - Bob
----- Original Message -----
From: "Carlos Simmerling" <carlos.csb.sunysb.edu>
To: <amber-developers.scripps.edu>
Sent: Tuesday, February 06, 2007 9:16 AM
Subject: Re: amber-developers: ptraj precision
> Hi Bob,
> I'm not sure why you say I'm not correct. All I said was that
> my fortran program has no problem reproducing the values, so
> in my opinion it must be a problem with ptraj. What I wanted was
> the "same" numbers in the file, some of the things you mention
> below are interesting but not really relevant to my issue of
> the values in the restart and traj just being different. With
> my (double precision) fotran program, I get the same coordinates
> in restart or traj and the same energies (yes, to within the output of
> sander). With ptraj that didn't happen. I wasn't talking about doing an
> "exact" restart, which of course we can't do with either traj or restart
> files in non-binary. The point is that ptraj does not properly write out
> what is in the coordinate file that it reads, and that should get fixed.
> thanks for your help with this!
> regards
> carlos
>
>
>
> Robert Duke wrote:
>> Hi Carlos -
>> You are not correct; the conversion error seen here is due to using a
>> float as the input variable, as well as a float reading format, but there
>> would still be no error associated with that if there were not
>> unavoidable problems with the mix of internal and external
>> representation. The reason you don't "see" any conversion error is that
>> using double precision in fortran, the conversion error occurs down
>> around decimal place 16-17 (if memory serves). SO you WOULD see
>> differences in a restart trajectory, but once again you may have to do
>> something like a debug dump of the energies to actually notice it due to
>> truncation of mdout output. The reason I am being sticky about this
>> point is that you were talking about "exact conversion to restart"; the
>> only way to get this is with a binary restart file which I am not sure we
>> reliably support (I know there are input options to do this; I have no
>> confidence that the stuff actually works across all platforms, having
>> seen the standard fortran binary i/o fall on it's face before - the
>> specification of external (file) representation is incomplete and vendor
>> specific). We should maybe extend NetCDF to cover the restrt and inpcrd
>> files sometime, if folks really want to be able to do an "exact"
>> restrart.
>> Regards - Bob
>>
>> ----- Original Message ----- From: "Carlos Simmerling"
>> <carlos.csb.sunysb.edu>
>> To: <amber-developers.scripps.edu>
>> Sent: Tuesday, February 06, 2007 7:44 AM
>> Subject: Re: amber-developers: ptraj precision
>>
>>
>>> I should point out that I wrote a simple fortran program to write
>>> restarts
>>> and I get exactly what I expected- the number in the traj file followed
>>> by zeroes. So, I don't think it is a problem with internal
>>> representation,
>>> it's something with either ptraj or C.
>>> carlos
>>>
>>> Robert Duke wrote:
>>>
>>>> Carlos -
>>>> I expect the problem is internal binary representation of the floating
>>>> point numbers. So the input trajectory file values may not be exactly
>>>> representable, though you are probably coming closer internally to your
>>>> input than it appears in your restart output (which also suffers from
>>>> not exactly representing the internal value). The only way to avoid
>>>> this sort of thing is with BCD - binary-coded decimal, which I believe
>>>> is probably available in Cobol and assembler :-) (probably PL/1 too).
>>>> Regards - Bob
>>>>
>>>> ----- Original Message ----- From: "Carlos Simmerling"
>>>> <carlos.csb.sunysb.edu>
>>>> To: <amber-developers.scripps.edu>
>>>> Sent: Monday, February 05, 2007 5:18 PM
>>>> Subject: amber-developers: ptraj precision
>>>>
>>>>
>>>>> I am reading a trajectory file into ptraj and writing as restart, with
>>>>> no actions (no imaging, etc).
>>>>>
>>>>> I don't get quite what is in the traj file, does anyone know why?
>>>>> The precision error is enough to affect the energies
>>>>> and I want the actual coordinates from the traj file, not ones that
>>>>> are +/- 0.000005 etc.
>>>>> yes, I know that the ones in the traj file aren't exactly what was in
>>>>> the original MD, but the point is to do an exact
>>>>> conversion to restart.
>>>>> thanks
>>>>> carlos
>>>>>
>>>>> EXAMPLE
>>>>> input trajectory file:
>>>>> 18.438 29.157 33.019 18.614 28.133 32.690
>>>>> output restart from ptraj:
>>>>> 18.4379997 29.1569996 33.0190010 18.6140003 28.1329994 32.6899986
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ===================================================================
>>>>> Carlos L. Simmerling, Ph.D.
>>>>> Associate Professor Phone: (631) 632-1336
>>>>> Center for Structural Biology Fax: (631) 632-1555
>>>>> CMM Bldg, Room G80
>>>>> Stony Brook University E-mail: carlos.simmerling.stonybrook.edu
>>>>> Stony Brook, NY 11794-5115
>>>>> ===================================================================
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
Received on Wed Feb 07 2007 - 06:07:46 PST
