Hi,
Yeah, we ran on it but it is also giving me a different result.
BK Dhanasekaran.
> Did you try cpptraj v16 with 32 bit yet?
>
> > Hai
>
> On Thu, Sep 15, 2016 at 2:28 AM, <dhanasekar.mbu.iisc.ernet.in> wrote:
>
>> Hi,
>>
>> I re-ran the analysis to test whether different cpptraj versions were
>> giving
>> rise to these discrepancies.
>>
>> I tested 20ns production run data on 2 systems, one with Ubuntu13 32 bit,
>> cpptraj15.00 (updated recently), and another with Ubuntu14 64-bit,
>> cpptraj16.12.
>>
>> I am attaching data files (.dat) and log files (.log) files for both these
>> runs.
>>
>> As you will see, the 32 bit systems are reporting this sudden jump in
>> RMSD,
>> whereas the 64-bit systems the showing the RMSD to be within 1 and 2
>> Angstrom(
>> i.e protein seems to be stable )
>> Inspite of upgrading from cpptraj version 14 to 15 (on 32bit machine), I
>> saw
>> the same jumps in RMSD. ( I have attached version14's rmsd.dat file too,
>> check
>> line number 4914-5100, 9914-10100 and 14914-15100 so on and so forth.
>> The rest of the RMSD values are identical for all .dat files(across all
>> platforms), except the frame numbers mentioned above.
>>
>> When viewing these trajectories in VMD, I didnt see any drastic changes
>> either.
>> I didnt get any errors during these cpptraj runs. Also, I made
>> sure that I was using the same data files, prmtop files and .in files.
>>
>> Please guide me about this.
>> What precautions should I take while running cpptraj on 32 bit Ubuntu
>> machines?
>> Help is highly appreciated.
>>
>> BK Dhanasekharan
>>
>>
>>
>> > Hi
>> >
>> > Can you try the most updated cpptraj (ambertools16) and let us know what
>> happens.
>>
>> By the way, are you sure you used identical input?
>> ** yes, we have used identical inputs in all cases.
>>
>> In the first figure, you have 100 ns while in the 2nd one you have 95 ns.
>> Can you
>> attach cpptraj log for 2nd run?
>> ** In the first figure, 100ns data was used.
>> In the 2nd figure, i have used 20ns data (sorry I mislabelled the figure).
>> But
>> we did not get any errors in the log reports.
>> >
>> > Hai
>> >
>> >> On Sep 8, 2016, at 11:05 AM, dhanasekar.mbu.iisc.ernet.in wrote: Hi, I
>> am
>> running prot+ligand simulation for a couple of systems for understanding
>> ligand
>> bound conformational changes. (I have used standard Amber14 protocols for
>> >> setting up the system, minimization, equilibration, etc.)
>> >> I have generated 100ns production run data and am using cpptraj version
>> 14.25
>> for the analysis.
>> >> I had earlier run rmsd calculations for all systems using the following
>> script
>> >> :
>> >> strip :WAT
>> >> strip :Na+
>> >> center :1-250 mass
>> >> autoimage
>> >> rms first out rmsd.dat :1-250.CA
>> >> atomicfluct out Per-res-fluct.dat :1-250 byres
>> >> atomicfluct out CA-fluct.dat .CA byatom
>> >> go
>> >> rmsd was below 2Ã… and system appeared stable.
>> >> I have to re-run rmsd again, and am facing some problems inspite of
>> using
>> same
>> >> crd files, same prmtop file and same rmsd.in file :
>> >> 1) RMSD data shows RMS as high as 25-45Ã… for a selected number of
>> snapshots
>> after an interval of 50 frames. I find this very weird since I used the
>> same
>> data ( crd files) a few days back with the same prmtop file and with the
>> same
>> cpptraj code, but did not see any of this earlier.
>> >> No errors were reported during cpptraj analysis. After data has been
>> generated,
>> >> it looks something like.
>> >> When visualised in VMD, I do not see any drastic changes in the prot
>> structure.
>> >> Everything appears to be OK.
>> >> Is there any way to rectify this ? What seems to be the problem? Is
>> this an
>> imaging issue or have the trajectories become corrupted? If so, please
>> suggest
>> >> remedial measures.
>> >> Thank you.
>> >> Regards,
>> >> B.K. Dhanasekaran
>> >> --
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Sep 16 2016 - 03:00:02 PDT
