It's my fault - as release manager, I should have spotted that component
sneaking into the release branch back in the 1.7 series, but I missed it. I
have deleted it now as it was never intended to be released.
Sorry for the confusion.
Ralph
On May 15, 2014, at 8:33 PM, Hadi Montakhabi wrote:
Ralph is right.
I used 1.8, and after digging into it, I noticed it doesn't even compile
the pmi component. When I tried to configure without orte, I could see the
errors while compiling.
It looks like it is well broken!
Peace,
Hadi
On May 15, 2014 7:28 PM, "Ralph Castain" wrote:
> Josh - he's t
you might try the nightly 1.8.2 build - there were some additional patches to
fix the darned tkr support. I'm afraid getting all the various compilers to
work correctly with it has been a major pain.
On May 15, 2014, at 5:01 PM, W Spector wrote:
> Hi Jeff and the list,
>
> A year ago, we had
Josh - he's talking about the PMI component in ompi/mca/rte. It generally
doesn't work.
On May 15, 2014, at 5:15 PM, Joshua Ladd wrote:
> Hadi,
>
> Is your job launching and executing normally? During the launch, frameworks
> are initialized by opening all components, selecting the desired
Hadi,
Is your job launching and executing normally? During the launch, frameworks
are initialized by opening all components, selecting the desired one, and
closing the others. I think you're just seeing components being opened,
queried, and ultimately closed. The important thing is knowing if PMI
Hi Jeff and the list,
A year ago, we had the discussion appended below. I just downloaded
v1.8.1 and the F90 module is still very broken. And once again I am
having to modify my local version. (+1 for open source!) Will it be
fixed in v1.8.2?
Configure is using the "use-mpi-tkr" version
Em 15-05-2014 20:48, Ralph Castain escreveu:
Nobody is disagreeing that one could find a way to make CMake work - all we are
saying is that (a) CMake has issues too, just like autotools, and (b) we have
yet to see a compelling reason to undertake the transition...which would have
to be a *very
Nobody is disagreeing that one could find a way to make CMake work - all we are
saying is that (a) CMake has issues too, just like autotools, and (b) we have
yet to see a compelling reason to undertake the transition...which would have
to be a *very* compelling one.
On May 15, 2014, at 4:45 PM
Em 15-05-2014 20:15, Maxime Boissonneault escreveu:
Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :
On May 15, 2014, at 6:14 PM, Fabricio Cannini wrote:
Alright, but now I'm curious as to why you decided against it.
Could please elaborate on it a bit ?
OMPI has a long, deep history wi
On May 15, 2014, at 4:15 PM, Maxime Boissonneault
wrote:
> Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :
>> On May 15, 2014, at 6:14 PM, Fabricio Cannini wrote:
>>
>>> Alright, but now I'm curious as to why you decided against it.
>>> Could please elaborate on it a bit ?
>> OMPI has
Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :
On May 15, 2014, at 6:14 PM, Fabricio Cannini wrote:
Alright, but now I'm curious as to why you decided against it.
Could please elaborate on it a bit ?
OMPI has a long, deep history with the GNU Autotools. It's a very long,
complicated
On May 15, 2014, at 6:14 PM, Fabricio Cannini wrote:
> Alright, but now I'm curious as to why you decided against it.
> Could please elaborate on it a bit ?
OMPI has a long, deep history with the GNU Autotools. It's a very long,
complicated story, but the high points are:
1. The GNU Autotools
Em 15-05-2014 18:40, Ralph Castain escreveu:
On May 15, 2014, at 2:34 PM, Fabricio Cannini wrote:
Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) tho
On May 15, 2014, at 2:34 PM, Fabricio Cannini wrote:
> Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
>> I think Ralph's email summed it up pretty well -- we unfortunately have (at
>> least) two distinct groups of people who install OMPI:
>>
>> a) those who know exactly what they want
On Thu, May 15, 2014 at 06:34:20PM -0300, Fabricio Cannini wrote:
> Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
> >I think Ralph's email summed it up pretty well -- we unfortunately have (at
> >least) two distinct groups of people who install OMPI:
> >
> >a) those who know exactly what
Please allow me to chip in my $0.02 and suggest to not reinvent the
wheel, but instead consider to migrate the build system to cmake :
http://www.cmake.org/
I agree that menu-wise, CMake does a pretty good job with ccmake, and is
much, much easier to create than autoconf/automake/m4 stuff (
Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what th
This is on a Windows box? If so, I don't know if anyone built/posted a 64-bit
release version for Windows (you might check the OMPI site and see if there is
something specific for 64-bit), and we don't support Windows directly any more.
You might also look at the cygwin site for a downloadable v
I wouldn't trust that PMI component in the RTE framework - it was only created
as a test example for that framework. It is routinely broken and not
maintained, and can only be used if forced.
Is this on the trunk? Or are you using the 1.8 series? If the latter, that
component shouldn't even be
I'm not sure of the issue, but so far as I'm aware the cpus-per-proc
functionality continued to work thru all those releases and into today. Yes,
the syntax changed during the 1.7 series to reflect a broader desire to
consolidate options into something that could be contained in a minimum number
On 5/15/2014 3:13 PM, Ajay Nair wrote:
I have been using openMPI for my application with intel visual
fortran. The version that I am currently using is openMPI-1.6.2. It
works fine iwth fortran code compiled in 32bit and run it with openMPI
32 bit files. However recently I moved to a 64 bit
By "goes through orte component", I meant it does go into rte_orte_open
function in rte_orte_component.c.
Let me try to formulate my question in a different way:
There are two components in the rte framework, namely orte and pmi.
The question is whether pmi could be used independent from orte? Or i
What do you mean "goes through orte component"? It will still call into the
orte code base, but will use PMI to do the modex.
On May 15, 2014, at 12:54 PM, Hadi Montakhabi wrote:
> Hello,
>
> I am trying to utilize pmi instead of orte, but I come across the following
> problem.
> I do configu
Hello,
I am trying to utilize pmi instead of orte, but I come across the following
problem.
I do configure using --with-slurm=[slurm installation path] and
--with-pmi=[slurm installation path].
After compiling, I run the executable using:
$srun -n 2 --mpi=pmi2 ./executable
However, this still go
Hello,
I am trying to utilize pmi instead of orte, but I come across the following
problem.
I do configure using --with-slurm=[slurm installation path] and
--with-pmi=[slurm installation path].
After compiling, I run the executable using:
$srun -n 2 --mpi=pmi2 ./executable
However, this still go
Hi,
I have been using openMPI for my application with intel visual fortran. The
version that I am currently using is openMPI-1.6.2. It works fine iwth
fortran code compiled in 32bit and run it with openMPI 32 bit files.
However recently I moved to a 64 bit machine and even though I could
compile t
This bug should be fixed in tonight's tarball, BTW.
On May 15, 2014, at 9:19 AM, Ralph Castain wrote:
> It is an unrelated bug introduced by a different commit - causing mpirun to
> segfault upon termination. The fact that you got the hostname to run
> indicates that this original fix works,
We're open to suggestion, really - just need some help identifying the best
way to get this info out there.
well, OpenMPI information is fragmented and sprayed all over.
In some places, there is mention of a wiki to be updated with
an explanation; for other things, a consumer needs to wander ar
Hi Gus
The issue is that you have to work thru all the various components (leafing
thru the code base) to construct a list of all the things you *don't* want to
build. By default, we build *everything*, so there is no current method to
simply "build only what I want".
For those building static
Hi List
Sorry, but I confess I am having a hard time to understand
all the fuss about this.
At least in OMPI 1.6.5 there are already
two configure options that just knock out support for slurm and
loadleveler if they are set to "no", hopefully for the joy of everybody
that want lean and mean OMP
This worked, thank you. A simple
CFLAGS="-fgnu89-inline" ./configure
did the trick.
On Wed, May 14, 2014 at 6:18 PM, Ralph Castain wrote:
> Just sniffing around the web, I found that this is a problem caused by
> newer versions of gcc. One reporter stated that they resolved the problem
> by a
These are all good points -- thanks for the feedback.
Just to be clear: my point about the menu system was to generate file that
could be used for subsequent installs, very specifically targeted at those who
want/need scriptable installations.
One possible scenario could be: you download OMPI
could you try just for curiosity to force to use OMPIO? e.g.
mpirun --mca io ompio
Thanks
Edgar
On 5/15/2014 3:56 AM, CANELA-XANDRI Oriol wrote:
> Hi, I installed and tried with version 1.8.1 but it also fails. I see the
> error when there are some processes without any matrix block. It's n
It is an unrelated bug introduced by a different commit - causing mpirun to
segfault upon termination. The fact that you got the hostname to run indicates
that this original fix works, so at least we know the connection logic is now
okay.
Thanks
Ralph
On May 15, 2014, at 3:40 AM, Siegmar Gros
I’m not sure how this would apply to other options, but for the scheduler, what
about no scheduler-related options defaults to everything enabled (like
before), but having any explicit scheduler enable option disables by default
all the other schedulers? Multiple explicit enable options would en
A file would do the trick, but from my experience of building programs,
I always prefer configure options. Maybe just an option
--disable-optional
that disables anything that is optional and non-explicitely requested.
Maxime
Le 2014-05-15 08:22, Bennet Fauber a écrit :
Would a separate file t
Would a separate file that contains each scheduler option and is
included by configure do the trick? It might read
include-slurm=YES
include-torque=YES
etc.
If all options are set to default to YES, then the people who want no
options are satisfied, but those of us who would like to change the
c
Le 2014-05-15 06:29, Jeff Squyres (jsquyres) a écrit :
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what th
Hi Ralph,
> Just committed a potential fix to the trunk - please let me know
> if it worked for you
Now I get the hostnames but also a segmentation fault.
tyr fd1026 101 which mpiexec
/usr/local/openmpi-1.9_64_cc/bin/mpiexec
tyr fd1026 102 mpiexec -np 3 --host tyr,sunpc1,linpc1 hostname
tyr.info
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what they want and prefer to have everything
installed, and hav
Hi, I installed and tried with version 1.8.1 but it also fails. I see the error
when there are some processes without any matrix block. It's not a common
situation, but this makes me feel unsure about I am not doing something wrong.
The error I get is:
*** Error in `./binary': free(): invalid
41 matches
Mail list logo
