Re: [MTT users] [devel-core] Recent OMPI Trunk fails MPI_Allgatherv_* MTT tests

2007-04-01 Thread Tim Prins
I'm not an MTT developer, but I'll answer #1...

MTT only looks at the return codes from the test programs that are ran. This 
is all well and good, but the problem is that some Intel tests return a 
meaningful value, and some don't. A while ago I went through and fixed all 
the c tests so that they return a meaningful value. But I don't know Fortran, 
so I did not even look at the Fortran versions of the tests. It appears that 
they are not returning a meaningful value, and that somebody needs to fix 
them.

Tim

On Sunday 01 April 2007 09:25 pm, Tim Mattox wrote:
> Hi All,
> I just checked the recent nightly MTT results and found two things of note,
> one for the MTT community, the other for the OMPI developers.
>
> For both, see http://www.open-mpi.org/mtt/reporter.php?do_redir=143
> for details of the failed MTT tests with the OMPI trunk at r14180.
>
> 1) For MTT developers:
> The MTT intel test suite is incorrectly seeing a failed MPI_Allgatherv_f
> test as passed, yet is correctly detecting that the MPI_Allgatherv_c
> test is failing.
> The STDOUT from "passed" MPI_Allgatherv_f seems to indicate that the tests
> actually failed in a similar way to the _c version, but MTT thinks it
> passed. I've not had time to diagnose why MTT is missing this...  anyone
> else have some spare cycles to look at this?
>
> 2) For OMPI developers:
> The MPI_Allgatherv_* tests are failing as of r14180 in all test conditions
> on the IU machines, and others, yet this passed the night before on r14172.
>
> Looking at the svn log for r#'s r14173 thru r14180, I can narrow it down to
> one of these changes as the culprit:
> https://svn.open-mpi.org/trac/ompi/changeset/14180
> https://svn.open-mpi.org/trac/ompi/changeset/14179
> https://svn.open-mpi.org/trac/ompi/changeset/14174 (Not likely)
>
> My money is on the much larger r14180 changeset.
> The other r#'s aren't culprits for obvious reasons.


[MTT users] Differentiating builds in the reporter

2007-06-14 Thread Tim Prins
Hi everyone,

This may be a silly question, but I am new to configuring MTT so I'll ask.

Here at IU on our cluster Thor, we are running the trunk both with threads 
enabled and with threads disabled. How should these builds be differentiated 
for the reporter?

Thanks,

Tim


[MTT users] IBM thread tests

2007-06-14 Thread Tim Prins
I don't know if there is a better place to post this, but...

The IBM test suite has 3 very simple tests which just call Init_thread and ask 
for the thread level. However, these are only run if OMPI_ENABLE_MPI_THREADS 
is defined. This is causing them to be skipped in our MTT tests with a 
threaded build. Is there a different define we should be checking for in the 
tests?

Thanks,

Tim


Re: [MTT users] Differentiating builds in the reporter

2007-06-15 Thread Tim Prins
Thanks. They are indeed using two different install sections, but I did not 
know if there was supposed to be any more separation than this.

Tim

On Friday 15 June 2007 11:50:37 am Ethan Mallove wrote:
> On Fri, Jun/15/2007 10:01:24AM, Jeff Squyres wrote:
> > On Jun 14, 2007, at 10:45 PM, Tim Prins wrote:
> > > Here at IU on our cluster Thor, we are running the trunk
> > > both with  threads enabled and with threads disabled.
> > > How should these builds be  differentiated for the
> > > reporter?
> >
> > Do you have two different MPI install sections for the
> > with/without  threads?  (that's how I have it configured
> > in my Cisco MTT -- not  running in production yet, but it
> > will be soon)
> >
> > If so, they should be naturally separated already.
>
> Or try this.
>
> With threads:
>
> http://www.open-mpi.org/mtt/reporter.php?do_redir=226
>
> Without threads:
>
> http://www.open-mpi.org/mtt/reporter.php?do_redir=227
>
> If you click [Advanced] pop-up window you can see I've
> entered "threads" and "!threads".
>
> -Ethan
>
> > --
> > Jeff Squyres
> > Cisco Systems
> >
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
>
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users


