Re: [AMBER-Developers] Compilation of AMBER Tools

From: Taisung Lee <taisung.biomaps.rutgers.edu>
Date: Thu, 9 Jun 2011 08:00:20 -0400

I believe the "allocatable array inside a structure" problem is my fault. I
am not sure if it is F2003-specific or not. It works for me with gFortran
4.4.5 and ifort 12.0 (on both Linux and Windows). Anyway, I will see if
there is any possible way to re-write this part.

 

Taisung

 

 

> -----Original Message-----

> From: David A. Case [mailto:case.biomaps.rutgers.edu]

> Sent: Thursday, June 09, 2011 4:32 AM

> To: AMBER Developers Mailing List

> Subject: Re: [AMBER-Developers] Compilation of AMBER Tools

>

> On Wed, Jun 08, 2011, Ross Walker wrote:

> >

> > We used pointers I believe. Since the allocatable argument inside a

> > structure is F2003 if I remember correctly. We could just switch back to

> > that to avoid issues.

>

> Ah...I forgot that part about being inside a struct. If we are sure that

> this

> is an F2003 extension, we could ask people not to make use of it.

>

> >

> > mm_options.l(31): error: identifier "hcp_h" is undefined

> > { ECHO; hcp_h = atof( &mmotext[6] ); }

> > ^

>

> I'm pretty sure this arises because there was an lex.mm_options.c file
left

> over from a previous compilation. This was an effort to accommodate
people

> who don't have flex installed: the code would fall back to using

> lex.mm_options.c if it is present, but this doesn't work if it is out of

> date.

>

> I'm not entirely happy with this explanation, since the "clean" target in

> AmberTools/src/sff should remove the old version. So: can you check date

> stamps to see what could be happening? Compare the time-stamp of

> lex.mm_options.c with that of mm_options.l Note that the current git

> version

> of mm_options.l (and hence lex.mm_options.c) does *not* have either hcp_h

> or cutres, so somehow you are getting a file from an earlier version.

>

> We could force the Makefile to re-make the .c file, effectively forcing

> users

> to install flex. Maybe that is the best option. But knowing the exact

> sequence of commands that leads to this would also help. I suspect that

> this

> affects developers who tend to make and re-make amber in the same
directory;

> but it still should get fixed.

>

> ...dac

>

>

> _______________________________________________

> 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 Thu Jun 09 2011 - 05:30:02 PDT
Custom Search