the code without interruption. I doubt anyone had ever run the code for such a
long sample interval. We found out because we missed recording an important
earthquake a week after the race condition was tripped. Murphy's law triumphs
again. :)
Larry Baker
US Geological Survey
650-329-5608
ba...@
Things that read like they should be unsigned look suspicious to me:
nbElems -909934592
count -1819869184
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
> On Nov 1, 2018, at 10:34 PM, Ben Menadue wrote:
>
> Hi,
>
> I haven’t heard back from the user yet,
entify whether it is an instruction fetch (VERY unlikely), an
operand fetch, or a store that caused the trap?
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
> On 30 Aug 2017, at 3:17:05 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
>
> I am testing the 2.1.2rc3 ta
different compilers (part of what Fortran calls a
processor) are used.
Better to find out what discussions took place in the MPI standards committee
before adding extensions to SIZEOF. They may very well have good reasons to
avoid character and logical data, as I concluded.
Larry Baker
US Geological
be able to get past the incompatibility between the internal
formats used by each compiler to store module definitions and declarations for
later USE by another compilation unit. I think your expectations cannot be
fulfilled because of the compilers, not because of OpenMPI.
Larry Baker
US
Gilles,
Before anyone takes my opinion as gospel, I should note that I only checked my
copies of the Fortran 90 Handbook (Adams et al.) and the Fortran 2003 Handbook
(Adams et al.). If more than seven dimensions is permitted by Fortran 2008 or
Fortran 15, I stand corrected.
Larry Baker
US
I have never tried to mix compilers like Dave mentions. In any event, the
Fortran standard specifies no more than seven dimensions are allowed in an
array declaration. I'm puzzled why OpenMPI would generate code that violates
the Fortran standard?
Larry Baker
US Geological Survey
650-329
). Nothing is said at all about
floating-point data types and the correspondence with the integer types. This
is what APIs like OpenMPI have to struggle with in the real world.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 14 Oct 2015, at 3:38 PM, Jeff Squyres (jsquyres) wrote
Gack! Can't type. compiler definition (FF, FC, LD) should have been compiler
definition (CC, FC, LD).
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 27 Feb 2015, at 10:39 AM, Larry Baker wrote:
> On 27 Feb 2015, at 10:14 AM, Jeff Squyres (jsquyres) wrote:
>
>>
convention, will OpenMPI always pass the -m flag on to the wrapper scripts so
the addition of --with-wrapper* is not necessary? It would have to handle the
embedded blank properly, which may be tricky.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
Good grins. Thanks Paul.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 20 Feb 2015, at 11:49 AM, Paul Hargrove wrote:
>
>INTEGER JEFF(3)
>DATA JEFF/4HMR. ,4HFORT,3HRAN/
>
> If you can understand that, you should probably pretend you can't
ermines whether the logical value is true or false.
> Logical variables can also be interpreted as integer data (an extension to
> the Fortran 90 standard). For example, in addition to having logical values
> .TRUE. and .FALSE., LOGICAL*1 data can also have values in the range --128 to
> 127.
&
for "%ld", "%lx", "%lX", "%lf"
> are all currently incorrect.
Not sure if it is applicable, but C99 has an header which
#include's and provides additional capabilities, such as
printf()/scanf() format macros for the types defined in .
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
Or, slightly modified using a defensive coding style:
> return 1 + vsnprintf(dummy, sizeof( dummy ), fmt, ap);
if you like sizeof() [which I prefer]. if you like sizeof:
> return 1 + vsnprintf(dummy, sizeof dummy, fmt, ap);
>
Larry Baker
US Geological Survey
650-329-5608
ba...
On 11 Dec 2014, at 2:12 PM, Paul Hargrove wrote:
> I believe Larry Baker of USGS is also a PGI user (in production, rather than
> just testing as I do).
That is correct.
Although we are running a rather old Rocks cluster kit (CentOS based) which is
so old that we cannot run the late
Allan,
If you can still boot the old embedded system, a lot of times the config
parameters are saved as /proc/config.gz. You can at least them compare the two
configs.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 25 Nov 2014, at 11:11 AM, Allan Wu wrote:
> Thanks P
PGI 14.7 is VERY new -- I just received the announcement on Sunday.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 29 Jul 2014, at 4:25 PM, Paul Hargrove wrote:
> I have license for PGI and installations of 14.1 and 14.4
> I will see what I can do today in terms of t
OpenMPI requires C99 conformance, stdint.h will be there, but you will have
to check for any width (u)int_t's you care about by name. Since these are
typedefs, I am not sure how that might be done in CPP; a configure step might
be required.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
characters i.e., if the
linker/loader does not support that many characters in an external symbol.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 22 Jan 2014, at 8:50 AM, Jeff Squyres (jsquyres) wrote:
> On Jan 21, 2014, at 11:49 PM, Paul Hargrove <phhargr...@lbl.gov&
mer information:
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
> Product: 2183-WS
> PIN: 507549
>
> Problem description:
>
> I am trying to track down the warnings that occur when compiling the UCAR
> NetCDF package with PGI com
-329-5608ba...@usgs.gov
On 17 Jan 2014, at 8:56 AM, Ralph Castain wrote:--- Begin Message ---
Customer information:
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
Product: 2183-WS
PIN: 507549
Problem description:
I am trying to track down the warnings that occur when compiling
the version number of
the compiler. Trouble was, only the first digit was examined, leading to PGI
V10.x, V11.x, V12.x, ..., all being parsed as V1. My recollection is that some
C++ code was affected.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 9 Jan 2014, at 4:35 PM, Paul
Ralph, et al.,
Kathy Yelick is featured in this month's ACM Member News sidebar (p. 17). It
also turns out she will be giving a lecture at SC13.
http://sc13.supercomputing.org/content/sc13-feature-acm-athena-lecturer-katherine-yelick
Check it out.
Larry Baker
US Geological Survey
650-329
separate
development trees for each OpenMPI version/compiler product/compiler version.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 22 Aug 2013, at 6:50 AM, Jeff Squyres (jsquyres) wrote:
> Sadly, probably not. :(. You'll prbably have the same problem with c++,
at least part of the way.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 10 May 2013, at 8:07 AM, Ralph Castain wrote:
> It's doable, if you have patience. You have to take CalTrain from the airport
> to San Jose - see:
>
> http://www.bart.gov/docs/visitorg
ly set up
> something ahead of time.
This option will work best for me. All I need is an e-mail notice of where and
when within 30 minutes or so of the reservation time (depending on the traffic
on 101 :) ).
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
spend any money,
unless I do it on my own (in which case I have to bend over backwards to
obscure my government affiliation -- like no mention of USGS on my registration
or name badge).
Thanks,
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 30 Apr 2013, at 2:58 PM, Jeff
;10.4.2A" | perl -E 'while () { if (
> m/(^|\s)((\d+\.)+\d+([a-zA-Z]\b)?)/ ) { $version = $2 ; print $version, "\n"
> ; last } }'
> 10.4.2A
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 15 Nov 2012, at 8:42 AM, Hjelm, Nathan T wrote:
> C
with-gxx-include-dir=/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
--version". Assuming the RE parser I wrote is satisfactory, it would have to
be adapted to fit in the framework, i.e., it has to be portable.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 14 Nov 2012, at 5:41 PM, Paul Hargrove wrote:
> On Wed, Nov 14, 2012 at 6:26
ex-31)" | sed -n -E -e
> '1s/^.*[^A-Za-z0-9_-]?([0-9]+[.][0-9]+[.][0-9]+)[^A-Za-z0-9_-]?.*$/\1/p'
> 2.5.35
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 14 Nov 2012, at 3:26 PM, Ralph Castain wrote:
> Sorry Nathan - I had to revert this out as it broke builds on Mac
Nice catch!
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 24 Aug 2012, at 4:55 PM, Paul Hargrove wrote:
> OK, I have a vanilla configure+make running on both SPARC/Solaris-10 and
> AMD64/Solaris-11.
> I am using the 12.3 Oracle compilers in both cases to match the
The value of i is exactly as it would be in C for the value of a loop control
variable at loop exit. (As opposed to being undefined, which is what is used
to be.) This dates from Fortran-77.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 11 Jul 2012, at 10:44 AM, Jeff
a patch for ptmalloc2/malloc.c for
OpenMPI 1.4.3 which automatically adjusts the optimization level for
_int_malloc(), which is where the bug occurs.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
-- Start of Patch --
--- opal/mca/memory/ptmalloc2/malloc.c.original 2010
Intel V12.x compiler) and balk.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
t". But, the main text states that there is
no ordering of the subexpression "rank * rcount * rext". When the
compiler chooses to evaluate "rank * rcount" first, the overflow
described by Yuki can result. I think you are correct that the
subexpression will get promoted to (ptrd
e_type &&
OMPI_REAL16_MATCHES_C )
_ACEOF
@@ -60152,7 +60160,7 @@
cat >>confdefs.h <<_ACEOF
-#define OMPI_HAVE_F90_COMPLEX32 $ofc_have_type
+#define OMPI_HAVE_F90_COMPLEX32 ( $ofc_have_type &&
OMPI_REAL16_MATCHES_C )
_ACEOF
Larry Baker
US Geological Survey
6
. When we say that "gcc" is supported, is that
intended to mean the command or the compiler? I would assume it meant
the latter.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 23 Feb 2012, at 4:44 AM, Jeffrey Squyres wrote:
I don't think I want to get specific ab
cc-4.2/bin/*cc*
/Developer/usr/llvm-gcc-4.2/bin/i686-apple-darwin9-llvm-gcc-4.2
/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
/Developer/usr/llvm-gcc-4.2/bin/powerpc-apple-darwin9-llvm-gcc-4.2
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 22 Feb 2012, at 5:55 PM, Paul H. Hargrove
> I am pretty sure a literal "rm -rf" should be fine.
Not necessarily. I'm not at work. But I think either -f or -r might not be
legal on all Unix's (Tru64 Unix? AIX?).
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On Dec 20, 2011, at 5:19 PM, Paul H. H
GS="-g -O3" \
CXX="g++ -m32" \
CXXFLAGS="-g -O3" \
FC="gfortran -m32" \
FCFLAGS="-g -O3" \
F77="gfortran -m32" \
FFLAGS="-g -O3"
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 23 Nov 2011, a
Tom,This is because the code in OpenMPI presumes macros will be expanded in pragmas, but that is not required by the C standard. (See my e-mails below from last year with PGI, TPR 17186.) I fixed OpenMPI 1.4.3 configure in the attached patch. My patch also disables inline assembly for PGI C++,
and the linked thread on the Intel forum for more info about.I couldn't find a trace of this being fixed in the 1.4 series, so I would wait upgrading until this issue gets resolved. Thanks, george.On Oct 17, 2011, at 23:00 , Larry Baker wrote:George,I have not had time to look over the 1.4.3 make
that matches the
version of the product (as opposed to #define __INTEL_COMPILER
and #define __ICC from within the V12.1.0 compiler).
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 19 Oct 2011, at 10:47 AM, Jeff Squyres wrote:
Did this get reported to the Intel compiler
if there is code in OpenMPI that looks at __ICC and
__INTEL_COMPILER, but that could cause problems. (Pass this on
upstream to the libtool people?)
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 17 Oct 2011, at 8:18 PM, George Bosilca wrote:
Larry,
Sorry for not updating
just cruft that can be removed?
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 7 Oct 2011, at 11:08 AM, Larry Baker wrote:
I ran into a problem this past week trying to upgrade our OpenMPI
1.4.3 for the latest Intel 2011 compiler, 2011.6.233.
make check fails with Segmenta
list knows what the purpose of that test
is, whether the Intel 2011 compilers are expected to have this feature
enabled, and whether the code this enables can cause this problem if
the Intel 2011.6.233 compilers do not fully support whatever this test
is intended to discern.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
fixed
problem like --without-rte-support failing.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 16 Aug 2011, at 11:53 AM, Matthew Russell wrote:
Hi Larry,
Thank you for your interest.
I believe your solution is the right one, however I think there's
some other issues
ase_open.o is not in libopen-rte.a for some reason. Or,
the external name that gets defined in odls_base_open.c is not the
same as the external name being referenced in errmgr_base_fns.c.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 16 Aug 2011, at 11:53 AM, Matthew Russell w
the error?
I have PGI and about five other compilers on our cluster. I'll get to
OpenMPI 1.4.3 with all those as soon as I fetch the latest versions
and reinstall my cluster software (Rocks just came out with 5.4.3).
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 16 Aug
-lutil -lm -lpthread
While this may not be what Matthew is encountering, it is definitely
something to keep in your bag or tricks.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 15 Aug 2011, at 5:43 PM, Ralph Castain wrote:
FWIW: I build OMPI on Mac OS-X (Snow Leopard) every da
-search_paths_first to ld when $
(CC) is the linker command in makefile.ux
export LDFLAGS=-Wl,-search_paths_first
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 15 Aug 2011, at 1:01 PM, Matthew Russell wrote:
I hope this problem merits being posted here.
On OS X (Snow Leopard, and Lion
ferent
remote_mtu's):
attr.path_mtu = (openib_btl->device->mtu < endpoint-
>rem_info.rem_mtu) ?
openib_btl->device->mtu : rem_info->rem_mtu;
Can someone verify that the code in ompi/mca/btl/openib/btl_openib/
connect/btl_openib_connect_xoob.c is correct?
Larry
>mtu < endpoint-
>rem_info.rem_mtu) ?
openib_btl->device->mtu : rem_info->rem_mtu;
The test on the right hand side of the conditional is endpoint-
>rem_info.rem_mtu, while the "false" expression is rem_info-
>rem_mtu. I suspect one of them is no
actually
disable them, despite saying it did. I like defensive code. The
COMPLEX*32 datatype protection needs to be applied to the REAL*16
datatype as well in ompi/datatype/dt_module.c.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 5 May 2011, at 7:15 AM, Jeff Squyres wr
ings go away? Maybe a macro you use in the library?
While looking at the source of the warnings, I saw that the code in
test/class/ompi_rb_tree.c, lines 361-368 are duplicated in lines
369-376 (quoted, below). Is this intentional?
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs
1.4.3, I should have time to test 1.4.4.
Will there be another 1.4.4 release candidate? Do I have to hurry to
give you my feedback?
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 19 May 2011, at 6:58 PM, Jeff Squyres wrote:
With all the outputs from Paul and Sam, I think
performance from
optimizations, unless the processes are all running on the same
machine. I will ask engineering
how messages are passed when all the processes are running on the
same hardware.
I am running on a 64-bit machine; I used -fast.
Larry Baker
US Geological Survey
650-329-5608
ba
symbols.
Default:
"plpa_"
--with-valgrind(=DIR) Directory where the valgrind software is
installed
--with-timer=TYPE Build high resolution timer component TYPE
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 5 May 2011, at 7:1
and
libraries
to replace the text in 1.4.x
--with-tm(=DIR) Directory where the tm software is installed
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 5 May 2011, at 7:15 AM, Jeff Squyres wrote:
Fixed the ROMIO attribute problem properly this time
The PGI compilers have a -fast and a -fastsse option. Does OpenMPI
make effective/safe use of SSE instructions (block moves maybe?)? On
their web site, PGI uses -fast in their examples for OpenMPI rather
than -fastsse. I don't know why.
Larry Baker
US Geological Survey
650-329-5608
ba
, Jeff Squyres wrote:Hmm. This sounds right, but I'm a little curious as to why this never came up before. What was the specific problem that caused you to add this patch?On May 17, 2011, at 9:41 PM, Larry Baker wrote:This bug applies to OpenMPI 1.4.x and 1.5.x.Inline assembly does not work
en-mpi.org/community/lists/users/2009/11/11277.php
.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 18 May 2011, at 5:50 AM, Jeff Squyres wrote:
(adding libtool-patc...@gnu.org)
Is this guaranteed to work for all versions of the PGI compiler?
I.e., does "pgCC -V" alw
t_ipa8_conftest.oo \
conftest$ac_exeext conftest.$ac_ext
fi
+fi
{ $as_echo "$as_me:$LINENO: result: $asm_result" >&5
$as_echo "$asm_result" >&6; }
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 5 May 2011, at 7:15 AM, Jeff
(prelink_cmds, $1)='tpldir=Template.dir~
rm -rf $tpldir~
$CC --prelink_objects --instantiation_dir $tpldir $objs $libobjs
$compile_deplibs~
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 5 May 2011, at 7:15 AM, Jeff Squyres wrote:
Fixed the ROMIO attribute
't have to know what parse_dots() returns). I
suppose a case could also be made that Tim's code is more
maintainable, given the discovery already of a misplaced (though
benign) break and the possibility of a typo in all those calls to
parse_dots().
Just my $.02
Larry Baker
US Geological Su
;-g -fast"
# Make the library
make >make.log 2>&1
# Validate the library
make check >check.log 2>&1
Then, I used the following commands to install it:
# Install OpenMPI 1.4.2
cd openmpi-1.4.2
make install >install.log 2>&1
Maybe the first thing you could try is
${dim}/' \
openmpi-1.4.2/ompi/mpi/f90/scripts/mpi_sizeof.f90.sh.original \
>openmpi-1.4.2/ompi/mpi/f90/scripts/mpi_sizeof.f90.sh
chmod +x openmpi-1.4.2/ompi/mpi/f90/scripts/mpi_sizeof.f90.sh
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On Sep 1, 2010, at 5:09 PM, Larry
a fix for this in the next few days, unless the author
wants to. Is that okay?
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On Aug 17, 2010, at 2:18 PM, Jeff Squyres wrote:
We still have one known possible regression:
https://svn.open-mpi.org/trac/ompi/ticket/2530
-10.x PGI compilers.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
Development environment:
[baker@hydra ~]$ cat /etc/redhat-release
CentOS release 4.5 (Final)
[baker@hydra ~]$ uname -a
Linux hydra.wr.usgs.gov 2.6.9-55.0.2.ELsmp #1 SMP Tue Jun 26
14:14:47 EDT 2007 x86_64
about
10.1-10.6 not working is possibly due to the (previously reported)
mistaken identification of the 10.x compilers by configure/libtool,
which I fixed.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
Begin forwarded message:
From: Larry Baker <ba...@usgs.gov>
My head hurts from working on this! I just realized is for
OpenMP, not OpenMPI. So, of course the PGI is used. I still
don't know why otfprofile is failing, but at least that explains why
OpenMPI-1.5rc5 has no .
Sorry for the noise.
Larry Baker
US Geological Survey
650-329-5608
ba
t;.
I don't know how to fix this. Where is otfprofile.cpp expecting to
get ? Why isn't it there? I'm beginning to think this contrib/
vt stuff should not be enabled by default. I don't know that it is
needed in general.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On A
The same problem (LIBS = is missing -lpthread) occurs in orte/tools/
{orte-clean,orte-iof,orte-ps,orted,orterun,orte-top}/Makefile.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
Begin forwarded message:
From: Larry Baker <ba...@usgs.gov>
Date: August 30, 2010 4:48:01
OC_DEBUG and NDEBUG.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On Aug 23, 2010, at 5:29 PM, Larry Baker wrote:
The PGI C compiler complains (issues a warning) for the redefinition
of the assert macro in opal/mca/memory/ptmalloc2/malloc.c:
Making all in mca/memory/ptmalloc
> $(AM_V_CCLD)$(LINK) $(opal_wrapper_OBJECTS) $(opal_wrapper_LDADD)
$(LIBS)
I don't know anything about automake, so I don't know what code to
look at that changed between 1.4.2 and 1.5rc5 that defines the *LIBS
Makefile variables.
Larry Baker
US Geological Survey
650-329-5608
b
rappers/Makefile
(configure/automake?) from 1.4.2 to 1.5rc5 are not supplying the
pthreads library correctly to the link step.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On Aug 17, 2010, at 2:18 PM, Jeff Squyres wrote:
We still have one known possible regression:
https://svn.o
possible, attach it to your
problem report.
make[6]: *** [vtfilter-vt_tracefilter.o] Error 1
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
form of #pragma ident used by
OpenMPI:
ompi_ident="string_not_coincidentally_inserted_by_the_compiler"
cat > conftest.c <When this code is used instead (twice), the PGI C compiler fails the
configure test for #prgma ident support, as it should.
Larry Baker
US Geological Sur
[baker@hydra openmpi-1.5rc5]$ find . -name libtool.m4 -exec grep
'1-5' {} ';' -print
*pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
./config/libtool.m4
*pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
./opal/libltdl/m4/libtool.m4
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On A
Call MPI_CART_SHIFT( mpi_comm_grid, direction, amount,
-^
With Fortran 90 "Include 'mpif.h'", no errors.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
$ /usr/local/openmpi/bin/ompi_info
Package: Open MPI r...@savaii.wr.usgs.gov Distribution
81 matches
Mail list logo