Re: [MTT users] OMPI C++ tests just split

2007-06-23 Thread Tim Prins
On Saturday 23 June 2007 10:58:13 am Jeff Squyres wrote:
> If you are running the MPI 2 C++ tests for OMPI testing, note that I
> just split it into 2 executables.  So if you currently have this in
> your .ini file:
>
>  simple_pass:tests = src/mpi2c++_test
>
> You need to change it to this:
>
>  simple_pass:tests = src/mpi2c++_test src/mpi2c++_dyanmics_test

It is actually (note the spelling of 'dynamics'):
 simple_pass:tests = src/mpi2c++_test src/mpi2c++_dynamics_test


Tim


[MTT users] Database insert errors

2007-07-01 Thread Tim Prins
Hi Folks,

For a while now we have been getting errors when MTT tries to submit its test 
results to the database. The weird thing is that it only happens on our 1.2 
runs, not our trunk runs. 

Here is the first few lines of the error output:
*** WARNING: MTTDatabase server notice: fields is not in mtt3 database.
MTTDatabase server notice: test_build_section_name is not in mtt3
database.
MTTDatabase server notice: mpi_install_section_name is not in mtt3
database.
MTTDatabase server notice: mtt_version_minor is not in mtt3 database.
MTTDatabase server notice: stop_timestamp is not in mtt3 database.
MTTDatabase server notice: mtt_version_major is not in mtt3 database.
MTTDatabase server notice: number_of_results is not in mtt3 database.
MTTDatabase server notice: test_run_section_name is not in mtt3
database.

MTT submission for test run
MTTDatabase server error:
SQL QUERY:
 INSERT INTO speedy_test_run
 (np,
variant,
test_build_id,
command,
test_name,
test_run_id)
 VALUES
 ('8',
'1',
'20809',
'mpirun  -mca pml ob1 -mca btl_tcp_if_include eth0 -mca btl
tcp,sm,self -np 8 --prefix
/san/homedirs/mpiteam/mtt-runs/thor/20070630-Nightly/pb_0/installs/k1mL
/install collective/allgather ',
'allgather',
'14517807')

SQL ERROR: ERROR:  insert or update on table "speedy_test_run" violates
foreign key constraint "$1"
DETAIL:  Key (test_build_id)=(20809) is not present in table
"speedy_test_build".

Another strange thing is that the output says that the build information and 
some test results have been submitted, but I do not see them in the reporter. 
Any ideas?

Thanks,

Tim


Re: [MTT users] Database insert errors

2007-07-09 Thread Tim Prins
Could these errors have to do with the fact that we are running MTT 
v2.0.1, and not the latest version?


Thanks,

Tim

Ethan Mallove wrote:

Hi Tim,

I see some of these FOREIGN KEY constraint errors every
night. There's a system of speedy and archive tables to keep
short-term queries fast, but it has bugs. There are rows in
the archive tables that should be mirrored in the speedy
tables, but this is not always the case. We (well, mostly
Josh) are working on an improved system of "partitioning"
the huge Postgres tables to keep queries fast which will
hopefully also resolve these referential integrity problems.

-Ethan


On Sun, Jul/01/2007 09:37:17PM, Tim Prins wrote:

Hi Folks,

For a while now we have been getting errors when MTT tries to submit its test 
results to the database. The weird thing is that it only happens on our 1.2 
runs, not our trunk runs. 


Here is the first few lines of the error output:
*** WARNING: MTTDatabase server notice: fields is not in mtt3 database.
MTTDatabase server notice: test_build_section_name is not in mtt3
database.
MTTDatabase server notice: mpi_install_section_name is not in mtt3
database.
MTTDatabase server notice: mtt_version_minor is not in mtt3 database.
MTTDatabase server notice: stop_timestamp is not in mtt3 database.
MTTDatabase server notice: mtt_version_major is not in mtt3 database.
MTTDatabase server notice: number_of_results is not in mtt3 database.
MTTDatabase server notice: test_run_section_name is not in mtt3
database.

