- devel - mailman3.cels.anl.gov

Re: [mpich-devel] ifort: error #10236: File not found: 'src/binding/fortran/use_mpi_f08/mpi_f08_types.f90'
by Kenneth Raffenetti 09 Sep '15

09 Sep '15

That's what I suspected. I have access to Intel 2016, but need our sysadmins to update the license server to activate it. In the meantime, I can try to fake an env that can build F08 and find the underlying problem. It looks like you were doing a vpath build...does an in-tree build succeed? Ken On 09/09/2015 05:43 PM, Jeff Hammond wrote: > You are right. GCC 5.2 contains no references to F08, presumably > because configure determined that F08 was not supported. I assume ifort > 16 tested positive for F08. > > I think you can download Intel 16 but if you have any trouble, let me > know offline and I'll help figure it out. > > Jeff > > On Wed, Sep 9, 2015 at 3:40 PM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > Did the GCC 5.2 build actually build the F08 module? I suspect it > might have been disabled at configure time. That is, is there an > mpi_f08.mod file in the installed include dir? > > > On 09/09/2015 12:58 PM, Jeff Hammond wrote: > > I cannot configure MPICH due to any F08-related issue. I ran > autogen.sh > twice just to be darn sure I wasn't making that mistake again. > > This is with the latest MPICH git master. I am using Intel > Fortran 16 > on Mac Yosemite. The GCC 5.2 build was fine so this might be > related to > ifort, but it's not obvious why. > > Thanks, > > Jeff > > > This is how I attempted to configure: > > jrhammon-mac01:build jrhammon$ head config.log > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by MPICH configure 3.2rc1, which was > generated by GNU Autoconf 2.69. Invocation command line was > > $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-cxx > --enable-fortran --enable-threads=runtime --enable-g=dbg > --with-pm=hydra > --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath > --enable-static --enable-shared > > Here is the error: > > Configuration completed. > MOD > src/binding/fortran/use_mpi_f08/mpi_c_interface_types.stamp > MOD src/binding/fortran/use_mpi_f08/mpi_f08_types.stamp > ifort: error #10236: File not found: > 'src/binding/fortran/use_mpi_f08/mpi_f08_types.f90' > ifort: command line error: no files specified; for help type > "ifort -help" > make: *** [src/binding/fortran/use_mpi_f08/mpi_f08_types.stamp] > Error 1 > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > http://jeffhammond.github.io/ > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] ifort: error #10236: File not found: 'src/binding/fortran/use_mpi_f08/mpi_f08_types.f90'
by Jeff Hammond 09 Sep '15

09 Sep '15

You are right. GCC 5.2 contains no references to F08, presumably because configure determined that F08 was not supported. I assume ifort 16 tested positive for F08. I think you can download Intel 16 but if you have any trouble, let me know offline and I'll help figure it out. Jeff On Wed, Sep 9, 2015 at 3:40 PM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > Did the GCC 5.2 build actually build the F08 module? I suspect it might > have been disabled at configure time. That is, is there an mpi_f08.mod file > in the installed include dir? > > > On 09/09/2015 12:58 PM, Jeff Hammond wrote: > >> I cannot configure MPICH due to any F08-related issue. I ran autogen.sh >> twice just to be darn sure I wasn't making that mistake again. >> >> This is with the latest MPICH git master. I am using Intel Fortran 16 >> on Mac Yosemite. The GCC 5.2 build was fine so this might be related to >> ifort, but it's not obvious why. >> >> Thanks, >> >> Jeff >> >> >> This is how I attempted to configure: >> >> jrhammon-mac01:build jrhammon$ head config.log >> This file contains any messages produced by compilers while >> running configure, to aid debugging if configure makes a mistake. >> >> It was created by MPICH configure 3.2rc1, which was >> generated by GNU Autoconf 2.69. Invocation command line was >> >> $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-cxx >> --enable-fortran --enable-threads=runtime --enable-g=dbg --with-pm=hydra >> --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath >> --enable-static --enable-shared >> >> Here is the error: >> >> Configuration completed. >> MOD src/binding/fortran/use_mpi_f08/mpi_c_interface_types.stamp >> MOD src/binding/fortran/use_mpi_f08/mpi_f08_types.stamp >> ifort: error #10236: File not found: >> 'src/binding/fortran/use_mpi_f08/mpi_f08_types.f90' >> ifort: command line error: no files specified; for help type "ifort -help" >> make: *** [src/binding/fortran/use_mpi_f08/mpi_f08_types.stamp] Error 1 >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] ifort: error #10236: File not found: 'src/binding/fortran/use_mpi_f08/mpi_f08_types.f90'
by Kenneth Raffenetti 09 Sep '15

