Hi Ben,
Looking at the code this all looks perfectly legal to me. I think it is just
the Gfortran compiler being overzealous when you have warn all turned on.
The two arrays in question are in the qmmm_module and are allocated as
4xnatom (real) and 3xnatom (int). These arrays are designed to provide
pre-allocated scratch space that any routine can use.
They are pointers in the qmmm_scratch structure to 1D arrays. When the code
calls qm2_calc_mm_pot it passes it the first element of each array except
for the natom+1 argument which provides an offset of natom.
These are simply array offsets, they are not intended to be scalars. Note
Fortran is such that one can do the following:
allocate(foo(3xnatom),stat=ier)
call foobar(foo(natom+1))
subroutine foobar(array_here)
integer :: array_here(2xnatom)
array_here(1:2xnatom) = 0.0d0
This would have the effect of zeroing array_here from natom+1 to 2xnatom.
This is legal and one of the nice features of Fortran which in c or c++
would need lots of pointers moved around.
In the calc_mm_pot routine in question we have:
subroutine qmgb_calc_mm_pot(natom,gb_mmpot,qm_atom_mask,scaled_mm_charges, &
real_scratch1,real_scratch2, int_scratch1, &
qm_coords,mm_coords,born_radii,one_born_radii,
iqmatoms)
_REAL_, intent(out) :: real_scratch1(natom), real_scratch2(natom)
integer, intent(out) :: int_scratch1(natom)
So inside this routine they are arrays of size natom. Here real_scratch1 is
just qm_real_scratch from 1 to natom and real_scratch2 is qm_real_scratch
from natom+1 to 2xnatom.
This should be perfectly legal and I am certain similar constructs are used
elsewhere in sander. This code looks perfectly legal to me but perhaps one
should check the standard to be sure. And see if there is a more 'correct'
way of accomplishing what is done here. Essentially providing an alias to
the middle of a large array as another array inside a subroutine.
All the best
Ross
> -----Original Message-----
> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
> bounces.ambermd.org] On Behalf Of Ben Roberts
> Sent: Wednesday, February 10, 2010 12:27 PM
> To: amber-developers.ambermd.org
> Subject: [AMBER-Developers] Scalar vs. array mix-up in QMGB
>
> Hi all,
>
> I've been going through building Amber with warnings turned on in the
> compilation. This has drawn my attention to a number of aspects of the
> code which are usually tolerated but when warnings are enabled die with
> fatal errors.
>
> One of those is the following:
>
> _qm2_energy.SQM.f(116): error #7836: If the actual argument is scalar,
> the corresponding dummy argument shall be scalar unless the actual
> argument is an element of an array that is not an assumed-shape or
> pointer array, or a substring of such an element. [REAL_SCRATCH1]
> call qmgb_calc_mm_pot(natom, qm_gb%gb_mmpot,
> qmmm_struct%atom_mask, &
> -----------^
> _qm2_energy.SQM.f(116): error #7836: If the actual argument is scalar,
> the corre
> sponding dummy argument shall be scalar unless the actual argument is
> an
> element
> of an array that is not an assumed-shape or pointer array, or a
> substring of su
> ch an element. [REAL_SCRATCH2]
> call qmgb_calc_mm_pot(natom, qm_gb%gb_mmpot,
> qmmm_struct%atom_mask, &
> -----------^
> _qm2_energy.SQM.f(116): error #7836: If the actual argument is scalar,
> the corresponding dummy argument shall be scalar unless the actual
> argument is an element of an array that is not an assumed-shape or
> pointer array, or a substring of such an element. [INT_SCRATCH1]
> call qmgb_calc_mm_pot(natom, qm_gb%gb_mmpot,
> qmmm_struct%atom_mask, &
> -----------^
>
> Now, I've had a look, and the variables REAL_SCRATCH1, REAL_SCRATCH2
> and
> INT_SCRATCH1 are passed in from qm2_energy.f (line 143ff. unless
> preprocessed) as qmmm_scratch%qm_real_scratch(1),
> qmmm_scratch%qm_real_scratch(natom+1) and
> qmmm_scratch%qm_int_scratch(1). I suppose these variables are scalars,
> while in qmgb_calc_mm_pot (line 114ff. in qm_gb.f), the dummy variables
> are declared as arrays of length NATOM.
>
> What's the correct fix here - is it to change the nature of the
> arguments passed, or to rewrite the parameter declarations as scalar
> values?
>
> Cheers,
> Ben
>
> _______________________________________________
> 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 Feb 11 2010 - 10:00:02 PST