MTT submission for test run
MTTDatabase server error:
SQL QUERY:
 INSERT INTO speedy_test_run
 (np,
variant,
test_build_id,
command,
test_name,
test_run_id)
 VALUES
 ('8',
'1',
'20809',
'mpirun  -mca pml ob1 -mca btl_tcp_if_include eth0 -mca btl
tcp,sm,self -np 8 --prefix
/san/homedirs/mpiteam/mtt-runs/thor/20070630-Nightly/pb_0/installs/k1mL
/install collective/allgather ',
'allgather',
'14517807')

SQL ERROR: ERROR:  insert or update on table "speedy_test_run" violates
foreign key constraint "$1"
DETAIL:  Key (test_build_id)=(20809) is not present in table
"speedy_test_build".

Another strange thing is that the output says that the build information and 
some test results have been submitted, but I do not see them in the reporter. 
Any ideas?


Thanks,

Tim
___
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

___
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users




[MTT users] Textfile Reporter

2007-07-09 Thread Tim Prins
Hi,

With the new version of MTT, the textfile report file format changed to a more 
human readable format. Since we here at IU use a script to parse this, it 
presents a bit of a problem. I can update our script, but was wondering how 
stable this new output format is.

If it will not be very stable, I was wondering if the developers would 
consider adding a parseable textfile output module. The easiest thing to do 
for this would be to just import the old textfile module as a new parseable 
module. I have tried this and it seems to work fine, however there may be 
problems with this that I am unaware of.

I can deal with this either way, but just thought it might make things easier 
to have a parseable format that is relatively static, and a human readable 
format that can be tweaked for useability as time goes by.

Thanks,

Tim


Re: [MTT users] Textfile Reporter

2007-07-10 Thread Tim Prins
Hmm, the INI file reporter does not seem to work for me. For the test results 
I only get the information about the last test run. 

Anyways, I like the idea of pulling the data directly in from perl output but 
just don't have the time to mess with it right now. For me bringing back the 
old reporter would be easiest for the time being. However, I also need the 
following patch applied to resurect a couple output fields that were removed 
which we need:

Index: lib/MTT/Test/Analyze/Correctness.pm
===
--- lib/MTT/Test/Analyze/Correctness.pm (revision 737)
+++ lib/MTT/Test/Analyze/Correctness.pm (working copy)
@@ -53,6 +53,8 @@

 test_name => $run->{name},
 command => $run->{cmd},
+test_build_section_name => $run->{test_build_simple_section_name},
+
 np => $run->{np},
 exit_value => MTT::DoCommand::exit_value($results->{exit_status}),
 exit_signal => MTT::DoCommand::exit_signal($results->{exit_status}),
Index: lib/MTT/MPI/Install.pm
===
--- lib/MTT/MPI/Install.pm  (revision 737)
+++ lib/MTT/MPI/Install.pm  (working copy)
@@ -505,6 +505,8 @@
 my $report = {
 phase => "MPI Install",

+mpi_install_section_name => $config->{simple_section_name},
+
 bitness => $config->{bitness},
 endian => $config->{endian},
 compiler_name => $config->{compiler_name},


Thanks,

Tim

On Tuesday 10 July 2007 11:46:34 am Ethan Mallove wrote:
> Whoops! I didn't realize anyone was using that Textfile
> module. We can resurrect that if you'd like (call it
> ParseableTextfile).
>
> There's also the INIFile Reporter. That might be your best
> bet, since there's a Config::INIFiles CPAN module. (Your
> wrappers are in Perl, right?) Though wouldn't it be even
> easier if there were a PerlDumper Reporter module so you
> could read in the data *directly* to your Perl wrappers?
> Your wrapper would do no parsing then. E.g.,
>
> open(FILE, "< $file");
> undef $/;
> $mtt_results = ;
>
> -Ethan
>
> On Mon, Jul/09/2007 06:07:51PM, Tim Prins wrote:
> > Hi,
> >
> > With the new version of MTT, the textfile report file
> > format changed to a more human readable format. Since we
> > here at IU use a script to parse this, it presents a bit
> > of a problem. I can update our script, but was wondering
> > how stable this new output format is.
> >
> > If it will not be very stable, I was wondering if the
> > developers would consider adding a parseable textfile
> > output module. The easiest thing to do for this would be
> > to just import the old textfile module as a new parseable
> > module. I have tried this and it seems to work fine,
> > however there may be problems with this that I am unaware
> > of.
> >
> > I can deal with this either way, but just thought it might
> > make things easier to have a parseable format that is
> > relatively static, and a human readable format that can be
> > tweaked for useability as time goes by.
> >
> > Thanks,
> >
> > Tim
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
>
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users


