Also seeing this problem on Fedora Core 5. Any resolution yet?
Brian
On 10/6/07, Dirk Eddelbuettel wrote:
>
> On 6 October 2007 at 09:36, Dirk Eddelbuettel wrote:
> |
> | On 5 October 2007 at 21:31, Brian Barrett wrote:
> | | On Oct 5, 2007, at 8:48 PM, Dirk Eddelbuettel wrote:
> | |
> | | > Wi
From the files you attached, I see the following in config.log:
OMPI_CC_ABSOLUTE=' DISPLAY known
and several lines later:
OMPI_CXX_ABSOLUTE=' DISPLAY known
But in Makefile, I see this bogus 2-line value (same as you noted):
OMPI_CC_ABSOLUTE = DISPLAY known
/usr/bin/gcc
and several lines lat
Interesting idea.
One obvious solution would be to mpirun your controller tasks and, as
you mentioned, use MPI to communicate between them. Then you can use
MPI_COMM_SPAWN to launch the actual MPI job that you want to monitor.
However, this will only more-or-less work. OMPI currently poll
On Oct 7, 2007, at 11:46 PM, Michael Clover wrote:
I tried to look at the checksum of my version of sed, and got a
different number. I also found instructions on an Octave web page
about loading the GNU sed on a Mac, to replace the POSIX flavored one
that comes with it. I was able to load sed
On Oct 7, 2007, at 12:53 AM, Dirk Eddelbuettel wrote:
| Not that I can tell. What else could I test? The build-logs
don't reveal
| anything fishy -- all pt2pt occurrences look fine. The build itself
| proceeded fine (and this was the Debian package build I then uplod)
Two more observations
Jeff,
as it turned out, my .tcshrc file did output "DISPLAY known"... I
had logic to set DISPLAY if it was undefined:
if ( ! $?DISPLAY ) then
if ( ! $?SSH_CLIENT ) then
if ( "$OS" == "darwin") then
# ... irrelevant
else
echo "no environment variable to capt
Excellent! Sorry it took so long to resolve this.
We could put in a few fixes to protect against this specific error
(where we call `which $CC|$CXX`), but I'm not sure if there are other
places in the configure process that rely on `foo` to output only 1
line of data. So I'm not sure that
Hi everybody, I have a doubt regarding ORTE. One of the major
functionality of orte is to maintain GPR, which subscribes and publishes
information to the universe. I have a doubt saying, when we submit job from a
machine, where does GPR gets created? Is it on the submit machine (HNP)?if YES,
Hi Neeraj,
The GPR is maintained in the mpirun (orterun) process. The data is then
distributed via the RML/OOB.
Hope this helps,
Tim
Neeraj Chourasia wrote:
Hi everybody,
I have a doubt regarding ORTE. One of the major functionality of
orte is to maintain GPR, which subscribes and pub
On 8 October 2007 at 22:06, Brian Granger wrote:
| Also seeing this problem on Fedora Core 5. Any resolution yet?
No, none. With the exact same configuration (encoded in the Debian package
build 'recipe' for the package), I get
-- on Debian: 'unable to open osc pt2pt' verbosity but a working
On 9 October 2007 at 08:08, Jeff Squyres wrote:
| On Oct 7, 2007, at 12:53 AM, Dirk Eddelbuettel wrote:
|
| > | Not that I can tell. What else could I test? The build-logs
| > don't reveal
| > | anything fishy -- all pt2pt occurrences look fine. The build itself
| > | proceeded fine (and thi
On Sat, Oct 06, 2007 at 09:29:25PM +0200, Jeff Squyres wrote:
> I'm CC'ing Torsten Hoefler -- he's the main developer of libnbc and
> will answer your question (he just realized he was not subscribed to
> this list :-) ).
thanks Jeff!
> On Oct 1, 2007, at 10:43 AM, Neeraj Chourasia wrote:
>
>
I should say that on FC5, where I see the error, mpi runs just fine.
Brian
On 10/9/07, Dirk Eddelbuettel wrote:
>
> On 8 October 2007 at 22:06, Brian Granger wrote:
> | Also seeing this problem on Fedora Core 5. Any resolution yet?
>
> No, none. With the exact same configuration (encoded in th
13 matches
Mail list logo