09 Sep '15

Did the GCC 5.2 build actually build the F08 module? I suspect it might have been disabled at configure time. That is, is there an mpi_f08.mod file in the installed include dir? On 09/09/2015 12:58 PM, Jeff Hammond wrote: > I cannot configure MPICH due to any F08-related issue. I ran autogen.sh > twice just to be darn sure I wasn't making that mistake again. > > This is with the latest MPICH git master. I am using Intel Fortran 16 > on Mac Yosemite. The GCC 5.2 build was fine so this might be related to > ifort, but it's not obvious why. > > Thanks, > > Jeff > > > This is how I attempted to configure: > > jrhammon-mac01:build jrhammon$ head config.log > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by MPICH configure 3.2rc1, which was > generated by GNU Autoconf 2.69. Invocation command line was > > $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-cxx > --enable-fortran --enable-threads=runtime --enable-g=dbg --with-pm=hydra > --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath > --enable-static --enable-shared > > Here is the error: > > Configuration completed. > MOD src/binding/fortran/use_mpi_f08/mpi_c_interface_types.stamp > MOD src/binding/fortran/use_mpi_f08/mpi_f08_types.stamp > ifort: error #10236: File not found: > 'src/binding/fortran/use_mpi_f08/mpi_f08_types.f90' > ifort: command line error: no files specified; for help type "ifort -help" > make: *** [src/binding/fortran/use_mpi_f08/mpi_f08_types.stamp] Error 1 > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

ifort: error #10236: File not found: 'src/binding/fortran/use_mpi_f08/mpi_f08_types.f90'
by Jeff Hammond 09 Sep '15

09 Sep '15

I cannot configure MPICH due to any F08-related issue. I ran autogen.sh twice just to be darn sure I wasn't making that mistake again. This is with the latest MPICH git master. I am using Intel Fortran 16 on Mac Yosemite. The GCC 5.2 build was fine so this might be related to ifort, but it's not obvious why. Thanks, Jeff This is how I attempted to configure: jrhammon-mac01:build jrhammon$ head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by MPICH configure 3.2rc1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-cxx --enable-fortran --enable-threads=runtime --enable-g=dbg --with-pm=hydra --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath --enable-static --enable-shared Here is the error: Configuration completed. MOD src/binding/fortran/use_mpi_f08/mpi_c_interface_types.stamp MOD src/binding/fortran/use_mpi_f08/mpi_f08_types.stamp ifort: error #10236: File not found: 'src/binding/fortran/use_mpi_f08/mpi_f08_types.f90' ifort: command line error: no files specified; for help type "ifort -help" make: *** [src/binding/fortran/use_mpi_f08/mpi_f08_types.stamp] Error 1 -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Argonne Spam Quarantine Notification
by Argonne Anti Spam Quarantine 08 Sep '15

08 Sep '15

++ Note: This message has been sent by a notification only system. Please do not reply ++ IronPort Spam Quarantine Notification If a spam message was missed, or if a message was incorrectly flagged as spam, you can add the sender to a personal safelist or blocklist via the quarantine. Senders on the safelist will not be flagged as spam, and senders on the blocklist will be automatically quarantined. For more information, visit: https://wiki.inside.anl.gov/inside/Ironport_Anti-Spam_Appliances/Documentat… The message(s) below have been quarantined by the Argonne National Laboratory spam filtering system. There are 1 new messages in your Email Quarantine since you received your last Spam Quarantine Notification. If the messages below are spam, you do not need to take any action. Messages will be automatically deleted from the quarantine after 28 day(s). If any of the messages below are not spam, click the 'Release' link to have them sent to your Inbox. Messages that have been correctly flagged as spam do not need to be reported. ----------- New Quarantine Messages --------------- Message 1 From: "Secure Your Home" <secure_your_home(a)octsy.com> Subject: *****SPAM*****Get ADT Protection this Summer for $0 Date: 07 Sep 2015 Release: http://mailgateway.anl.gov:8080/Message?action=Release&mid=92926980&h=493f3… --------------------------------------------------- To manage your quarantine please visit the URL below: http://mailgateway.anl.gov:8080/Search?h=2ffb2bd0571f729efb89bf11a9fc382c&e… If you have any questions regarding the Laboratory spam filtering product, please contact the CIS helpdesk at help(a)anl.gov or x-9999 option 2.