Re: [MTT users] Textfile Reporter

2007-07-10 Thread Tim Prins
Looks good. Thanks for doing this. I did need the following patch though to 
correct a capitalization problem...

Tim

Index: lib/MTT/Reporter/ParsableTextfile.pm
===
--- lib/MTT/Reporter/ParsableTextfile.pm(revision 742)
+++ lib/MTT/Reporter/ParsableTextfile.pm(working copy)
@@ -10,7 +10,7 @@
 # $HEADER$
 #

-package MTT::Reporter::ParsableTextFile;
+package MTT::Reporter::ParsableTextfile;

 use strict;
 use Cwd;


On Tuesday 10 July 2007 04:40:40 pm Ethan Mallove wrote:
> Done.
>
> I brought it back as "ParsableTextfile" in both the trunk
> and ompi-core-testers. You'll just have to do two things in
> your INI file:
>
>  * Change "module = Textfile" to "module = ParsableTextfile"
>  * Rename "textfile_" params to "parsabletextfile_" params
>
> Let me know if you run into any other issues with this.
>
> -Ethan
>
> On Tue, Jul/10/2007 02:27:27PM, Tim Prins wrote:
> > Hmm, the INI file reporter does not seem to work for me. For the test
> > results I only get the information about the last test run.
> >
> > Anyways, I like the idea of pulling the data directly in from perl output
> > but just don't have the time to mess with it right now. For me bringing
> > back the old reporter would be easiest for the time being. However, I
> > also need the following patch applied to resurect a couple output fields
> > that were removed which we need:
> >
> > Index: lib/MTT/Test/Analyze/Correctness.pm
> > ===
> > --- lib/MTT/Test/Analyze/Correctness.pm (revision 737)
> > +++ lib/MTT/Test/Analyze/Correctness.pm (working copy)
> > @@ -53,6 +53,8 @@
> >
> >  test_name => $run->{name},
> >  command => $run->{cmd},
> > +test_build_section_name =>
> > $run->{test_build_simple_section_name}, +
> >  np => $run->{np},
> >  exit_value =>
> > MTT::DoCommand::exit_value($results->{exit_status}), exit_signal =>
> > MTT::DoCommand::exit_signal($results->{exit_status}), Index:
> > lib/MTT/MPI/Install.pm
> > ===
> > --- lib/MTT/MPI/Install.pm  (revision 737)
> > +++ lib/MTT/MPI/Install.pm  (working copy)
> > @@ -505,6 +505,8 @@
> >  my $report = {
> >  phase => "MPI Install",
> >
> > +mpi_install_section_name => $config->{simple_section_name},
> > +
> >  bitness => $config->{bitness},
> >  endian => $config->{endian},
> >  compiler_name => $config->{compiler_name},
> >
> >
> > Thanks,
> >
> > Tim
> >
> > On Tuesday 10 July 2007 11:46:34 am Ethan Mallove wrote:
> > > Whoops! I didn't realize anyone was using that Textfile
> > > module. We can resurrect that if you'd like (call it
> > > ParseableTextfile).
> > >
> > > There's also the INIFile Reporter. That might be your best
> > > bet, since there's a Config::INIFiles CPAN module. (Your
> > > wrappers are in Perl, right?) Though wouldn't it be even
> > > easier if there were a PerlDumper Reporter module so you
> > > could read in the data *directly* to your Perl wrappers?
> > > Your wrapper would do no parsing then. E.g.,
> > >
> > > open(FILE, "< $file");
> > > undef $/;
> > > $mtt_results = ;
> > >
> > > -Ethan
> > >
> > > On Mon, Jul/09/2007 06:07:51PM, Tim Prins wrote:
> > > > Hi,
> > > >
> > > > With the new version of MTT, the textfile report file
> > > > format changed to a more human readable format. Since we
> > > > here at IU use a script to parse this, it presents a bit
> > > > of a problem. I can update our script, but was wondering
> > > > how stable this new output format is.
> > > >
> > > > If it will not be very stable, I was wondering if the
> > > > developers would consider adding a parseable textfile
> > > > output module. The easiest thing to do for this would be
> > > > to just import the old textfile module as a new parseable
> > > > module. I have tried this and it seems to work fine,
> > > > however there may be problems with this that I am unaware
> > > > of.
> > > >
> > > > I can deal with this either way, bu

