Hi, Ben, Jason,
Indexing shouldn't matter since I am simply pasting values in a memory
location given to me and it should be irrelevant how that location is
indexed. I am really puzzled what can be wrong since XMIN returns
coordiantes every time it needs a gradient and if those coordinates
were incorrect XMIN would fail spectaculary in teh first place. Ben,
where do you fetch XMIN coordinates? One has to be careful, because
XMIN works in a totally different environment internally. When
coordiantes are returned XMIN makes sure that their serial numbers
correspond to those used externally. This has to do with frozen atoms.
If there are no frozen atoms XMIN internal arrays should exactly
correspond to the corresponding external arrays. One good test would
be to check if the same behavior happens with a totally flexible
system. Another thing is that the only way XMIN knows about a frozen
atom is when all three corresponding gradient values are exactly zero
(checked by ==0.0). I am not familiar with Sander at all, if there has
been any changes in marking frozen atoms, XMIN will fail. Hope this
helps. If you can give me a concrete example I can check it out, but I
have only used AmberTools, never Sander.
Best,
Istvan
Quoting Jason Swails <jason.swails.gmail.com>:
> xmin is written in C, correct? Could it be that array indexing may be an
> issue (C indexes from 0 whereas Fortran starts from 1)? Naive suggestion
> based on no code study whatsoever. Hopefully it's the issue, since it's
> easy to fix (and potentially explains the described effects).
>
> Feel free to deposit this email in the nearest receptacle (and luckily for
> the environment it's not written on paper).
>
> All the best,
> Jason
>
> On Thu, Jan 20, 2011 at 4:59 PM, Ben Roberts <ben.roberts.geek.nz> wrote:
>
>> Hi all,
>>
>> People may recall that some months ago I added functionality to lmod.f to
>> write out the coordinates (as restart files and/or as trajectory files)
>> during an XMIN minimisation. However, recently I've come across a rather
>> strange problem with the coordinates that are written.
>>
>> Specifically, the energy reported doesn't match the energy calculated from
>> the coordinates. The written-out coordinates involve massively stretched
>> bonds, while the energy calculation must have bonds at or near the reference
>> length. If I freeze all but two atoms in a particular system using a
>> bellymask, and compute the resulting bond energy, Amber reports a bond
>> energy of 0.3128 kcal/mol, while the bond energy computed from the
>> coordinates is 8.8964 kcal/mol.
>>
>> In a similar development, an attempt to minimise a structure with PUPIL
>> will see pairs of link atoms fly further and further apart until they're too
>> far apart for a link to be established. This is partly a PUPIL "feature" and
>> may be changed. However - and here I display my ignorance of the XMIN
>> algorithm - it seems to me that XMIN *may* be returning the "wrong"
>> coordinates to the rest of sander.
>>
>> Is anyone able to advise on what might be happening here, and in particular
>> why the coordinates are so different from what I might be expecting, so I
>> can work out how to fix it if appropriate? Especially, I'd like to know
>> whether this is expected behaviour for the XMIN algorithm. If it is, I just
>> need to sort PUPIL out; if not, we need to sort other things out too, I
>> guess.
>>
>> Cheers,
>> Ben
>> --
>> For greater security, I support S/MIME encryption.
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Jan 21 2011 - 01:30:03 PST
