proc_get_epoch( proc );
calls ORTE_NAME_PRINT(proc)
when in debug mode.
When this is the case, ORTE_NAME_PRINT prints all fields of proc, including
epoch. So, proc->epoch = proc_get_epoch(proc) triggers the valgrind warning,
because of the print, in debug mode.
This is the only reason why proc->
The warnings issued through ess_base_select.c:46 are annoying but harmless.
Wesley is going to hunt them and remove them, but they are really issued
because of the print:
orte_ess_base_proc_get_epoch (ess_base_select.c:46) calls
ORTE_NAME_PRINT(proc), which prints proc->epoch, before proc->epoc
suggestion on how
>> to resolve this or work around this.
>>
>> We have thought about mapping all processes from a mpirun into a
>> single job to simplify job resource tracking, but that will require much
>> spread changes in our software.
>>
>> Thanks.
>&g
Hi,
Could you explain why you would like one orted on top of each MPI process?
There are some situations, like resource usage limitation / accounting, that
are possible to solve without changing the one daemon per node deployment.
Or do you enforce other kinds of restrictions on the orted process
Hi,
I just tested compiling ompi on a LSF cluster (LSF 7.0.2) (see ticket
1356).
I could solve a few trivial bugs myself (see svn diff below), however
I hit compile errors beyond my knowledge of ORTE internal structures
in orte/mca/ras/lsf/ras_lsf_module.c and orte/mca/ras/lsf/
ras_lsf_com