[MTT users] trouble with new reporter

2007-08-27 Thread Tim Prins

All,

First, I have to say the new faster reporter is very nice.

However, I am running into some difficulty with trial runs. Here is what 
I did:


1. went to www.open-mpi.org/mtt/reporter.php
2. Clicked preferences, toggled show trial runs
3. typed 'IU' into org
4. Press summary

So far so good, I see the performance results I expect. But then if I 
click on the performance results, I get 'no data available for the 
specified query"


Thanks,

Tim


Re: [MTT users] trouble with new reporter

2007-08-27 Thread Tim Prins
Hmm... I just tried this at home and it works.

Maybe I need to get rid of old cookies?

Tim

On Monday 27 August 2007 02:30:17 pm Jeff Squyres wrote:
> Is this an effect of "preferfnces" cookies not propagating properly?
>
> On Aug 27, 2007, at 2:26 PM, Josh Hursey wrote:
> > Weird. I just tried this and it worked fine for me. Showing 25 skampi
> > runs for IU all trials. Can you try it again?
> >
> > -- Josh
> >
> > On Aug 27, 2007, at 2:11 PM, Tim Prins wrote:
> >> All,
> >>
> >> First, I have to say the new faster reporter is very nice.
> >>
> >> However, I am running into some difficulty with trial runs. Here is
> >> what
> >> I did:
> >>
> >> 1. went to www.open-mpi.org/mtt/reporter.php
> >> 2. Clicked preferences, toggled show trial runs
> >> 3. typed 'IU' into org
> >> 4. Press summary
> >>
> >> So far so good, I see the performance results I expect. But then if I
> >> click on the performance results, I get 'no data available for the
> >> specified query"
> >>
> >> Thanks,
> >>
> >> Tim
> >> ___
> >> mtt-users mailing list
> >> mtt-us...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> >
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users




[MTT users] results being submitted as wrong suite

2007-08-27 Thread Tim Prins
Hi folks,

Another question. I am working on trying to get the performance stuff to work, 
using the jms branch. The tests all ran ok, but when they were submitted, all 
of the tests (imb, netpipe, osu, and skampi) are in the database labeled as 
being from the skampi suite.

You can see this here: http://www.open-mpi.org/mtt/reporter.php?do_redir=291
(you may have to enable trial runs).

I looked at my config file but could not find anything immediately wrong. It 
is attached.

Any ideas?

Thanks,

Tim
#==
# Overall configuration
#==

[MTT]

#identifier to say this is part of the collective performance 
#measurements
description = [2007 collective performance bakeoff]

hostfile =
hostlist =
max_np = 
textwrap = 76
drain_timeout = 5
trial = 1

#--

#==
# MPI get phase
#==

