On Thu, Jul 15, 2010, Josh Berryman wrote:
>
> I have to own up that I have been using nab a little bit differently to the
> way it was probably intended, as a library of useful functions callable from
> C++ programs rather than as a self-contained programming language. Perhaps
> if I were doing things properly, which is to say having only .nab source
> files, "nabout" would be automagically defined and I wouldn't have had this
> error.
This is fine...we hope that people will learn how to use libsff.a in novel
ways. In fact, the nab compiler sticks the following line in C code that it
creates:
nabout = stdout; /*default*/
(This is done right at the top of the main program.) I recommend that you
do something similar in your driver code. You will probably need to include
<stdio.h> and "nabcode.h" in the driver, and remember that this effectively
makes "nabout" a reserved global variable.
The advantage of this approach is that you don't need to change the sff code
every time a new release comes out, and you can keep up with bugfixes, etc.
Plus, there are many places in sff that use nabout, so its better to get it
defined the way it should be. Plus, you can then point nabout somewhere else
if you don't want it going to stdout, which was the whole point of introducing
this variable in the first place....
>
> Looking at the documentation, it seems that MORT is intended more for this
> purpose, but as both approaches lead back to the sff in the end I feel like
> I might as well stick with nab, which I know my way around.
I agree...the learning curve for MORT is pretty steep. There is a
"programmers guide" in $AMBERHOME/doc/leap_pg.pdf, but mort is mainly useful
if you want/need to manipulate molecules by means of lists of bonds, angles,
etc.
....good luck....dac
p.s.: the ptraj problems you report indeed look completely separate.
> indulging me.
>
> Josh
>
>
>
>
> On Wed, Jul 14, 2010 at 6:36 PM, case <case.biomaps.rutgers.edu> wrote:
>
> > On Wed, Jul 14, 2010, Josh Berryman wrote:
> >
> > > Hello everyone. I have/had a problem with my AmberTools 1.4 install (new
> > > and fully patched this morning); running on 64-bit ubuntu 10.04.
> >
> > >
> > > I found that rdparm (called by the nab function readparm) was
> > segfaulting.
> > > Replacing all instances of "nabout" by "stdout" and recompiling seems to
> > > fix this; although I am sure there are sound reasons for having a special
> > > filepointer this is a good enough workaround for my personal use.
> >
> > Can you give some details?
> >
> > 1. Do any of the test cases fail? If not, can you post a small program
> > that illustrates the problem?
> >
> > 2. When you say "replace all instances of nabout with stdout", in what
> > file(s)
> > did you make this replacement? What prompted you to think that this change
> > would fix the problem?
> >
> > ...thx....dac
> >
> >
> > _______________________________________________
> > 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
--
================================================================
David A. Case | email:
BioMaPS Institute and Dept. of | case.biomaps.rutgers.edu
Chemistry & Chemical Biology | fax: +1-732-445-5958
Rutgers University | phone: +1-732-445-5885
610 Taylor Rd. |
Piscataway, NJ 08854-8087 USA | http://casegroup.rutgers.edu
================================================================
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Jul 15 2010 - 06:00:03 PDT
