AMBER Archive (2008)

Subject: Re: AMBER: Inconsistent types (INTEGER(4)/REAL(8)) - Is it serious ?

From: Robert Duke (rduke_at_email.unc.edu)
Date: Wed Jul 02 2008 - 19:00:07 CDT

Hi David,
You are probably right, then. Since I don't officially support either
OpenMPI or g95, I could see potential mix/match grief if there are some
other issues, but where the fortran compiler is complaining about void *
stuff, well that is just nonsense. For pmemd, I don't support module
interfaces to the mpi stuff and just carefully check any calls I code - I
can get away with that since I am the only guy in the code, and it
simplifies life where the module interfaces may not be readily available.
So I would say run it, and if it blows up, we look for mismatched default
types. Arturo, if you have trouble with running pmemd, then send me the
compiler listing.
Regards - Bob

----- Original Message -----
From: "David A. Case" <case_at_scripps.edu>
To: <amber_at_scripps.edu>
Sent: Wednesday, July 02, 2008 6:58 PM
Subject: Re: AMBER: Inconsistent types (INTEGER(4)/REAL(8)) - Is it serious
?

> On Wed, Jul 02, 2008, David A. Case wrote:
>
>> >
>> > ============================================================
>> > In file nmr_calls.f90:285
>> >
>> > call mpi_bcast(nmr_iwork, intreq, mpi_integer, &
>> > 1
>> > In file nmr_calls.f90:273
>> >
>> > call mpi_bcast(rwell, nmr_dat_dbl_cnt, mpi_double_precision, 0, &
>> > 2
>> > Warning (155): Inconsistent types (INTEGER(4)/REAL(8)) in actual
>> > argument lists at (1) and (2)
>> >
>
> Here's my reasons I said not to worry: the mpi_bcast() function is the
> same
> call, no matter whether integers or reals are being broadcast. The third
> argument (mpi_integer or mpi_double_precision above) gives the
> size and type of the data being transferred.
>
> In the C language binding, the first argument of mpi_bcast is void*, which
> essentially says "don't worry about what type of data this is."
>
> There is no simple equivalent in Fortran. If you want to broadcast both
> reals and integers in the same subroutine, you have to do it as written
> above,
> and a picky compiler will issue warnings (only!) like the ones you report.
>
> In my view, this has nothing to do with the fact that this is in NMR, nor
> is
> there any real way to avoid it. G95 puts out warnings like this all over
> the
> place. Until shown otherwise, I will stand by my original advice to
> ignore
> this sort of warning.
>
> ...dac
>
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber_at_scripps.edu
> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
> to majordomo_at_scripps.edu
>

-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo_at_scripps.edu