1 0

Argonne Spam Quarantine Notification
by Argonne Anti Spam Quarantine 07 Sep '15

07 Sep '15

++ Note: This message has been sent by a notification only system. Please do not reply ++ IronPort Spam Quarantine Notification If a spam message was missed, or if a message was incorrectly flagged as spam, you can add the sender to a personal safelist or blocklist via the quarantine. Senders on the safelist will not be flagged as spam, and senders on the blocklist will be automatically quarantined. For more information, visit: https://wiki.inside.anl.gov/inside/Ironport_Anti-Spam_Appliances/Documentat… The message(s) below have been quarantined by the Argonne National Laboratory spam filtering system. There are 1 new messages in your Email Quarantine since you received your last Spam Quarantine Notification. If the messages below are spam, you do not need to take any action. Messages will be automatically deleted from the quarantine after 28 day(s). If any of the messages below are not spam, click the 'Release' link to have them sent to your Inbox. Messages that have been correctly flagged as spam do not need to be reported. ----------- New Quarantine Messages --------------- Message 1 From: "TV-Internet-and-Phone-Packages" <Kiara(a)sherli.uno> Subject: *****SPAM*****Shop and save on TV, internet and phone bundles Date: 06 Sep 2015 Release: http://mailgateway.anl.gov:8080/Message?action=Release&mid=92864367&h=7d2c6… --------------------------------------------------- To manage your quarantine please visit the URL below: http://mailgateway.anl.gov:8080/Search?h=2ffb2bd0571f729efb89bf11a9fc382c&e… If you have any questions regarding the Laboratory spam filtering product, please contact the CIS helpdesk at help(a)anl.gov or x-9999 option 2.

1 0

Re: [mpich-devel] [PATCH] ofi: need to specify ordering for FI_EP_RDM
by Kenneth Raffenetti 04 Sep '15

04 Sep '15

Pushed to master. http://git.mpich.org/mpich.git/commitdiff/de6df61e8ceb2bbfc9bda82a66c6531c1… Thanks again! On 09/04/2015 02:48 PM, Kenneth Raffenetti wrote: > No worries. I can take it from here. Thanks! > > On 09/04/2015 02:37 PM, Jeff Squyres (jsquyres) wrote: >> Well, 1 out of 2 isn't bad... sorry; out of force of habit, I did "git >> format-patch -s ...". :-) >> >> >>> On Sep 4, 2015, at 3:34 PM, Jeff Squyres (jsquyres) >>> <jsquyres(a)cisco.com> wrote: >>> >>> Per >>> https://github.com/ofiwg/libfabric/issues/1217#issuecomment-131264316, >>> you really need to specify FI_ORDER_SAS for both transmit and receive >>> if you want to guarantee ordering on FI_EP_RDM endpoints (and you do; >>> the MPI-style tagging interface doesn't make much sense unless the >>> underlying fabric provider guarnatees ordering). >>> >>> Signed-off-by: Jeff Squyres <jsquyres(a)cisco.com> >>> --- >>> src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c >>> b/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c >>> index 5de47b7..7c445ac 100644 >>> --- a/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c >>> +++ b/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c >>> @@ -81,6 +81,8 @@ int MPID_nem_ofi_init(MPIDI_PG_t * pg_p, int >>> pg_rank, char **bc_val_p, int *val_ >>> hints->mode = FI_CONTEXT; >>> hints->ep_attr->type = FI_EP_RDM; /* Reliable >>> datagram */ >>> hints->caps = FI_TAGGED; /* Tag matching >>> interface */ >>> + hints->tx_attr->msg_order = FI_ORDER_SAS; >>> + hints->rx_attr->msg_order = FI_ORDER_SAS; >>> >>> hints->ep_attr->mem_tag_format = MEM_TAG_FORMAT; >>> MPIU_Assert(pg_p->size < ((1 << MPID_RANK_BITS) - 1)); >>> -- >>> 2.4.3 >>> >> >> > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] [PATCH] ofi: need to specify ordering for FI_EP_RDM
by Kenneth Raffenetti 04 Sep '15

04 Sep '15

