Thanks so much for catching this. I completely forgot to test this on non gnu architectures. I will make the fix today __
-Charlie
On 1/25/19, 3:58 AM, "Motoshi Kamiya" <mkamiya.ims.ac.jp> wrote:
Dear all,
I met the following error during the compilation of amber18+update1-10
with ifort of Intel Parallel Studio XE 2017 Update4.
(ifort version 17.0.4)
The failed part seems to be introduced in the recent update, update.10.
=========== build log (extracted) ===============
ifort -DBINTRAJ -DEMIL -DPUBFFT -ip -O3 -no-prec-div -xHost -DCUDA
-DGTI -I/home/users/qf7/amber18/include -c mcres.F90
mcres.F90(1120): error #6415: This name cannot be assigned this data
type because it conflicts with prior uses of the name. [ATM_CNT]
integer, intent(in) :: atm_cnt
------------------------------------------------^
...
compilation aborted for mcres.F90 (code 1)
make[4]: *** [mcres.o] Error 1
=========== build log =================
The compilation process is:
$ ./update_amber --update
$ ./configure --no-updates -cuda intel
$ make -j12 install
(The same error also occurs for the build without cuda.)
But fortunately, this problem seems to be solved by applying
the following simple patch.
This just changes the order of variable declaration in
"buildCoarseGrid" subroutine; move "atm_cnt" declaration to the top.
# diff -uNr mcres.F90.org mcres.F90
--- mcres.F90.org 2019-01-25 15:30:45.000000000 +0900
+++ mcres.F90 2019-01-25 16:21:56.000000000 +0900
.. -1115,9 +1115,9 ..
implicit none
+ integer, intent(in) :: atm_cnt
double precision, intent(in) :: crd(3, atm_cnt)
double precision, intent(in) :: mxX,mxY,mxZ, coarseGSP
- integer, intent(in) :: atm_cnt
integer, intent(inout) :: coarseGrid(:,:,:,:)
integer, intent(in) ::
maxCoarseXVxl,maxCoarseYVxl,maxCoarseZVxl
It seems intel compiler do not allow the original way of declaration.
The short sample code at the bottom of this message couldn't be
compiled with any version of ifort I tested (15.0.1, 17.0.4,
17.0.8, 18.0.2, and 18.0.5).
I suppose all the versions of ifort will suffer from the error.
On the other hand, gfortran does not mind the declaration order.
Could you fix the code?
I'm not sure whether this is a bug of the pmemd code, though.
Best regards,
--
Motoshi Kamiya
Research Center for Computational Science,
National Institutes of Natural Sciences
!!!short sample code for confirmation(ifort -c)
subroutine sub(atm_cnt,d)
implicit none
double precision, intent(in) :: d(3,atm_cnt)
integer, intent(in) :: atm_cnt
return
end subroutine sub
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator.
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jan 25 2019 - 07:30:02 PST
