Hi Bob,
yes it's fixed. You're right that it would be good to address accurate
restarting,
but for now I am willing to accept consistency in the files.
thanks for your help!
carlos
Robert Duke wrote:
> 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 Sun Feb 11 2007 - 06:07:10 PST
