Dear Jason
Thank you very much for your attention~~
I'll have a try.
Thanks and best regards!
Sincerely,
Xiaofeng Ji
At 2016-03-21 03:00:02, amber-request.ambermd.org wrote:
>Send AMBER mailing list submissions to
> amber.ambermd.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.ambermd.org/mailman/listinfo/amber
>or, via email, send a message with subject or body 'help' to
> amber-request.ambermd.org
>
>You can reach the person managing the list at
> amber-owner.ambermd.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of AMBER digest..."
>
>
>AMBER Mailing List Digest
>
>Today's Topics:
>
> 1. Re: GROMACS File Conversion Subtlety (Mark Abraham)
> 2. Re: problem in plotting total energy graphs by perl script
> (Bill Ross)
> 3. Re: GROMACS File Conversion Subtlety (Jason Swails)
> 4. Re: GROMACS File Conversion Subtlety (Mark Abraham)
> 5. Re: GROMACS File Conversion Subtlety (Daniel Roe)
> 6. Re: GROMACS File Conversion Subtlety (Daniel Roe)
> 7. Re: problem in plotting total energy graphs by perl script
> (Jason Swails)
> 8. Re: errors in plumed and amber14 patch (Jason Swails)
> (Jason Swails)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sat, 19 Mar 2016 19:32:57 +0000
>From: Mark Abraham <mark.j.abraham.gmail.com>
>Subject: Re: [AMBER] GROMACS File Conversion Subtlety
>To: AMBER Mailing List <amber.ambermd.org>
>Message-ID:
> <CAMNuMAS8QRX0tm424wdWHCxC9Q8QZbQHz7HikTV4efSikqFG9A.mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>Hi,
>
>On Sat, Mar 19, 2016 at 7:33 PM Jason Swails <jason.swails.gmail.com> wrote:
>
>> On Fri, Mar 18, 2016 at 9:04 PM, Mark Abraham <mark.j.abraham.gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > The GROMACS TRR format is based on XDR, which is defined to be a
>> big-endian
>> > format in a 20-year-old IETF standard. I think there is no good reason to
>> > write a tool to be able to write non-confoming XDR, and so no reason for
>> > any tools to be able to read such files. I also think we have better
>> things
>> > to do than rippling "please support little-endian TRR" requests to all
>> the
>> > different software packages that might handle such files! :-)
>> >
>>
>> ?Perhaps, but the current behavior of choking by segfault is decidedly
>> suboptimal.
>
>
>I'm skeptical that this is the behaviour. There's certainly been no bug
>report at http://redmine.gromacs.org/. There's a magic number at the start
>of every trr frame header, even though it is redundant, precisely to act as
>such a catch-all.
>
>
>> I can understand not wanting to spend the time to implement
>> little endian recognition, but putting in a magic number check to print out
>> a useful error message seems to me to be a clear, easy improvement over the
>> current behavior (if the magic number doesn't match what's expected, it's
>> clearly not a TRR and you can quit saying so).
>>
>
>Sure, but we have that kind of behaviour :-) See e.g.
>https://github.com/gromacs/gromacs/blob/master/src/gromacs/fileio/trrio.cpp#L87
>.
>
>
>> That said, other packages that handle TRR files *do* handle little-endian
>> encodings (specifically VMD, whose plugins GROMACS links to for every
>> other file type).
>
>
>Yes, but IIRC that's just a side-effect of having to handle formats like
>DCD that don't specify. The way to be portable is to specify, document, and
>have people follow it, rather than require everyone else write code tricks.
>
>In a little-endian world, displaying an error message at the
>
>beginning rather than a segfault somewhere in the middle is a clear
>> improvement in any program's UI. Such things would probably help GROMACS
>> play nicer in a more inclusive ecosystem.
>>
>
>Indeed. I'll look forward to seeing such input so I can fix it (e.g. at
>http://redmine.gromacs.org/). I expect the file handling itself is fine,
>but some of the analysis tools might be ignoring the failure ;-)
>
>Mark
>
>
>> All the best,
>> Jason
>>
>> --
>> Jason M. Swails
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
>
>------------------------------
>
>Message: 2
>Date: Sat, 19 Mar 2016 13:11:40 -0700
>From: Bill Ross <ross.cgl.ucsf.edu>
>Subject: Re: [AMBER] problem in plotting total energy graphs by perl
> script
>To: AMBER Mailing List <amber.ambermd.org>
>Message-ID: <56EDB27C.20808.cgl.ucsf.edu>
>Content-Type: text/plain; charset=windows-1252; format=flowed
>
>Have you looked at mden file contents? They could be easier to work with.
>
>Bill
>
>On 3/19/16 3:16 AM, Sehrish Naz Aijaz wrote:
>> Dear Hai,
>> I try to run this in my amber12 but it gives the following error. Can you explain this to me...
>> Traceback (most recent call last):
>> File "/usr/local/amber14/bin/mdout_analyzer.py", line 3, in <module>
>> from tkFileDialog import askopenfilenames
>> ImportError: No module named tkFileDialog
>>
>> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>>
>> From: Hai Nguyen<mailto:nhai.qn.gmail.com>
>> Sent: 19 March 2016 14:48
>> To: AMBER Mailing List<mailto:amber.ambermd.org>
>> Subject: Re: [AMBER] problem in plotting total energy graphs by perl script
>>
>> I think it should be compatible (Jason might correct me if I am wrong).
>>
>> Here is the tutorial: http://jswails.wikidot.com/helpful-scripts#toc8
>>
>> Cheers
>> Hai
>>
>> On Sat, Mar 19, 2016 at 2:26 AM, Sehrish Naz Aijaz <sehrish.naz.outlook.com>
>> wrote:
>>
>>> Dear Hai,
>>> I have amber12 in my system. Is this script compatible for amber12 which I
>>> think not compatible with amber12. So what should I do???
>>>
>>> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>>> From: Hai Nguyen<mailto:nhai.qn.gmail.com>
>>> Sent: 19 March 2016 13:56
>>> To: AMBER Mailing List<mailto:amber.ambermd.org>
>>> Subject: Re: [AMBER] problem in plotting total energy graphs by perl script
>>>
>>> Can you try to use mdout_analyzer.py in AmberTools15? (It's pain to debug
>>> Perl code)
>>>
>>> Check http://ambermd.org/doc12/Amber15.pdf (page 515)
>>>
>>> Hai
>>>
>>> On Sat, Mar 19, 2016 at 1:25 AM, Sehrish Naz Aijaz <
>>> sehrish.naz.outlook.com>
>>> wrote:
>>>
>>>> Dear all,
>>>> I had run 10 ns simulation (AMBER12) of large compounds in TIP3P box to
>>>> check their stable conformation with time. the input file I used for
>>>> production is
>>>> NPT production with no restrains
>>>> &cntrl
>>>> imin=0, ntx=7, irest=1, ntrx=1, ntxo=1,
>>>> ntpr=500, ntwx=500, ntwv=200, ntwe=200,
>>>> ntf=2, ntb=2, cut=10.0,
>>>> nsnb=100, igb=0,
>>>> nstlim=2000000,
>>>> t=0.0, dt=0.001,
>>>> ntt=3, gamma_ln=1.0, tempi=300.0, temp0=300.0,
>>>> vlimit=20,
>>>> ntp=1, taup=1.0, pres0=1.0, comp=44.6,
>>>> ntc=2, tol=0.00000001,
>>>> /
>>>>
>>>> after getting the production files. I tried to calculate the total energy
>>>> graphs of the system by using perl script as follows
>>>> . #!/usr/bin/perl
>>>>
>>>>
>>>> if ($#ARGV < 0) {
>>>> print " Incorrect usage...\n";
>>>> exit;
>>>> }
>>>>
>>>>
>>>> foreach $i ( 0..$#ARGV ) {
>>>> $filein = $ARGV[$i];
>>>> $checkfile = $filein;
>>>> $checkfile =~ s/\.Z//;
>>>> if ( $filein ne $checkfile ) {
>>>> open(INPUT, "zcat $filein |") ||
>>>> die "Cannot open compressed $filein -- $!\n";
>>>> } else {
>>>> open(INPUT, $filein) || die "Cannot open $filein -- $!\n";
>>>> }
>>>> print "Processing sander output file ($filein)...\n";
>>>> &process_input;
>>>> close(INPUT);
>>>> }
>>>>
>>>> print "Starting output...\n";
>>>> .sortedkeys = sort by_number keys(%TIME);
>>>> .sortedavgkeys = sort by_number keys(%AVG_TIME);
>>>>
>>>> foreach $i ( TEMP, TSOLUTE, TSOLVENT, PRES, EKCMT, ETOT, EKTOT, EPTOT,
>>>> DENSITY, VOLUME, ESCF ) {
>>>> print "Outputing summary.$i\n";
>>>> open(OUTPUT, "> summary.$i");
>>>> %outarray = eval "\%$i";
>>>> foreach $j ( .sortedkeys ) {
>>>> print OUTPUT "$j ", $outarray{$j}, "\n";
>>>> }
>>>> close (OUTPUT);
>>>>
>>>> print "Outputing summary_avg.$i\n";
>>>> open(OUTPUT, "> summary_avg.$i");
>>>> %outarray = eval "\%AVG_$i";
>>>> foreach $j ( .sortedavgkeys ) {
>>>> print OUTPUT "$j ", $outarray{$j}, "\n";
>>>> }
>>>> close (OUTPUT);
>>>>
>>>> print "Outputing summary_rms.$i\n";
>>>> open(OUTPUT, "> summary_rms.$i");
>>>> %outarray = eval "\%RMS_$i";
>>>> foreach $j ( .sortedavgkeys ) {
>>>> print OUTPUT "$j ", $outarray{$j}, "\n";
>>>> }
>>>> close (OUTPUT);
>>>>
>>>>
>>>> }
>>>>
>>>>
>>>> sub by_number {
>>>> if ($a < $b) {
>>>> -1;
>>>> } elsif ($a == $b) {
>>>> 0;
>>>> } elsif ($a > $b) {
>>>> 1;
>>>> }
>>>> }
>>>>
>>>> sub process_input {
>>>>
>>>> $status = 0;
>>>> $debug = 0;
>>>> while ( <INPUT> ) {
>>>> $string = $_;
>>>>
>>>> print $_ if ( ! /NB-upda/ && $debug );
>>>>
>>>> if (/A V E R A G E S/) {
>>>> $averages = 1;
>>>> ($averages_over) = /.*O V E R.*(\d*).*S T E P S/;
>>>> }
>>>>
>>>> $rms = 1 if (/R M S/);
>>>>
>>>> if (/NSTEP/) {
>>>> ($time, $temp, $pres) =
>>>> /NSTEP =.*TIME.* =(.*\d*\.\d*).*TEMP.* =(.*\d*\.\d*).*PRESS =
>>>> (.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "time is $time, temp is $temp, pres is $pres\n";
>>>> }
>>>> $_ = <INPUT>;
>>>>
>>>> if (/Etot/) {
>>>> ($etot, $ektot, $eptot) =
>>>>
>>>> /Etot.*=(.*\d*\.\d*).*EKtot.*=(.*\d*\.\d*).*EPtot.*=(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "Etot is $etot, ektot is $ektot, eptot is $eptot\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> }
>>>> if (/BOND.*ANGLE.*DIHED/) {
>>>> ($bond, $angle, $dihedral) =
>>>>
>>>> /BOND.*=(.*\d*\.\d*).*ANGLE.*=(.*\d*\.\d*).*DIHED.*=(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "bond is $bond, angle is $angle, dihedral is
>>>> $dihedral\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> }
>>>> if (/1-4 NB/) {
>>>> ($nb14, $eel14, $nb) =
>>>> /1-4 NB.*=(.*\d*\.\d*).*1-4
>>>> EEL.*=(.*\d*\.\d*).*VDWAALS.*=(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "nb14 is $nb14, eel14 is $eel14, vdwaals is $nb\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> }
>>>> if (/EELEC/) {
>>>> ($eel, $ehbond, $constraint) =
>>>>
>>>> /EELEC.*=(.*\d*\.\d*).*EHBOND.*=(.*\d*\.\d*).*CONSTRAINT.*=(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "eel is $eel, ehbond is $ehbond, constraint is
>>>> $constraint\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> #
>>>> # check to see if EAMBER is in the mdout file (present when
>>>> # NTR=1)
>>>> #
>>>> if ( /EAMBER/ ) {
>>>> $_ = <INPUT>;
>>>> }
>>>> }
>>>> if (/EKCMT/) {
>>>> ($ekcmt, $virial, $volume) =
>>>>
>>>> /EKCMT.*=(.*\d*\.\d*).*VIRIAL.*=(.*\d*\.\d*).*VOLUME.*=(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "Ekcmt is $ekcmt, virial is $virial, volume is
>>>> $volume\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> }
>>>> if (/T_SOLUTE/) {
>>>> ($tsolute, $tsolvent) =
>>>> /T_SOLUTE =(.*\d*\.\d*).*T_SOLVENT =(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "Temp solute is $tsolute, temp solvent is $tsolvent\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> }
>>>>
>>>> if (/Density/) {
>>>> ($density) = /.*Density.*=(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "Density is $density\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> }
>>>>
>>>> if (/Etot/) {
>>>> ($etot, $ektot, $eptot) =
>>>>
>>>> /Etot.*=(.*\d*\.\d*).*EKtot.*=(.*\d*\.\d*).*EPtot.*=(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "Etot is $etot, ektot is $ektot, eptot is $eptot\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> }
>>>> if (/ESCF/) {
>>>> ($escf) =
>>>> /.*ESCF.*=(.*\d*\.\d*)/;
>>>> if ( $debug ) {
>>>> print $_;
>>>> print "ESCF is $escf\n";
>>>> }
>>>> $_ = <INPUT>;
>>>> }
>>>>
>>>> # update arrays
>>>>
>>>> if ( $averages == 1 ) {
>>>> $AVG_TIME{$time} = $time;
>>>> $AVG_TEMP{$time} = $temp;
>>>> $AVG_PRES{$time} = $pres;
>>>> $AVG_ETOT{$time} = $etot;
>>>> $AVG_EKTOT{$time} = $ektot;
>>>> $AVG_EPTOT{$time} = $eptot;
>>>> $AVG_BOND{$time} = $bond;
>>>> $AVG_ANGLE{$time} = $angle;
>>>> $AVG_DIHEDRAL{$time} = $dihedral;
>>>> $AVG_NB14{$time} = $nb14;
>>>> $AVG_EEL14{$time} = $eel14;
>>>> $AVG_NB{$time} = $nb;
>>>> $AVG_EEL{$time} = $eel;
>>>> $AVG_EHBOND{$time} = $ehbond;
>>>> $AVG_CONSTRAINT{$time} = $constraint;
>>>> $AVG_EKCMT{$time} = $ekcmt;
>>>> $AVG_VIRIAL{$time} = $virial;
>>>> $AVG_VOLUME{$time} = $volume;
>>>> $AVG_TSOLUTE{$time} = $tsolute;
>>>> $AVG_TSOLVENT{$time} = $tsolvent;
>>>> $AVG_DENSITY{$time} = $density;
>>>> $AVG_ESCF{$time} = $escf;
>>>> $averages = 0;
>>>> } elsif ( $rms == 1 ) {
>>>> $RMS_TIME{$time} = $time;
>>>> $RMS_TEMP{$time} = $temp;
>>>> $RMS_PRES{$time} = $pres;
>>>> $RMS_ETOT{$time} = $etot;
>>>> $RMS_EKTOT{$time} = $ektot;
>>>> $RMS_EPTOT{$time} = $eptot;
>>>> $RMS_BOND{$time} = $bond;
>>>> $RMS_ANGLE{$time} = $angle;
>>>> $RMS_DIHEDRAL{$time} = $dihedral;
>>>> $RMS_NB14{$time} = $nb14;
>>>> $RMS_EEL14{$time} = $eel14;
>>>> $RMS_NB{$time} = $nb;
>>>> $RMS_EEL{$time} = $eel;
>>>> $RMS_EHBOND{$time} = $ehbond;
>>>> $RMS_CONSTRAINT{$time} = $constraint;
>>>> $RMS_EKCMT{$time} = $ekcmt;
>>>> $RMS_VIRIAL{$time} = $virial;
>>>> $RMS_VOLUME{$time} = $volume;
>>>> $RMS_TSOLUTE{$time} = $tsolute;
>>>> $RMS_TSOLVENT{$time} = $tsolvent;
>>>> $RMS_DENSITY{$time} = $density;
>>>> $RMS_ESCF{$time} = $escf;
>>>>
>>>> $rms = 0;
>>>> } else {
>>>> $TIME{$time} = $time;
>>>> $TEMP{$time} = $temp;
>>>> $PRES{$time} = $pres;
>>>> $ETOT{$time} = $etot;
>>>> $EKTOT{$time} = $ektot;
>>>> $EPTOT{$time} = $eptot;
>>>> $BOND{$time} = $bond;
>>>> $ANGLE{$time} = $angle;
>>>> $DIHEDRAL{$time} = $dihedral;
>>>> $NB14{$time} = $nb14;
>>>> $EEL14{$time} = $eel14;
>>>> $NB{$time} = $nb;
>>>> $EEL{$time} = $eel;
>>>> $EHBOND{$time} = $ehbond;
>>>> $CONSTRAINT{$time} = $constraint;
>>>> $EKCMT{$time} = $ekcmt;
>>>> $VIRIAL{$time} = $virial;
>>>> $VOLUME{$time} = $volume;
>>>> $TSOLUTE{$time} = $tsolute;
>>>> $TSOLVENT{$time} = $tsolvent;
>>>> $DENSITY{$time} = $density;
>>>> $ESCF{$time} = $escf;
>>>> }
>>>>
>>>> }
>>>> }
>>>> }
>>>>
>>>> But after running this perl script on the output files I got graph
>>>> displaying half values of output files as attached here. Can anybody
>>> guide
>>>> me whats wrong with the perl graph or my input file as my output files
>>> are
>>>> printing all values for energy but perl script plot half values???
>>>>
>>>>
>>>>
>>>> Sent from Mail for Windows 10
>>>>
>>>>
>>>> _______________________________________________
>>>> AMBER mailing list
>>>> AMBER.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>
>>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Sun, 20 Mar 2016 08:03:03 -0700
>From: Jason Swails <jason.swails.gmail.com>
>Subject: Re: [AMBER] GROMACS File Conversion Subtlety
>To: AMBER Mailing List <amber.ambermd.org>
>Message-ID:
> <CAEk9e3r2TCnCL1Na09GK2JByEODvqfanrOh=TVEGN+6+BHaMJg.mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>On Sat, Mar 19, 2016 at 12:32 PM, Mark Abraham <mark.j.abraham.gmail.com>
>wrote:
>
>> Hi,
>>
>> On Sat, Mar 19, 2016 at 7:33 PM Jason Swails <jason.swails.gmail.com>
>> wrote:
>>
>> > On Fri, Mar 18, 2016 at 9:04 PM, Mark Abraham <mark.j.abraham.gmail.com>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > The GROMACS TRR format is based on XDR, which is defined to be a
>> > big-endian
>> > > format in a 20-year-old IETF standard. I think there is no good reason
>> to
>> > > write a tool to be able to write non-confoming XDR, and so no reason
>> for
>> > > any tools to be able to read such files. I also think we have better
>> > things
>> > > to do than rippling "please support little-endian TRR" requests to all
>> > the
>> > > different software packages that might handle such files! :-)
>> > >
>> >
>> > ?Perhaps, but the current behavior of choking by segfault is decidedly
>> > suboptimal.
>>
>>
>> I'm skeptical that this is the behaviour.
>
>
>??
>http://redmine.gromacs.org/issues/1926
>? -- the behavior there (and the reason it took so long to debug) is a
>GROMACS segfault in basic analysis.
>
>Here's the initial report: http://archive.ambermd.org/201603/0335.html
>
>And the repro by the cpptraj developer:
>http://archive.ambermd.org/201603/0336.html
>
>So yea, it was a segfault.
>?
>
>--
>Jason M. Swails
>
>
>------------------------------
>
>Message: 4
>Date: Sun, 20 Mar 2016 15:26:00 +0000
>From: Mark Abraham <mark.j.abraham.gmail.com>
>Subject: Re: [AMBER] GROMACS File Conversion Subtlety
>To: AMBER Mailing List <amber.ambermd.org>
>Message-ID:
> <CAMNuMAQZcZKVSGRM7Q_2zvDRpwXPbe13DoVtpE2Uwi_7BqPGYg.mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>Hi,
>
>That initial report (from do_x3dna) isn't from a GROMACS tool. However,
>Daniel has said it can be reproduced with gmx. To reproduce a segfault and
>see how to stop it, I need one of these "little-endian TRR" input files
>that might segfault. Hopefully someone who has cpptraj installed and knows
>how to make one can do so, and e.g. upload at
>http://redmine.gromacs.org/issues/1926 :-)
>
>Mark
>
>On Sun, Mar 20, 2016 at 4:03 PM Jason Swails <jason.swails.gmail.com> wrote:
>
>> On Sat, Mar 19, 2016 at 12:32 PM, Mark Abraham <mark.j.abraham.gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > On Sat, Mar 19, 2016 at 7:33 PM Jason Swails <jason.swails.gmail.com>
>> > wrote:
>> >
>> > > On Fri, Mar 18, 2016 at 9:04 PM, Mark Abraham <
>> mark.j.abraham.gmail.com>
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > The GROMACS TRR format is based on XDR, which is defined to be a
>> > > big-endian
>> > > > format in a 20-year-old IETF standard. I think there is no good
>> reason
>> > to
>> > > > write a tool to be able to write non-confoming XDR, and so no reason
>> > for
>> > > > any tools to be able to read such files. I also think we have better
>> > > things
>> > > > to do than rippling "please support little-endian TRR" requests to
>> all
>> > > the
>> > > > different software packages that might handle such files! :-)
>> > > >
>> > >
>> > > ?Perhaps, but the current behavior of choking by segfault is decidedly
>> > > suboptimal.
>> >
>> >
>> > I'm skeptical that this is the behaviour.
>>
>>
>> ??
>> http://redmine.gromacs.org/issues/1926
>> ? -- the behavior there (and the reason it took so long to debug) is a
>> GROMACS segfault in basic analysis.
>>
>> Here's the initial report: http://archive.ambermd.org/201603/0335.html
>>
>> And the repro by the cpptraj developer:
>> http://archive.ambermd.org/201603/0336.html
>>
>> So yea, it was a segfault.
>> ?
>>
>> --
>> Jason M. Swails
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
>
>------------------------------
>
>Message: 5
>Date: Sun, 20 Mar 2016 09:29:54 -0600
>From: Daniel Roe <daniel.r.roe.gmail.com>
>Subject: Re: [AMBER] GROMACS File Conversion Subtlety
>To: AMBER Mailing List <amber.ambermd.org>
>Message-ID:
> <CAAC0qObR_yM1vxJG5Pti1bJs0P3Ny5Hqr9SYukk7tvd+E79NsQ.mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>Hi,
>
>I'm going to make sure I can reproduce this behavior on another
>machine first. If so, I will then upload the files necessary for
>reproducing the behavior.
>
>-Dan
>
>On Sun, Mar 20, 2016 at 9:26 AM, Mark Abraham <mark.j.abraham.gmail.com> wrote:
>> Hi,
>>
>> That initial report (from do_x3dna) isn't from a GROMACS tool. However,
>> Daniel has said it can be reproduced with gmx. To reproduce a segfault and
>> see how to stop it, I need one of these "little-endian TRR" input files
>> that might segfault. Hopefully someone who has cpptraj installed and knows
>> how to make one can do so, and e.g. upload at
>> http://redmine.gromacs.org/issues/1926 :-)
>>
>> Mark
>>
>> On Sun, Mar 20, 2016 at 4:03 PM Jason Swails <jason.swails.gmail.com> wrote:
>>
>>> On Sat, Mar 19, 2016 at 12:32 PM, Mark Abraham <mark.j.abraham.gmail.com>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > On Sat, Mar 19, 2016 at 7:33 PM Jason Swails <jason.swails.gmail.com>
>>> > wrote:
>>> >
>>> > > On Fri, Mar 18, 2016 at 9:04 PM, Mark Abraham <
>>> mark.j.abraham.gmail.com>
>>> > > wrote:
>>> > >
>>> > > > Hi,
>>> > > >
>>> > > > The GROMACS TRR format is based on XDR, which is defined to be a
>>> > > big-endian
>>> > > > format in a 20-year-old IETF standard. I think there is no good
>>> reason
>>> > to
>>> > > > write a tool to be able to write non-confoming XDR, and so no reason
>>> > for
>>> > > > any tools to be able to read such files. I also think we have better
>>> > > things
>>> > > > to do than rippling "please support little-endian TRR" requests to
>>> all
>>> > > the
>>> > > > different software packages that might handle such files! :-)
>>> > > >
>>> > >
>>> > > Perhaps, but the current behavior of choking by segfault is decidedly
>>> > > suboptimal.
>>> >
>>> >
>>> > I'm skeptical that this is the behaviour.
>>>
>>>
>>>
>>> http://redmine.gromacs.org/issues/1926
>>> -- the behavior there (and the reason it took so long to debug) is a
>>> GROMACS segfault in basic analysis.
>>>
>>> Here's the initial report: http://archive.ambermd.org/201603/0335.html
>>>
>>> And the repro by the cpptraj developer:
>>> http://archive.ambermd.org/201603/0336.html
>>>
>>> So yea, it was a segfault.
>>>
>>>
>>> --
>>> Jason M. Swails
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
>--
>-------------------------
>Daniel R. Roe, PhD
>Department of Medicinal Chemistry
>University of Utah
>30 South 2000 East, Room 307
>Salt Lake City, UT 84112-5820
>http://home.chpc.utah.edu/~cheatham/
>(801) 587-9652
>(801) 585-6208 (Fax)
>
>
>
>------------------------------
>
>Message: 6
>Date: Sun, 20 Mar 2016 10:00:33 -0600
>From: Daniel Roe <daniel.r.roe.gmail.com>
>Subject: Re: [AMBER] GROMACS File Conversion Subtlety
>To: AMBER Mailing List <amber.ambermd.org>
>Message-ID:
> <CAAC0qObrswpRK5LWhy=mzs8mzEsdqODxk+gAL1L9OQrVTsCg0w.mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>Hi,
>
>I was able to reproduce the crash on another machine. I uploaded files
>you can use to reproduce the behavior to the bug report. Let me know
>if you need any more info.
>
>The current GitHub version of cpptraj now produces big-endian TRR
>files which work with Gromacs analysis tools.
>
>-Dan
>
>On Sun, Mar 20, 2016 at 9:29 AM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>> Hi,
>>
>> I'm going to make sure I can reproduce this behavior on another
>> machine first. If so, I will then upload the files necessary for
>> reproducing the behavior.
>>
>> -Dan
>>
>> On Sun, Mar 20, 2016 at 9:26 AM, Mark Abraham <mark.j.abraham.gmail.com> wrote:
>>> Hi,
>>>
>>> That initial report (from do_x3dna) isn't from a GROMACS tool. However,
>>> Daniel has said it can be reproduced with gmx. To reproduce a segfault and
>>> see how to stop it, I need one of these "little-endian TRR" input files
>>> that might segfault. Hopefully someone who has cpptraj installed and knows
>>> how to make one can do so, and e.g. upload at
>>> http://redmine.gromacs.org/issues/1926 :-)
>>>
>>> Mark
>>>
>>> On Sun, Mar 20, 2016 at 4:03 PM Jason Swails <jason.swails.gmail.com> wrote:
>>>
>>>> On Sat, Mar 19, 2016 at 12:32 PM, Mark Abraham <mark.j.abraham.gmail.com>
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > On Sat, Mar 19, 2016 at 7:33 PM Jason Swails <jason.swails.gmail.com>
>>>> > wrote:
>>>> >
>>>> > > On Fri, Mar 18, 2016 at 9:04 PM, Mark Abraham <
>>>> mark.j.abraham.gmail.com>
>>>> > > wrote:
>>>> > >
>>>> > > > Hi,
>>>> > > >
>>>> > > > The GROMACS TRR format is based on XDR, which is defined to be a
>>>> > > big-endian
>>>> > > > format in a 20-year-old IETF standard. I think there is no good
>>>> reason
>>>> > to
>>>> > > > write a tool to be able to write non-confoming XDR, and so no reason
>>>> > for
>>>> > > > any tools to be able to read such files. I also think we have better
>>>> > > things
>>>> > > > to do than rippling "please support little-endian TRR" requests to
>>>> all
>>>> > > the
>>>> > > > different software packages that might handle such files! :-)
>>>> > > >
>>>> > >
>>>> > > Perhaps, but the current behavior of choking by segfault is decidedly
>>>> > > suboptimal.
>>>> >
>>>> >
>>>> > I'm skeptical that this is the behaviour.
>>>>
>>>>
>>>>
>>>> http://redmine.gromacs.org/issues/1926
>>>> -- the behavior there (and the reason it took so long to debug) is a
>>>> GROMACS segfault in basic analysis.
>>>>
>>>> Here's the initial report: http://archive.ambermd.org/201603/0335.html
>>>>
>>>> And the repro by the cpptraj developer:
>>>> http://archive.ambermd.org/201603/0336.html
>>>>
>>>> So yea, it was a segfault.
>>>>
>>>>
>>>> --
>>>> Jason M. Swails
>>>> _______________________________________________
>>>> AMBER mailing list
>>>> AMBER.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>>
>>
>> --
>> -------------------------
>> Daniel R. Roe, PhD
>> Department of Medicinal Chemistry
>> University of Utah
>> 30 South 2000 East, Room 307
>> Salt Lake City, UT 84112-5820
>> http://home.chpc.utah.edu/~cheatham/
>> (801) 587-9652
>> (801) 585-6208 (Fax)
>
>
>
>--
>-------------------------
>Daniel R. Roe, PhD
>Department of Medicinal Chemistry
>University of Utah
>30 South 2000 East, Room 307
>Salt Lake City, UT 84112-5820
>http://home.chpc.utah.edu/~cheatham/
>(801) 587-9652
>(801) 585-6208 (Fax)
>
>
>
>------------------------------
>
>Message: 7
>Date: Sun, 20 Mar 2016 13:12:40 -0400
>From: Jason Swails <jason.swails.gmail.com>
>Subject: Re: [AMBER] problem in plotting total energy graphs by perl
> script
>To: AMBER Mailing List <amber.ambermd.org>
>Message-ID:
> <CAEk9e3rUfQT7AheUP83fqAhoD598qPi5tfMi3s9F3Kghs11_fw.mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>On Sat, Mar 19, 2016 at 6:29 AM, Sehrish Naz Aijaz <sehrish.naz.outlook.com>
>wrote:
>
>> Dear Hai,
>> I try to run this in my amber14 but it gives the following error. Can you
>> suggest something regarding this to me...
>> Traceback (most recent call last):
>> File "/usr/local/amber14/bin/mdout_analyzer.py", line 3, in <module>
>> from tkFileDialog import askopenfilenames
>> ImportError: No module named tkFileDialog
>>
>
>?You need to install all of the Python packages listed in
>http://ambermd.org/ubuntu.html
>
>HTH,
>Jason
>
>--
>Jason M. Swails
>
>
>------------------------------
>
>Message: 8
>Date: Sun, 20 Mar 2016 13:14:40 -0400
>From: Jason Swails <jason.swails.gmail.com>
>Subject: Re: [AMBER] errors in plumed and amber14 patch (Jason Swails)
>To: AMBER Mailing List <amber.ambermd.org>
>Message-ID:
> <CAEk9e3otbVy_Ev3Ba7_dTsVJAqhZP_8bqOZe4ZWwRPFCdC_wuA.mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>On Thu, Mar 17, 2016 at 10:12 PM, jixiaofeng <benniu2004.163.com> wrote:
>
>>
>>
>> Dear Sir,
>>
>> Thank you very much for your reply.
>>
>> I have installed Amber14+amberTool15, but PLUMED was not patched
>> successfully. So I changed from tool14 to tool15.
>> If AmberTools 15 is bundled with PLUMED support, is this means that I
>> only need to install Amber14+amberTool15 and PLUMED seperately, Amber can
>> use PLUMED directly. Is there any additional settings in the process of
>> using ?
>>
>
>?I don't think there are any additional settings. All you have to do is
>install PLUMED to make it available.
>
>HTH,
>Jason
>
>--
>Jason M. Swails
>
>
>------------------------------
>
>_______________________________________________
>AMBER mailing list
>AMBER.ambermd.org
>http://lists.ambermd.org/mailman/listinfo/amber
>
>
>End of AMBER Digest, Vol 1521, Issue 1
>**************************************
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Mar 20 2016 - 20:30:04 PDT
