Hi,
thanks for the comments. I will definetly implement all of them and commit
the code as soon as I finished.

Also I experience few problems with using opal_verbose_output, either there
is a bugs or I am doing something wrong.


/home/USERS/lenny/OMPI_ORTE_DEBUG/bin/mpirun -mca mca_verbose 0 -mca
paffinity_base_verbose 1 --byslot -np 2 -hostfile hostfile -mca
btl_openib_max_lmc 1  -mca opal_paffinity_alone 1 -mca btl_openib_verbose 1
/home/USERS/lenny/TESTS/ORTE/mpi_p01_debug -t lt


/home/USERS/lenny/TESTS/ORTE/mpi_p01_debug: symbol lookup error:
/home/USERS/lenny/OMPI_ORTE_DEBUG//lib/openmpi/mca_btl_openib.so: undefined
symbol: mca_btl_base_out
/home/USERS/lenny/TESTS/ORTE/mpi_p01_debug: symbol lookup error:
/home/USERS/lenny/OMPI_ORTE_DEBUG//lib/openmpi/mca_btl_openib.so: undefined
symbol: mca_btl_base_out
--------------------------------------------------------------------------
mpirun has exited due to process rank 1 with PID 5896 on
node witch17 exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).


On Wed, Mar 26, 2008 at 2:50 PM, Ralph H Castain <r...@lanl.gov> wrote:

> I would tend to echo Tim's suggestions. I note that you do lookup that
> opal
> mca param in orte as well. I know you sent me a note about that off-list -
> I
> apologize for not getting to it yet, but was swamped yesterday.
>
> I think the solution suggested in #1 below is the right approach. Looking
> up
> opal params in orte or ompi is probably not a good idea. We have had
> problems in the past where params were looked up in multiple places as
> people -do- sometimes change the names (ahem...).
>
> Also, I would suggest using the macro version of verbose
> OPAL_OUTPUT_VERBOSE
> so that it compiles out for non-debug builds - up to you. Many of us use
> it
> as we don't need the output from optimized builds.
>
> Other than that, I think this looks fine. I do truly appreciate the
> cleanup
> of ompi_mpi_init.
>
> Ralph
>
>
>
> On 3/26/08 6:09 AM, "Tim Prins" <tpr...@cs.indiana.edu> wrote:
>
> > Hi Lenny,
> >
> > This looks good. But I have a couple of suggestions (which others may
> > disagree with):
> >
> > 1. You register an opal mca parameter, but look it up in ompi, then call
> > a opal function with the result. What if you had a function
> > opal_paffinity_base_set_slots(long rank) (or some other name, I don't
> > care) which looked up the mca parameter and then setup the slots as you
> > are doing if it is fount. This would make things a bit cleaner IMHO.
> >
> > 2. the functions in the paffinety base should be prefixed with
> > 'opal_paffinity_base_'
> >
> > 3. Why was the ompi_debug_flag added? It is not used anywhere.
> >
> > 4. You probably do not need to add the opal debug flag. There is already
> > a 'paffinity_base_verbose' flag which should suit your purposes fine. So
> > you should just be able to replace all of the conditional output
> > statements in paffinity with something like
> > opal_output_verbose(10, opal_paffinity_base_output, ...),
> > where 10 is the verbosity level number.
> >
> > Tim
> >
> >
> > Lenny Verkhovsky wrote:
> >>
> >>
> >> Hi, all
> >>
> >> Attached patch for modified Rank_File RMAPS component.
> >>
> >>
> >>
> >> 1.    introduced new general purpose debug flags
> >>
> >>       mpi_debug
> >>
> >>       opal_debug
> >>
> >>
> >>
> >> 2.    introduced new mca parameter opal_paffinity_slot_list
> >>
> >> 3.    ompi_mpi_init cleaned from opal paffinity functions
> >>
> >> 4.    opal paffinity functions moved to new file
> >> opal/mca/paffinity/base/paffinity_base_service.c
> >>
> >> 5.    rank_file component files were renamed according to prefix policy
> >>
> >> 6.    global variables renamed as well.
> >>
> >> 7.    few bug fixes that were brought during previous discussions.
> >>
> >> 8.    If user defines opal_paffinity_alone and rmaps_rank_file_path or
> >> opal_paffinity_slot_list,
> >>
> >> then he gets a Warning that only opal_paffinity_alone will be used.
> >>
> >>
> >>
> >> .
> >>
> >> Best Regards,
> >>
> >> Lenny.
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> devel mailing list
> >> de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >
> > _______________________________________________
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

Reply via email to