[MPI get: ompi-nightly-trunk]
mpi_details = Open MPI

module = OMPI_Snapshot
ompi_snapshot_url = http://www.open-mpi.org/nightly/trunk

#--

#==
# Install MPI phase
#==

[MPI install: odin 32 bit gcc]
mpi_get = ompi-nightly-trunk
save_stdout_on_success = 1
merge_stdout_stderr = 1
ompi_vpath_mode = none

ompi_make_all_arguments = -j 8
ompi_make_check = 1

ompi_compiler_name = gnu
ompi_compiler_version = &shell("gcc --version | head -n 1 | awk '{ print \$3 
}'")
ompi_configure_arguments = 

[MTT users] Database submit error

2007-08-28 Thread Tim Prins

Hi all,

I am working with the jms branch, and when trying to use mpich2, I get 
the following submit error:


*** WARNING: MTTDatabase server notice: mpi_install_section_name is not in
mtt database.
MTTDatabase server notice: number_of_results is not in mtt database.
MTTDatabase server notice: phase is not in mtt database.
MTTDatabase server notice: test_type is not in mtt database.
MTTDatabase server notice: test_build_section_name is not in mtt
database.
MTTDatabase server notice: variant is not in mtt database.
MTTDatabase server notice: command is not in mtt database.
MTTDatabase server notice: fields is not in mtt database.
MTTDatabase server notice: resource_manager is not in mtt database.

MTT submission for test run
MTTDatabase server notice: Invalid test_build_id (47368) given.
Guessing that it should be -1
MTTDatabase server error: ERROR: Unable to find a test_build to
associate with this test_run.

MTTDatabase abort: (Tried to send HTTP error) 400
MTTDatabase abort:
No test_build associated with this test_run
*** WARNING: MTTDatabase did not get a serial; phases will be isolated from
each other in the reports
>> Reported to MTTDatabase: 1 successful submit, 0 failed submits (total of
  12 results)

This happens for each test run section.

Thanks,

Tim


Re: [MTT users] Database submit error

2007-08-28 Thread Tim Prins

It installed and the tests built and made it into the database:
http://www.open-mpi.org/mtt/reporter.php?do_redir=293

Tim

Jeff Squyres wrote:

Did you get a correct MPI install section for mpich2?

On Aug 28, 2007, at 9:05 AM, Tim Prins wrote:


Hi all,

I am working with the jms branch, and when trying to use mpich2, I get
the following submit error:

*** WARNING: MTTDatabase server notice: mpi_install_section_name is  
not in

 mtt database.
 MTTDatabase server notice: number_of_results is not in mtt  
database.

 MTTDatabase server notice: phase is not in mtt database.
 MTTDatabase server notice: test_type is not in mtt database.
 MTTDatabase server notice: test_build_section_name is not in mtt
 database.
 MTTDatabase server notice: variant is not in mtt database.
 MTTDatabase server notice: command is not in mtt database.
 MTTDatabase server notice: fields is not in mtt database.
 MTTDatabase server notice: resource_manager is not in mtt  
database.


 MTT submission for test run
 MTTDatabase server notice: Invalid test_build_id (47368) given.
 Guessing that it should be -1
 MTTDatabase server error: ERROR: Unable to find a test_build to
 associate with this test_run.

 MTTDatabase abort: (Tried to send HTTP error) 400
 MTTDatabase abort:
 No test_build associated with this test_run
*** WARNING: MTTDatabase did not get a serial; phases will be  
isolated from

 each other in the reports
Reported to MTTDatabase: 1 successful submit, 0 failed submits  
(total of

   12 results)

This happens for each test run section.

Thanks,

Tim
___
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users








[MTT users] Test runs not getting into database

2007-09-05 Thread Tim Prins

Hi,

BigRed has not gotten its test results into the database for a while. 
This is running the ompi-core-testers branch. We run by passing the 
results through the mtt-relay.


