On 9/3/2010, at 3:35 p.m., Ross Walker wrote:
> Hi Ben
>
>> However, it seems that others have beaten me to it. Is the general
>> feeling that the Intel compilers are just stricter than they were (and
>> the code is doing something non-standard), or rather that the compilers
>> are themselves broken?
>
> This is almost certainly a compiler bug. As a workaround though could you
> try changing the following:
>
> integer natom, ntypes, nbonh, ntheth, nphih, next, nres, &
> !7
> nbona, ntheta, nphia, numbnd, numang, nptra, nphb, &
> !14
> ifbox, ifcap, nspm, numextra, ncopy, nttyp, &
> !20
> bonda_idx, anglea_idx, diheda_idx, &
> !23
> gbl_bond_allocsize, gbl_angle_allocsize, &
> !25
> gbl_dihed_allocsize, next_mult_fac, &
> !27
> nub, nubtypes, &
> !29
> nimphi, nimprtyp, &
> !31
> gbl_angle_ub_allocsize, gbl_dihed_imp_allocsize,&
> !33
> cmap_term_count, cmap_type_count, &
> !35
> gbl_cmap_allocsize
> !36
>
> to
>
> integer, public :: natom, ntypes, nbonh, ntheth, nphih, next, nres, &
> !7
> nbona, ntheta, nphia, numbnd, numang, nptra, nphb, &
> !14
> ifbox, ifcap, nspm, numextra, ncopy, nttyp, &
> !20
> bonda_idx, anglea_idx, diheda_idx, &
> !23
> gbl_bond_allocsize, gbl_angle_allocsize, &
> !25
> gbl_dihed_allocsize, next_mult_fac, &
> !27
> nub, nubtypes, &
> !29
> nimphi, nimprtyp, &
> !31
> gbl_angle_ub_allocsize, gbl_dihed_imp_allocsize,&
> !33
> cmap_term_count, cmap_type_count, &
> !35
> gbl_cmap_allocsize
> !36
If you mean in prmtop_dat.fpp, it doesn't seem to work. Sorry.
Ben
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Mar 09 2010 - 13:30:02 PST