No worries. I can take it from here. Thanks! On 09/04/2015 02:37 PM, Jeff Squyres (jsquyres) wrote: > Well, 1 out of 2 isn't bad... sorry; out of force of habit, I did "git format-patch -s ...". :-) > > >> On Sep 4, 2015, at 3:34 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >> Per https://github.com/ofiwg/libfabric/issues/1217#issuecomment-131264316, >> you really need to specify FI_ORDER_SAS for both transmit and receive >> if you want to guarantee ordering on FI_EP_RDM endpoints (and you do; >> the MPI-style tagging interface doesn't make much sense unless the >> underlying fabric provider guarnatees ordering). >> >> Signed-off-by: Jeff Squyres <jsquyres(a)cisco.com> >> --- >> src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c b/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c >> index 5de47b7..7c445ac 100644 >> --- a/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c >> +++ b/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c >> @@ -81,6 +81,8 @@ int MPID_nem_ofi_init(MPIDI_PG_t * pg_p, int pg_rank, char **bc_val_p, int *val_ >> hints->mode = FI_CONTEXT; >> hints->ep_attr->type = FI_EP_RDM; /* Reliable datagram */ >> hints->caps = FI_TAGGED; /* Tag matching interface */ >> + hints->tx_attr->msg_order = FI_ORDER_SAS; >> + hints->rx_attr->msg_order = FI_ORDER_SAS; >> >> hints->ep_attr->mem_tag_format = MEM_TAG_FORMAT; >> MPIU_Assert(pg_p->size < ((1 << MPID_RANK_BITS) - 1)); >> -- >> 2.4.3 >> > >

1 0

Re: [mpich-devel] [PATCH] ofi: need to specify ordering for FI_EP_RDM
by Jeff Squyres (jsquyres) 04 Sep '15

04 Sep '15

Well, 1 out of 2 isn't bad... sorry; out of force of habit, I did "git format-patch -s ...". :-) > On Sep 4, 2015, at 3:34 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > Per https://github.com/ofiwg/libfabric/issues/1217#issuecomment-131264316, > you really need to specify FI_ORDER_SAS for both transmit and receive > if you want to guarantee ordering on FI_EP_RDM endpoints (and you do; > the MPI-style tagging interface doesn't make much sense unless the > underlying fabric provider guarnatees ordering). > > Signed-off-by: Jeff Squyres <jsquyres(a)cisco.com> > --- > src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c b/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c > index 5de47b7..7c445ac 100644 > --- a/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c > +++ b/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c > @@ -81,6 +81,8 @@ int MPID_nem_ofi_init(MPIDI_PG_t * pg_p, int pg_rank, char **bc_val_p, int *val_ > hints->mode = FI_CONTEXT; > hints->ep_attr->type = FI_EP_RDM; /* Reliable datagram */ > hints->caps = FI_TAGGED; /* Tag matching interface */ > + hints->tx_attr->msg_order = FI_ORDER_SAS; > + hints->rx_attr->msg_order = FI_ORDER_SAS; > > hints->ep_attr->mem_tag_format = MEM_TAG_FORMAT; > MPIU_Assert(pg_p->size < ((1 << MPID_RANK_BITS) - 1)); > -- > 2.4.3 > -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

[PATCH] ofi: need to specify ordering for FI_EP_RDM
by Jeff Squyres 04 Sep '15

04 Sep '15

Per https://github.com/ofiwg/libfabric/issues/1217#issuecomment-131264316, you really need to specify FI_ORDER_SAS for both transmit and receive if you want to guarantee ordering on FI_EP_RDM endpoints (and you do; the MPI-style tagging interface doesn't make much sense unless the underlying fabric provider guarnatees ordering). Signed-off-by: Jeff Squyres <jsquyres(a)cisco.com> --- src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c b/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c index 5de47b7..7c445ac 100644 --- a/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c +++ b/src/mpid/ch3/channels/nemesis/netmod/ofi/ofi_init.c @@ -81,6 +81,8 @@ int MPID_nem_ofi_init(MPIDI_PG_t * pg_p, int pg_rank, char **bc_val_p, int *val_ hints->mode = FI_CONTEXT; hints->ep_attr->type = FI_EP_RDM; /* Reliable datagram */ hints->caps = FI_TAGGED; /* Tag matching interface */ + hints->tx_attr->msg_order = FI_ORDER_SAS; + hints->rx_attr->msg_order = FI_ORDER_SAS; hints->ep_attr->mem_tag_format = MEM_TAG_FORMAT; MPIU_Assert(pg_p->size < ((1 << MPID_RANK_BITS) - 1)); -- 2.4.3

1 0