Hello,
I am running a MPI application on a single host, with a dual quadcore with
hyperthreading on. (16 OS-visible processors), but just in debug mode
(msvc2010) 32bit, with 2 mpi processes only.
mpirun -mca btl_tcp_if_exclude lo -np 1 prog1.exe : -np 1 prog2.exe
. when progr1.exe has 1 thread
Apologies for the issue,
I was getting output from the 2 processes, and their threads, and I was
focused on only 1 process.
Please ignore,
On 13 February 2014 14:33, MM wrote:
> Hello,
>
> I am running a MPI application on a single host, with a dual quadcore with
> hyperthreading on. (16 OS-v
On 13 February 2014 15:33, Matthias Troyer wrote:
> Hi,
>
> In orders to use MPI in a multi-threaded environment, even when only one
> thread uses MPI, you need to request the necessary level of thread support
> in the environment constructor. Then you'd an check whether your MPI
> implementation
Why does ompi_info -c say "MPI I/O Support: yes" even though I configured using
-disable-io-romio? If ompi_info is going to tell me MPI I/O is supported, then
shouldn't I expect my test program (attached) to work correctly? (it doesn't).
I didn't disable "built-in" mpi-io, only io-romio.
--
my ompi_info says (openmpi)
Threading support: No
Does that mean it's not supported?
If so, what to do?
On 13 February 2014 17:00, Matthias Troyer wrote:
>
>
>
>
>
> On Feb 13, 2014, at 17:44, MM wrote:
>
> On 13 February 2014 15:33, Matthias Troyer wrote:
>
>> Hi,
>>
>> In orders to use M
Le 13 févr. 2014 à 15:23, MM a écrit :
> my ompi_info says (openmpi)
> Threading support: No
>
> Does that mean it's not supported?
>
Yes, that’s what it means.
> If so, what to do?
>
Gently ignore that information. Open MPI works for “serialized” workloads, even
when thread support is di
Hmmm...well, a little digging says that we probably didn't do this as
thoroughly as we should have :-/
Basically, the "MPI I/O Support" line is tied solely to the disable-mpi-io
flag. In the 1.6 series, you only had one option for MPI I/O support, and that
was romio. So if you disable romio, th
Hi Ralph,
I would report one more finding in openmpi-1.7.5a1.
Because ORTE_MAPPING_BY...s are not a bit field expression,
at orte_rmaps_base_set_ranking_policy in rmaps_base_frame.c
you should not use "&" to compare them:
747 if (NULL == spec) {
748 /* check for map-by objec
Thanks - these used to be bitmaps, but changed when we started getting so many
options. Sadly, they are very rarely used, so bugs like this can go unnoticed
for long times. Appreciate you taking such a close look at them.
Ralph
On Feb 13, 2014, at 4:55 PM, tmish...@jcity.maeda.co.jp wrote:
>
You are welcome, Ralph.
But, after fixing it, I'm facing another problem whin I use ppr option:
[mishima@manage openmpi-1.7.4]$ mpirun -np 2 -map-by ppr:1:socket -bind-to
socket -report-bindings ~/mis/openmpi/demos/m
yprog
[manage.cluster:28057] [[25570,0],0] ORTE_ERROR_LOG: Not implemented in
f
Hi George,
Thank you for your prompt reply, but my apologies for missing it and it's
been quite a while.
Anyway, to answer your question I was trying to do sendrecv in a chain
where "toSend" and "receiveFrom" ranks are not the same. I was using a
single buffer, which resulted in cases where the b
I've found it. Please add 2 lines(770, 771) in rmaps_base_frame.c:
747 if (NULL == spec) {
748 /* check for map-by object directives - we set the
749 * ranking to match if one was given
750 */
751 if (ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING
Sorry, one more shot - byslot was dropped!
if (NULL == spec) {
/* check for map-by object directives - we set the
* ranking to match if one was given
*/
if (ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE(mapping)) {
if (ORTE_MAPPING_BYSLOT == OR
13 matches
Mail list logo