The mtt-output file has lines like:
*** WARNING: MTTDatabase did not get a serial; phases will be isolated 
from each other in the reports
>> Reported to MTTDatabase: 1 successful submit, 0 failed submits 
(total of 1 result)


I have the database submit files if they would help.

Thanks,

Tim



Re: [MTT users] Test runs not getting into database

2007-09-05 Thread Tim Prins

Here is the smallest one. Let me know if you need anything else.

Tim

Jeff Squyres wrote:
Can you send any one of those mtt database files?  We'll need to  
figure out if this is a client or a server problem.  :-(


On Sep 5, 2007, at 7:40 AM, Tim Prins wrote:


Hi,

BigRed has not gotten its test results into the database for a while.
This is running the ompi-core-testers branch. We run by passing the
results through the mtt-relay.

The mtt-output file has lines like:
*** WARNING: MTTDatabase did not get a serial; phases will be isolated
from each other in the reports

Reported to MTTDatabase: 1 successful submit, 0 failed submits

(total of 1 result)

I have the database submit files if they would help.

Thanks,

Tim

___
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users





$VAR1 = {
  'exit_signal_1' => -1,
  'duration_1' => '5 seconds',
  'mpi_version' => '1.3a1r16038',
  'trial' => 0,
  'mpi_install_section_name_1' => 'bigred 32 bit gcc',
  'client_serial' => undef,
  'hostname' => 's1c2b12',
  'result_stdout_1' => '/bin/rm -f *.o *~ PI* core IMB-IO IMB-EXT 
IMB-MPI1 exe_io exe_ext exe_mpi1
touch IMB_declare.h
touch exe_mpi1 *.c; rm -rf exe_io exe_ext
make MPI1 CPP=MPI1
make[1]: Entering directory 
`/N/ptl01/mpiteam/bigred/20070905-Wednesday/pb_0/installs/d7Ri/tests/imb/IMB_2.3/src\'
mpicc  -I.  -DMPI1 -O -c IMB.c
mpicc  -I.  -DMPI1 -O -c IMB_declare.c
mpicc  -I.  -DMPI1 -O -c IMB_init.c
mpicc  -I.  -DMPI1 -O -c IMB_mem_manager.c
mpicc  -I.  -DMPI1 -O -c IMB_parse_name_mpi1.c
mpicc  -I.  -DMPI1 -O -c IMB_benchlist.c
mpicc  -I.  -DMPI1 -O -c IMB_strgs.c
mpicc  -I.  -DMPI1 -O -c IMB_err_handler.c
mpicc  -I.  -DMPI1 -O -c IMB_g_info.c
mpicc  -I.  -DMPI1 -O -c IMB_warm_up.c
mpicc  -I.  -DMPI1 -O -c IMB_output.c
mpicc  -I.  -DMPI1 -O -c IMB_pingpong.c
mpicc  -I.  -DMPI1 -O -c IMB_pingping.c
mpicc  -I.  -DMPI1 -O -c IMB_allreduce.c
mpicc  -I.  -DMPI1 -O -c IMB_reduce_scatter.c
mpicc  -I.  -DMPI1 -O -c IMB_reduce.c
mpicc  -I.  -DMPI1 -O -c IMB_exchange.c
mpicc  -I.  -DMPI1 -O -c IMB_bcast.c
mpicc  -I.  -DMPI1 -O -c IMB_barrier.c
mpicc  -I.  -DMPI1 -O -c IMB_allgather.c
mpicc  -I.  -DMPI1 -O -c IMB_allgatherv.c
mpicc  -I.  -DMPI1 -O -c IMB_alltoall.c
mpicc  -I.  -DMPI1 -O -c IMB_sendrecv.c
mpicc  -I.  -DMPI1 -O -c IMB_init_transfer.c
mpicc  -I.  -DMPI1 -O -c IMB_chk_diff.c
mpicc  -I.  -DMPI1 -O -c IMB_cpu_exploit.c
mpicc   -o IMB-MPI1 IMB.o IMB_declare.o  IMB_init.o IMB_mem_manager.o 
IMB_parse_name_mpi1.o  IMB_benchlist.o IMB_strgs.o IMB_err_handler.o 
IMB_g_info.o  IMB_warm_up.o IMB_output.o IMB_pingpong.o IMB_pingping.o 
IMB_allreduce.o IMB_reduce_scatter.o IMB_reduce.o IMB_exchange.o IMB_bcast.o 
IMB_barrier.o IMB_allgather.o IMB_allgatherv.o IMB_alltoall.o IMB_sendrecv.o 
IMB_init_transfer.o  IMB_chk_diff.o IMB_cpu_exploit.o   
make[1]: Leaving directory 
`/N/ptl01/mpiteam/bigred/20070905-Wednesday/pb_0/installs/d7Ri/tests/imb/IMB_2.3/src\'
',
  'mpi_name' => 'ompi-nightly-trunk',
  'number_of_results' => '1',
  'phase' => 'Test Build',
  'compiler_version_1' => '3.3.3',
  'exit_value_1' => 0,
  'result_message_1' => 'Success',
  'start_timestamp_1' => 'Wed Sep  5 04:16:52 2007',
  'compiler_name_1' => 'gnu',
  'suite_name_1' => 'imb',
  'test_result_1' => 1,
  'mtt_client_version' => '2.1devel',
  'fields' => 
'compiler_name,compiler_version,duration,exit_signal,exit_value,mpi_get_section_name,mpi_install_id,mpi_install_section_name,mpi_name,mpi_version,phase,result_message,result_stdout,start_timestamp,suite_name,test_result',
  'mpi_install_id' => undef,
  'platform_name' => 'IU_BigRed',
  'local_username' => 'mpiteam',
  'mpi_get_section_name_1' => 'ompi-nightly-trunk'
};


[MTT users] Problem with reporter: selecting bitness

2007-09-20 Thread Tim Prins

Hi,

I was doing a search and hit advanced, entered '32' into the bitness 
field, and pressed submit. I got back the following error:


postgres: ERROR: operator does not exist: bit ~* "unknown" LINE 70: 
(bitness ~* '32') ^ HINT: No operator matches the given name and 
argument type(s). You may need to add explicit type casts. postgres: 
ERROR: operator does not exist: bit ~* "unknown" LINE 70: (bitness ~* 
'32') ^ HINT: No operator matches the given name and argument type(s). 
You may need to add explicit type casts.



Thanks,

Tim


[MTT users] Reporter problems

2008-01-29 Thread Tim Prins

Hi,

Using the reporter this morning it is being awfully slow, as in it is 
taking about 3 minutes to do a top level summary search for:

List-Post: mtt-users@lists.open-mpi.org
Date: past 24 hours
Org: IU
Platform name: IU_Odin

I don't know whether this is a known problem or not. I seem to recall 
that after the last database upgrade such a search was taking just a few 
seconds.


Thanks,

Tim


[MTT users] 'whatami' patch

2008-01-29 Thread Tim Prins

Hi,

The 'whatami' script does not recognize our new cluster. Attached is a 
patch to make it work.


For reference, the relevant line in /etc/issue is:
Red Hat Enterprise Linux Server release 5 (Tikanga)


Thanks,

Tim
Index: client/whatami/whatami
===
--- client/whatami/whatami  (revision 1142)
+++ client/whatami/whatami  (working copy)
@@ -189,6 +189,10 @@
 #distro=${distro_brand}${distro_version}_${sub_distro}
 distro=${distro_brand}${distro_version}

+elif [ -n "`egrep 'Red Hat Enterprise Linux Server release 
[0-9]*' /etc/issue`" ]; then
+distro_brand=rhel_server
+distro_version=`grep 'Red Hat' /etc/issue | sed -e 
's/Red Hat Enterprise Linux Server release \([0-9]*\).*/\1/' `
+distro=${distro_brand}${distro_version} 
 elif [ -n "`egrep 'Cray Rocks Linux release 1.3' /etc/issue`" 
]; then
 distro=rh73