Re: [OMPI users] OpenMPI Run-Time "Freedom" Question

[Jed Brown]

Or OMPI_CC=icc-xx.y mpicc ...

Jed

On Aug 12, 2010 5:18 PM, "Ralph Castain"  wrote:


On Aug 12, 2010, at 7:04 PM, Michael E. Thomadakis wrote:

> On 08/12/10 18:59, Tim Prince wrote:
>>...
The "easy" way to accomplish this would be to:

(a) build OMPI with whatever compiler you decide to use as a "baseline"

(b) do -not- use the wrapper compiler to build the application. Instead, do
"mpicc --showme" (or whatever language equivalent you want) to get the
compile line, substitute your "new" compiler library for the "old" one, and
then execute the resulting command manually.

If you then set your LD_LIBRARY_PATH to the "new" libs, it might work - but
no guarantees. Still, you could try it - and if it worked, you could always
just explain that this is a case-by-case situation, and so it -could- break
with other compiler combinations.

Critical note: the app developers would have to validate the code with every
combination! Otherwise, correct execution will be a complete crap-shoot -
just because the app doesn't abnormally terminate does -not- mean it
generated a correct result!




> Thanks for the information on this. We indeed use Intel Compiler set
11.1.XXX + OMPI 1.4.1 and ...

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

Re: [OMPI users] Abort

[Gus Correa]

David Zhang wrote:
When my MPI code fails (seg fault), it usually cause the rest of the mpi 
process to abort as well.  Perhaps rather than calling abort(), perhaps 
you could do a divide-by-zero operation to halt the program?

David Zhang
University of California, San Diego

>
On Thu, Aug 12, 2010 at 6:49 PM, David Ronis > wrote:


I've got a mpi program that is supposed to to generate a core file if
problems arise on any of the nodes.   I tried to do this by adding a
call to abort() to my exit routines but this doesn't work; I get no core
file, and worse, mpirun doesn't detect that one of my nodes has
aborted(?) and doesn't kill off the entire job, except in the trivial
case where the number of processors I'm running on is 1.   I've replaced
abort with MPI_Abort, which kills everything off, but leaves no core
file.  Any suggestions how I can get one and still have mpi exit?

Thanks in advance.

David
 


Also, make sure your computers' coredumpsize / core file size
limit is not zero, which is sometimes the case.

Gus Correa

Re: [OMPI users] Abort

[Ralph Castain]

Sounds very strange - what OMPI version, on what type of machine, and how was 
it configured?


On Aug 12, 2010, at 7:49 PM, David Ronis wrote:

> I've got a mpi program that is supposed to to generate a core file if
> problems arise on any of the nodes.   I tried to do this by adding a
> call to abort() to my exit routines but this doesn't work; I get no core
> file, and worse, mpirun doesn't detect that one of my nodes has
> aborted(?) and doesn't kill off the entire job, except in the trivial
> case where the number of processors I'm running on is 1.   I've replaced
> abort with MPI_Abort, which kills everything off, but leaves no core
> file.  Any suggestions how I can get one and still have mpi exit?
> 
> Thanks in advance.
> 
> David
> 
> 
> 
> 
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Abort

[David Zhang]

When my MPI code fails (seg fault), it usually cause the rest of the mpi
process to abort as well.  Perhaps rather than calling abort(), perhaps you
could do a divide-by-zero operation to halt the program?

On Thu, Aug 12, 2010 at 6:49 PM, David Ronis  wrote:

> I've got a mpi program that is supposed to to generate a core file if
> problems arise on any of the nodes.   I tried to do this by adding a
> call to abort() to my exit routines but this doesn't work; I get no core
> file, and worse, mpirun doesn't detect that one of my nodes has
> aborted(?) and doesn't kill off the entire job, except in the trivial
> case where the number of processors I'm running on is 1.   I've replaced
> abort with MPI_Abort, which kills everything off, but leaves no core
> file.  Any suggestions how I can get one and still have mpi exit?
>
> Thanks in advance.
>
> David
>
>
>
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>



-- 
David Zhang
University of California, San Diego

Re: [OMPI users] MPI_Bcast issue

[Randolph Pullen]

Sorry for the late replies but with work, time zones etc…

This post has been going on for a while and in an attempt bring it to a close 
I’m going to try to collapse this down to some core issues and answer all the 
questions in 1 place.

Richard: yes your last statement is correct, I am just using PVm solely as a 
launcher, the MPI worlds are semantically independent. 

Jeffs suggestion that it may be a network congestion issue rings a bell 
somewhere.
Jeff, although it is possible to make a small example program, this would 
require PVM or some other method of launching MPI simultaneously on each node. 
I would agree that this is a bit off topic for this forum and so I won’t 
mention it further.  

In finalizing this issue, I would like to discuss the characteristics of the 
other options available.  If I understood what to expect from the alltoall on a 
large cluster and given the scenario outlined below it may help me greatly in 
deciding how (or if) to re-write this.

BTW:  Jeff,  sorry if I miss quoted you, I must have miss-understood.
>From your post reproduced in part here:
==
>- All of Open MPI's network-based collectives use point-to-point 
>communications underneath (shared memory may not, but that's not the issue 
>here).  One of the implementations is linear, meaning that the root sends the 
>message to comm rank 1, then comm rank 2, ..etc.  But this algorithm is only 
>used when the message is small, the number of peers is small, etc.  All the 
>other 
>algorithms are parallel in nature, meaning that after an iteration or two, 
>>multiple processes have the data and can start pipelining sends to other 
>processes, etc.
==

What I meant when I said b-tree is nearly right I think – I should have said 
‘in an N-Tree manner’ but both would produce O(log N) solutions and I agree 
that these are all perfectly fine for almost everything.

This assumes that you have ‘adequate’ network bandwidth as you correctly 
pointed out in your recent post.  This may not be the case for my problem (see 
below)

The Problem:
-    A large all to all (N to N transmission or N broadcasts) of possibly 
hundreds of GB in total.
-    The cluster size my clients will use is unknown at this time but probably 
in the order of between 10 to a few hundred nodes.
-    The number of nodes is likely to increase with the data size but the ratio 
of data/node is unknown and variable.

My design Goals:
1.    Speed and accuracy are everything.  Accuracy is paramount but the system 
would become unusable if this algorithm became exponential.
2.    I love the flexibility OMPI brings to fabric deployment.  I want to pass 
on the richness of these choices to my clients/customers – however if IB (or 
some other) plugin solution moved the alltoall algorithm from say  O(N log N) 
to  just O(Log N) transmission, its mandatory use may be an acceptable solution 
on larger clusters

My Assumptions
1.    I can concentrate on providing the best near linear solutions and ignore 
site implementation peculiarities
2.    Tuning each installation can accommodate all site specific idiosyncrasies
3.    The solution will probably be network bound.  No mater how fast the 
network is, 100GB may well be too much for concurrent p2p transmissions to run 
in O(log N) time
[please feel free to trash my assumptions]

This is a difficult problem, I have written 3 solutions for this using 
different technologies and I have been unsatisfied with each so far.

Theoretically the problem can be solved in N broadcasts but [Jeff] as you point 
out, in practice, data loss is likely on the nodes who are not ready etc..  
However a near O(N) solution  should be possible.

It appears that OMPI’s Bcast is O(log N) for N > a trivial number of nodes
So AlltoAll is probably at least O(N log N) – unless it utilises something 
other than p2p transmissions and its only O(N log N) if there is adequate 
bandwidth on the network fabric.

Do I have it correct?
Is alltoall going to work for me ?

Randolph




--- On Fri, 13/8/10, Jeff Squyres  wrote:

From: Jeff Squyres 
Subject: Re: [OMPI users] MPI_Bcast issue
To: "Open MPI Users" 
Received: Friday, 13 August, 2010, 3:03 AM

Dick / all --

I just had a phone call with Ralph Castain who has had some additional off-list 
mails with Randolph.  Apparently, none of us understand the model that is being 
used here.  There are also apparently some confidentiality issues involved such 
that it might be difficult to publicly state enough information to allow the 
open community to understand, diagnose, and fix the issue.  So I'm not quite 
sure how to proceed here -- I'm afraid that I don't have the time or resources 
for private problem resolution in an unorthodox situation like this.

For example, I was under the impression that PVM was solely being used as a 

[OMPI users] Abort

[David Ronis]

I've got a mpi program that is supposed to to generate a core file if
problems arise on any of the nodes.   I tried to do this by adding a
call to abort() to my exit routines but this doesn't work; I get no core
file, and worse, mpirun doesn't detect that one of my nodes has
aborted(?) and doesn't kill off the entire job, except in the trivial
case where the number of processors I'm running on is 1.   I've replaced
abort with MPI_Abort, which kills everything off, but leaves no core
file.  Any suggestions how I can get one and still have mpi exit?

Thanks in advance.

David

Re: [OMPI users] OpenMPI Run-Time "Freedom" Question

[Tim Prince]

On 8/12/2010 6:04 PM, Michael E. Thomadakis wrote:

On 08/12/10 18:59, Tim Prince wrote:

On 8/12/2010 3:27 PM, Ralph Castain wrote:
Ick - talk about confusing! I suppose there must be -some- rational 
reason why someone would want to do this, but I can't imagine what 
it would be


I'm no expert on compiler vs lib confusion, but some of my own 
experience would say that this is a bad idea regardless of whether 
or not OMPI is involved. Compiler version interoperability is 
usually questionable, depending upon how far apart the rev levels are.


Only answer I can offer is that you would have to try it. It will 
undoubtedly be a case-by-case basis: some combinations might work, 
others might fail.



On Aug 12, 2010, at 3:53 PM, Michael E. Thomadakis wrote:


Hello OpenMPI,

we have deployed OpenMPI 1.4.1 and 1.4.2 on our Intel Nehalem 
cluster using Intel compilers V 11.1.059 and 11.1.072 respectively, 
and one user has the following request:


Can we build OpenMPI version say O.1 against Intel compilers 
version say I.1 but  then built an application with OpenMPI O.1 BUT 
then use a DIFFERENT Intel compiler version say I.2 to built and 
run this MPI application?


I suggested to him to 1) simply try to built and run the 
application with O.1 but use Intel compilers version I.X whatever 
this X is and see if it has any issues.


OR 2) If the above does not work, I would build OpenMPI O.1 against 
Intel version I.X so he can use THIS combination for his 
hypothetical application.


He insists that I build OpenMPI O.1 with some version of Intel 
compilers I.Y but then at run time he would like to use *different* 
Intel run time libs at will I.Z <> I.X.


Can you provide me with a suggestion for a sane solution to this ? :-)

Best regards

Michael
Guessing at what is meant here, if you build MPI with a given version 
of Intel compilers, it ought to work when the application is built 
with a similar or more recent Intel compiler, or when the run-time 
LD_LIBRARY_PATH refers to a similar or newer library (within reason). 
There are similar constraints on glibc version.  "Within reason" 
works over a more restricted range when C++ is involved.  Note that 
the Intel linux compilers link to the gcc and glibc libraries as well 
as those which come with the compiler, and the MPI could be built 
with a combination of gcc and ifort to work with icc or gcc and 
ifort.  gfortran and ifort libraries, however, are incompatible, 
except that libgomp calls can be supported by libiomp5.
The "rational" use I can see is that an application programmer would 
likely wish to test a range of compilers without rebuilding MPI.  
Intel documentation says there is forward compatibility testing of 
libraries, at least to the extent that a build made with 10.1 would 
work with 11.1 libraries.
The most recent Intel library compatibility break was between MKL 9 
and 10.




Dear Tim, I offered to provide myself the combination of OMPI+ Intel 
compilers so that application can use it in stable fashion. When I 
inquired about this application so I can look into this I was told 
that "there is NO application yet (!) that fails but just in case it 
fails ..." I was asked to hack into the OMPI  building process to let 
OMPI use one run-time but then the MPI application using this OMPI ... 
use another!



Thanks for the information on this. We indeed use Intel Compiler set 
11.1.XXX + OMPI 1.4.1 and 1.4.2.


The basic motive in this hypothetical situation is to build the MPI 
application ONCE and then swap run-time libs as newer compilers come 
out I am certain that even if one can get away with it with nearby 
run-time versions there is no guarantee of the stability at-infinitum. 
I end up having to spent more time for technically "awkward" requests 
than the reasonable ones. Reminds me when I was a teacher I had to 
spent more time with all the people trying to avoid doing the work 
than with the good students... hmmm :-)


According to my understanding, your application (or MPI) built with an 
Intel 11.1 compiler should continue working with future Intel 11.1 and 
12.x libraries.  I don't expect Intel to test or support this 
compatibility beyond that.
You will likely want to upgrade your OpenMPI earlier than the time when 
Intel compiler changes require a new MPI build.
If the interest is in getting performance benefits of future hardware 
simply by installing new dynamic libraries without rebuilding an 
application, Intel MKL is the most likely favorable scenario.  The MKL 
with optimizations for AVX is already in  beta test, and should work as 
a direct replacement for the MKL in current releases.


--
Tim Prince

Re: [OMPI users] OpenMPI Run-Time "Freedom" Question

[Ralph Castain]

On Aug 12, 2010, at 7:04 PM, Michael E. Thomadakis wrote:

> On 08/12/10 18:59, Tim Prince wrote:
>> 
>> On 8/12/2010 3:27 PM, Ralph Castain wrote:
>>> 
>>> Ick - talk about confusing! I suppose there must be -some- rational reason 
>>> why someone would want to do this, but I can't imagine what it would be
>>> 
>>> I'm no expert on compiler vs lib confusion, but some of my own experience 
>>> would say that this is a bad idea regardless of whether or not OMPI is 
>>> involved. Compiler version interoperability is usually questionable, 
>>> depending upon how far apart the rev levels are.
>>> 
>>> Only answer I can offer is that you would have to try it. It will 
>>> undoubtedly be a case-by-case basis: some combinations might work, others 
>>> might fail.
>>> 
>>> 
>>> On Aug 12, 2010, at 3:53 PM, Michael E. Thomadakis wrote:
>>> 
 Hello OpenMPI,
 
 we have deployed OpenMPI 1.4.1 and 1.4.2 on our Intel Nehalem cluster 
 using Intel compilers V 11.1.059 and 11.1.072 respectively, and one user 
 has the following request:
 
 Can we build OpenMPI version say O.1 against Intel compilers version say 
 I.1 but  then built an application with OpenMPI O.1 BUT then use a 
 DIFFERENT Intel compiler version say I.2 to built and run this MPI 
 application?
 
 I suggested to him to 1) simply try to built and run the application with 
 O.1 but use Intel compilers version I.X whatever this X is and see if it 
 has any issues. 
 
 OR 2) If the above does not work, I would build OpenMPI O.1 against Intel 
 version I.X so he can use THIS combination for his hypothetical 
 application. 
 
 He insists that I build OpenMPI O.1 with some version of Intel compilers 
 I.Y but then at run time he would like to use different Intel run time 
 libs at will I.Z <> I.X. 
 
 Can you provide me with a suggestion for a sane solution to this ? :-) 
 
 Best regards
 
 Michael
>> Guessing at what is meant here, if you build MPI with a given version of 
>> Intel compilers, it ought to work when the application is built with a 
>> similar or more recent Intel compiler, or when the run-time LD_LIBRARY_PATH 
>> refers to a similar or newer library (within reason). There are similar 
>> constraints on glibc version.  "Within reason" works over a more restricted 
>> range when C++ is involved.  Note that the Intel linux compilers link to the 
>> gcc and glibc libraries as well as those which come with the compiler, and 
>> the MPI could be built with a combination of gcc and ifort to work with icc 
>> or gcc and ifort.  gfortran and ifort libraries, however, are incompatible, 
>> except that libgomp calls can be supported by libiomp5.
>> The "rational" use I can see is that an application programmer would likely 
>> wish to test a range of compilers without rebuilding MPI.  Intel 
>> documentation says there is forward compatibility testing of libraries, at 
>> least to the extent that a build made with 10.1 would work with 11.1 
>> libraries.
>> The most recent Intel library compatibility break was between MKL 9 and 10.
>> 
> 
> Dear Tim, I offered to provide myself the combination of OMPI+ Intel 
> compilers so that application can use it in stable fashion. When I inquired 
> about this application so I can look into this I was told that "there is NO 
> application yet (!) that fails but just in case it fails ..." I was asked to 
> hack into the OMPI  building process to let OMPI use one run-time but then 
> the MPI application using this OMPI ... use another! 
> 
> 

The "easy" way to accomplish this would be to:

(a) build OMPI with whatever compiler you decide to use as a "baseline"

(b) do -not- use the wrapper compiler to build the application. Instead, do 
"mpicc --showme" (or whatever language equivalent you want) to get the compile 
line, substitute your "new" compiler library for the "old" one, and then 
execute the resulting command manually.

If you then set your LD_LIBRARY_PATH to the "new" libs, it might work - but no 
guarantees. Still, you could try it - and if it worked, you could always just 
explain that this is a case-by-case situation, and so it -could- break with 
other compiler combinations.

Critical note: the app developers would have to validate the code with every 
combination! Otherwise, correct execution will be a complete crap-shoot - just 
because the app doesn't abnormally terminate does -not- mean it generated a 
correct result!


> Thanks for the information on this. We indeed use Intel Compiler set 11.1.XXX 
> + OMPI 1.4.1 and 1.4.2.
> 
> The basic motive in this hypothetical situation is to build the MPI 
> application ONCE and then swap run-time libs as newer compilers come out 
> I am certain that even if one can get away with it with nearby run-time 
> versions there is no guarantee of the stability at-infinitum. I end up having 
> to spent more time for technically "awkward" requests 

Re: [OMPI users] OpenMPI Run-Time "Freedom" Question

[Terry Frankcombe]

On Thu, 2010-08-12 at 20:04 -0500, Michael E. Thomadakis wrote:
> The basic motive in this hypothetical situation is to build the MPI 
> application ONCE and then swap run-time libs as newer compilers come out 

Not building your application with the compiler you want to use sounds
like a very bad idea to me.  There's more to a compiler than it's
runtime libraries.

Re: [OMPI users] OpenMPI Run-Time "Freedom" Question

[Michael E. Thomadakis]

 On 08/12/10 18:59, Tim Prince wrote:

On 8/12/2010 3:27 PM, Ralph Castain wrote:
Ick - talk about confusing! I suppose there must be -some- rational 
reason why someone would want to do this, but I can't imagine what it 
would be


I'm no expert on compiler vs lib confusion, but some of my own 
experience would say that this is a bad idea regardless of whether or 
not OMPI is involved. Compiler version interoperability is usually 
questionable, depending upon how far apart the rev levels are.


Only answer I can offer is that you would have to try it. It will 
undoubtedly be a case-by-case basis: some combinations might work, 
others might fail.



On Aug 12, 2010, at 3:53 PM, Michael E. Thomadakis wrote:


Hello OpenMPI,

we have deployed OpenMPI 1.4.1 and 1.4.2 on our Intel Nehalem 
cluster using Intel compilers V 11.1.059 and 11.1.072 respectively, 
and one user has the following request:


Can we build OpenMPI version say O.1 against Intel compilers version 
say I.1 but  then built an application with OpenMPI O.1 BUT then use 
a DIFFERENT Intel compiler version say I.2 to built and run this MPI 
application?


I suggested to him to 1) simply try to built and run the application 
with O.1 but use Intel compilers version I.X whatever this X is and 
see if it has any issues.


OR 2) If the above does not work, I would build OpenMPI O.1 against 
Intel version I.X so he can use THIS combination for his 
hypothetical application.


He insists that I build OpenMPI O.1 with some version of Intel 
compilers I.Y but then at run time he would like to use *different* 
Intel run time libs at will I.Z <> I.X.


Can you provide me with a suggestion for a sane solution to this ? :-)

Best regards

Michael
Guessing at what is meant here, if you build MPI with a given version 
of Intel compilers, it ought to work when the application is built 
with a similar or more recent Intel compiler, or when the run-time 
LD_LIBRARY_PATH refers to a similar or newer library (within reason). 
There are similar constraints on glibc version.  "Within reason" works 
over a more restricted range when C++ is involved.  Note that the 
Intel linux compilers link to the gcc and glibc libraries as well as 
those which come with the compiler, and the MPI could be built with a 
combination of gcc and ifort to work with icc or gcc and ifort.  
gfortran and ifort libraries, however, are incompatible, except that 
libgomp calls can be supported by libiomp5.
The "rational" use I can see is that an application programmer would 
likely wish to test a range of compilers without rebuilding MPI.  
Intel documentation says there is forward compatibility testing of 
libraries, at least to the extent that a build made with 10.1 would 
work with 11.1 libraries.
The most recent Intel library compatibility break was between MKL 9 
and 10.




Dear Tim, I offered to provide myself the combination of OMPI+ Intel 
compilers so that application can use it in stable fashion. When I 
inquired about this application so I can look into this I was told that 
"there is NO application yet (!) that fails but just in case it fails 
..." I was asked to hack into the OMPI  building process to let OMPI use 
one run-time but then the MPI application using this OMPI ... use another!



Thanks for the information on this. We indeed use Intel Compiler set 
11.1.XXX + OMPI 1.4.1 and 1.4.2.


The basic motive in this hypothetical situation is to build the MPI 
application ONCE and then swap run-time libs as newer compilers come 
out I am certain that even if one can get away with it with nearby 
run-time versions there is no guarantee of the stability at-infinitum. I 
end up having to spent more time for technically "awkward" requests than 
the reasonable ones. Reminds me when I was a teacher I had to spent more 
time with all the people trying to avoid doing the work than with the 
good students... hmmm :-)



take care,,,
Mike



--
Tim Prince


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

Re: [OMPI users] OpenMPI Run-Time "Freedom" Question

[Michael E. Thomadakis]

 On 08/12/10 17:27, Ralph Castain wrote:
Ick - talk about confusing! I suppose there must be -some- rational 
reason why someone would want to do this, but I can't imagine what it 
would be


I'm no expert on compiler vs lib confusion, but some of my own 
experience would say that this is a bad idea regardless of whether or 
not OMPI is involved. Compiler version interoperability is usually 
questionable, depending upon how far apart the rev levels are.


Only answer I can offer is that you would have to try it. It will 
undoubtedly be a case-by-case basis: some combinations might work, 
others might fail.



On Aug 12, 2010, at 3:53 PM, Michael E. Thomadakis wrote:



Hi Ralph, I believe the clean and rational solution when an MPI 
Application needs a specific combination of OMPI and Intel Compilers is 
to just build this OMPI against that compiler version statically or 
dynamically so the application can just use it. I feel that the OMPI 
libs + run-time is intimate part of the run-time of the application. 
What people think they can do is to build only ONCE against the same 
OMPI but freely swap in and out any Intel library run-time w/o worries 
and without REBUILDING the application. Nothing in life is free though.

Thanks for the reply 


Michael



Hello OpenMPI,

we have deployed OpenMPI 1.4.1 and 1.4.2 on our Intel Nehalem cluster 
using Intel compilers V 11.1.059 and 11.1.072 respectively, and one 
user has the following request:


Can we build OpenMPI version say O.1 against Intel compilers version 
say I.1 but  then built an application with OpenMPI O.1 BUT then use 
a DIFFERENT Intel compiler version say I.2 to built and run this MPI 
application?


I suggested to him to 1) simply try to built and run the application 
with O.1 but use Intel compilers version I.X whatever this X is and 
see if it has any issues.


OR 2) If the above does not work, I would build OpenMPI O.1 against 
Intel version I.X so he can use THIS combination for his hypothetical 
application.


He insists that I build OpenMPI O.1 with some version of Intel 
compilers I.Y but then at run time he would like to use *different* 
Intel run time libs at will I.Z <> I.X.


Can you provide me with a suggestion for a sane solution to this ? :-)

Best regards

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



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

Re: [OMPI users] OpenMPI Run-Time "Freedom" Question

[Tim Prince]

On 8/12/2010 3:27 PM, Ralph Castain wrote:
Ick - talk about confusing! I suppose there must be -some- rational 
reason why someone would want to do this, but I can't imagine what it 
would be


I'm no expert on compiler vs lib confusion, but some of my own 
experience would say that this is a bad idea regardless of whether or 
not OMPI is involved. Compiler version interoperability is usually 
questionable, depending upon how far apart the rev levels are.


Only answer I can offer is that you would have to try it. It will 
undoubtedly be a case-by-case basis: some combinations might work, 
others might fail.



On Aug 12, 2010, at 3:53 PM, Michael E. Thomadakis wrote:


Hello OpenMPI,

we have deployed OpenMPI 1.4.1 and 1.4.2 on our Intel Nehalem cluster 
using Intel compilers V 11.1.059 and 11.1.072 respectively, and one 
user has the following request:


Can we build OpenMPI version say O.1 against Intel compilers version 
say I.1 but  then built an application with OpenMPI O.1 BUT then use 
a DIFFERENT Intel compiler version say I.2 to built and run this MPI 
application?


I suggested to him to 1) simply try to built and run the application 
with O.1 but use Intel compilers version I.X whatever this X is and 
see if it has any issues.


OR 2) If the above does not work, I would build OpenMPI O.1 against 
Intel version I.X so he can use THIS combination for his hypothetical 
application.


He insists that I build OpenMPI O.1 with some version of Intel 
compilers I.Y but then at run time he would like to use *different* 
Intel run time libs at will I.Z <> I.X.


Can you provide me with a suggestion for a sane solution to this ? :-)

Best regards

Michael
Guessing at what is meant here, if you build MPI with a given version of 
Intel compilers, it ought to work when the application is built with a 
similar or more recent Intel compiler, or when the run-time 
LD_LIBRARY_PATH refers to a similar or newer library (within reason). 
There are similar constraints on glibc version.  "Within reason" works 
over a more restricted range when C++ is involved.  Note that the Intel 
linux compilers link to the gcc and glibc libraries as well as those 
which come with the compiler, and the MPI could be built with a 
combination of gcc and ifort to work with icc or gcc and ifort.  
gfortran and ifort libraries, however, are incompatible, except that 
libgomp calls can be supported by libiomp5.
The "rational" use I can see is that an application programmer would 
likely wish to test a range of compilers without rebuilding MPI.  Intel 
documentation says there is forward compatibility testing of libraries, 
at least to the extent that a build made with 10.1 would work with 11.1 
libraries.

The most recent Intel library compatibility break was between MKL 9 and 10.



--
Tim Prince

Re: [OMPI users] OpenMPI Run-Time "Freedom" Question

[Ralph Castain]

Ick - talk about confusing! I suppose there must be -some- rational reason why 
someone would want to do this, but I can't imagine what it would be

I'm no expert on compiler vs lib confusion, but some of my own experience would 
say that this is a bad idea regardless of whether or not OMPI is involved. 
Compiler version interoperability is usually questionable, depending upon how 
far apart the rev levels are.

Only answer I can offer is that you would have to try it. It will undoubtedly 
be a case-by-case basis: some combinations might work, others might fail.


On Aug 12, 2010, at 3:53 PM, Michael E. Thomadakis wrote:

> Hello OpenMPI,
> 
> we have deployed OpenMPI 1.4.1 and 1.4.2 on our Intel Nehalem cluster using 
> Intel compilers V 11.1.059 and 11.1.072 respectively, and one user has the 
> following request:
> 
> Can we build OpenMPI version say O.1 against Intel compilers version say I.1 
> but  then built an application with OpenMPI O.1 BUT then use a DIFFERENT 
> Intel compiler version say I.2 to built and run this MPI application?
> 
> I suggested to him to 1) simply try to built and run the application with O.1 
> but use Intel compilers version I.X whatever this X is and see if it has any 
> issues. 
> 
> OR 2) If the above does not work, I would build OpenMPI O.1 against Intel 
> version I.X so he can use THIS combination for his hypothetical application. 
> 
> He insists that I build OpenMPI O.1 with some version of Intel compilers I.Y 
> but then at run time he would like to use different Intel run time libs at 
> will I.Z <> I.X. 
> 
> Can you provide me with a suggestion for a sane solution to this ? :-) 
> 
> Best regards
> 
> Michael
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

[OMPI users] OpenMPI Run-Time "Freedom" Question

[Michael E. Thomadakis]

 Hello OpenMPI,

we have deployed OpenMPI 1.4.1 and 1.4.2 on our Intel Nehalem cluster 
using Intel compilers V 11.1.059 and 11.1.072 respectively, and one user 
has the following request:


Can we build OpenMPI version say O.1 against Intel compilers version say 
I.1 but  then built an application with OpenMPI O.1 BUT then use a 
DIFFERENT Intel compiler version say I.2 to built and run this MPI 
application?


I suggested to him to 1) simply try to built and run the application 
with O.1 but use Intel compilers version I.X whatever this X is and see 
if it has any issues.


OR 2) If the above does not work, I would build OpenMPI O.1 against 
Intel version I.X so he can use THIS combination for his hypothetical 
application.


He insists that I build OpenMPI O.1 with some version of Intel compilers 
I.Y but then at run time he would like to use *different* Intel run time 
libs at will I.Z <> I.X.


Can you provide me with a suggestion for a sane solution to this ? :-)

Best regards

Michael

Re: [OMPI users] MPI_Bcast issue

[Jeff Squyres]

Dick / all --

I just had a phone call with Ralph Castain who has had some additional off-list 
mails with Randolph.  Apparently, none of us understand the model that is being 
used here.  There are also apparently some confidentiality issues involved such 
that it might be difficult to publicly state enough information to allow the 
open community to understand, diagnose, and fix the issue.  So I'm not quite 
sure how to proceed here -- I'm afraid that I don't have the time or resources 
for private problem resolution in an unorthodox situation like this.

For example, I was under the impression that PVM was solely being used as a 
launcher.  This is apparently not the case -- the original code is a PVM job 
that has been modified to eventually call MPI_INIT.  I don't know how much more 
I can say on this open list.

Hence, I'm throughly confused as to the model that is being used at this point. 
 I don't think I can offer any further help unless a small [non-PVM] example is 
provided to the community that can show the problem.

I also asked a bunch of questions in a prior post that would be helpful to have 
answered before going further.

Sorry!  :-(



On Aug 12, 2010, at 9:32 AM, Richard Treumann wrote:

> 
> You said  "separate MPI  applications doing 1 to > N broadcasts over PVM".  
> You do not mean you are using pvm_bcast though - right? 
> 
> If these N MPI applications are so independent that you could run one at a 
> time or run them on N different clusters and still get the result you want 
> (not the time to solution) then I cannot imagine how there could be cross 
> talk.   
> 
> I have been assuming that when you describe this as an NxN problem, you mean 
> there is some desired interaction among the N MPI worlds.   
> 
> If I have misunderstood and the N MPI worlds stared with N mpirun operations 
> under PVM are each semantically independent of the other (N-1) then I am 
> totally at a loss for an explanation. 
> 
>   
> Dick Treumann  -  MPI Team   
> IBM Systems & Technology Group
> Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
> Tele (845) 433-7846 Fax (845) 433-8363
> 
> 
> users-boun...@open-mpi.org wrote on 08/11/2010 08:59:16 PM:
> 
> > [image removed] 
> > 
> > Re: [OMPI users] MPI_Bcast issue 
> > 
> > Randolph Pullen 
> > 
> > to: 
> > 
> > Open MPI Users 
> > 
> > 08/11/2010 09:01 PM 
> > 
> > Sent by: 
> > 
> > users-boun...@open-mpi.org 
> > 
> > Please respond to Open MPI Users 
> > 
> > I (a single user) am running N separate MPI  applications doing 1 to
> > N broadcasts over PVM, each MPI application is started on each 
> > machine simultaneously by PVM - the reasons are back in the post history.
> > 
> > The problem is that they somehow collide - yes I know this should 
> > not happen, the question is why.
> > 
> > --- On Wed, 11/8/10, Richard Treumann  wrote: 
> > 
> > From: Richard Treumann 
> > Subject: Re: [OMPI users] MPI_Bcast issue
> > To: "Open MPI Users" 
> > Received: Wednesday, 11 August, 2010, 11:34 PM
> 
> > 
> > Randolf 
> > 
> > I am confused about using multiple, concurrent mpirun operations.  
> > If there are M uses of mpirun and each starts N tasks (carried out 
> > under pvm or any other way) I would expect you to have M completely 
> > independent MPI jobs with N tasks (processes) each.  You could have 
> > some root in each of the M MPI jobs do an MPI_Bcast to the other 
> > N-1) in that job but there is no way in MPI (without using 
> > accept.connect) to get tasks of job 0 to give data to tasks of jobs 
> > 1-(m-1). 
> > 
> > With M uses of mpirun, you have M worlds that are forever isolated 
> > from the other M-1 worlds (again, unless you do accept/connect) 
> > 
> > In what sense are you treating this as an single MxN application?   
> > ( I use M & N to keep them distinct. I assume if M == N, we have your case) 
> > 
> > 
> > Dick Treumann  -  MPI Team   
> > IBM Systems & Technology Group
> > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
> > Tele (845) 433-7846 Fax (845) 433-8363 
> > 
> > -Inline Attachment Follows-
> 
> > ___
> > users mailing list
> > us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/users 
> > 
> > 
> >  ___
> > users mailing list
> > us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/users___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI users] Separating output from multiple MPI processes

[Ralph Castain]

Check "mpirun -h" and you'll see options to do exactly that...specifically, you 
want -output-filename


On Aug 12, 2010, at 8:20 AM, Price, Brian M (N-KCI) wrote:

> All,
>  
> Is there a simple way (environment variable or flag) to separate the output 
> of each of my MPI processes into separate log files?
>  
> Thanks.
>  
> Brian Price
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

[OMPI users] Separating output from multiple MPI processes

[Price, Brian M (N-KCI)]

All,

Is there a simple way (environment variable or flag) to separate the output of 
each of my MPI processes into separate log files?

Thanks.

Brian Price

Re: [OMPI users] MPI_Bcast issue

[Richard Treumann]

You said  "separate MPI  applications doing 1 to > N broadcasts over PVM". 
 You do not mean you are using pvm_bcast though - right?

If these N MPI applications are so independent that you could run one at a 
time or run them on N different clusters and still get the result you want 
(not the time to solution) then I cannot imagine how there could be cross 
talk. 

I have been assuming that when you describe this as an NxN problem, you 
mean there is some desired interaction among the N MPI worlds. 

If I have misunderstood and the N MPI worlds stared with N mpirun 
operations under PVM are each semantically independent of the other (N-1) 
then I am totally at a loss for an explanation.


Dick Treumann  -  MPI Team 
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363


users-boun...@open-mpi.org wrote on 08/11/2010 08:59:16 PM:

> [image removed] 
> 
> Re: [OMPI users] MPI_Bcast issue
> 
> Randolph Pullen 
> 
> to:
> 
> Open MPI Users
> 
> 08/11/2010 09:01 PM
> 
> Sent by:
> 
> users-boun...@open-mpi.org
> 
> Please respond to Open MPI Users
> 
> I (a single user) am running N separate MPI  applications doing 1 to
> N broadcasts over PVM, each MPI application is started on each 
> machine simultaneously by PVM - the reasons are back in the post 
history.
> 
> The problem is that they somehow collide - yes I know this should 
> not happen, the question is why.
> 
> --- On Wed, 11/8/10, Richard Treumann  wrote:
> 
> From: Richard Treumann 
> Subject: Re: [OMPI users] MPI_Bcast issue
> To: "Open MPI Users" 
> Received: Wednesday, 11 August, 2010, 11:34 PM

> 
> Randolf 
> 
> I am confused about using multiple, concurrent mpirun operations. 
> If there are M uses of mpirun and each starts N tasks (carried out 
> under pvm or any other way) I would expect you to have M completely 
> independent MPI jobs with N tasks (processes) each.  You could have 
> some root in each of the M MPI jobs do an MPI_Bcast to the other 
> N-1) in that job but there is no way in MPI (without using 
> accept.connect) to get tasks of job 0 to give data to tasks of jobs 
1-(m-1). 
> 
> With M uses of mpirun, you have M worlds that are forever isolated 
> from the other M-1 worlds (again, unless you do accept/connect) 
> 
> In what sense are you treating this as an single MxN application? 
> ( I use M & N to keep them distinct. I assume if M == N, we have your 
case) 
> 
> 
> Dick Treumann  -  MPI Team 
> IBM Systems & Technology Group
> Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
> Tele (845) 433-7846 Fax (845) 433-8363
> 
> -Inline Attachment Follows-

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

Re: [OMPI users] How to program with openmpi under MFC?

[Shiqing Fan]

 Hi,

I couldn't get any clue. Could you please provide me a small VS solution 
together with source file? It might be easier if I can simply check the 
callstacks. BTW: please send me off-list if the file is too big. Thanks.



Shiqing

On 2010-8-12 1:20 PM, lyb wrote:

Hi,
Some other information supply. the function breaks at the 3rd ASSERT. 
Send you the picture. thanks



Hello,
 the message is,
Unhandle exception at 0x7835b701 (mfc80ud.dll) : 0xC005: conflit 
while read 0xf78e9e00.


thanks.


 Hi,

I personally haven't try to program MPI with MFC, but in principle 
it should work. What kind of error did you get, was there any error 
message? Thanks.


Shiqing



On 2010-8-12 9:13 AM, lyb wrote:

Hi,

I have a MFC project, and need to add mpi functions in it,  and  
choose openmpi.

but I  searched all of mail list ,  not. find the answer.

And I try to call mpi functions under MFC, as follows,

int ompi_test(int *argc, char **argv)
{
int rank, size;

MPI_Init(argc, );
MPI_Comm_rank(MPI_COMM_WORLD, );
MPI_Comm_size(MPI_COMM_WORLD, );
printf("Hello, world, I am %d of %d\n", rank, size);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();

return 0;
}
void CSchedulerDlg::OnBnClickedButton1()
{
ompi_test(NULL, NULL);
}

but break at MPI_Init(argc, );.

So what should I do?
Can anybody help me?

Thanks in advance.

Best Regards.



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











--
--
Shiqing Fan  http://www.hlrs.de/people/fan
High Performance Computing   Tel.: +49 711 685 87234
  Center Stuttgart (HLRS)Fax.: +49 711 685 65832
Address:Allmandring 30   email: f...@hlrs.de
70569 Stuttgart

Re: [OMPI users] Checkpointing mpi4py program

[Joshua Hursey]

Can you try this with the current trunk (r23587 or later)?

I just added a number of new features and bug fixes, and I would be interested 
to see if it fixes the problem. In particular I suspect that this might be 
related to the Init/Finalize bounding of the checkpoint region.

-- Josh

On Aug 10, 2010, at 2:18 PM,   
wrote:

> Josh
> 
> Please find attached is the python program that reproduces the hang that
> I described. Initial part of this file describes the prerequisite
> modules and the steps to reproduce the problem. Please let me know if
> you have any questions in reproducing the hang.
> 
> Please note that, if I add the following lines at the end of the program
> (in case sleep_time is True), the problem disappears ie; program resumes
> successfully after successful completion of checkpoint.
> # Add following lines at the end for sleep_time is True
> else:
>   time.sleep(0.1)
> # End of added lines
> 
> 
> Thanks a lot for your time in looking into this issue.
> 
> Regards
> Ananda
> 
> Ananda B Mudar, PMP
> Senior Technical Architect
> Wipro Technologies
> Ph: 972 765 8093
> ananda.mu...@wipro.com
> 
> 
> -Original Message-
> Date: Mon, 9 Aug 2010 16:37:58 -0400
> From: Joshua Hursey 
> Subject: Re: [OMPI users] Checkpointing mpi4py program
> To: Open MPI Users 
> Message-ID: <270bd450-743a-4662-9568-1fedfcc6f...@open-mpi.org>
> Content-Type: text/plain; charset=windows-1252
> 
> I have not tried to checkpoint an mpi4py application, so I cannot say
> for sure if it works or not. You might be hitting something with the
> Python runtime interacting in an odd way with either Open MPI or BLCR.
> 
> Can you attach a debugger and get a backtrace on a stuck checkpoint?
> That might show us where things are held up.
> 
> -- Josh
> 
> 
> On Aug 9, 2010, at 4:04 PM, 
>  wrote:
> 
>> Hi
>> 
>> I have integrated mpi4py with openmpi 1.4.2 that was built with BLCR
> 0.8.2. When I run ompi-checkpoint on the program written using mpi4py, I
> see that program doesn?t resume sometimes after successful checkpoint
> creation. This doesn?t occur always meaning the program resumes after
> successful checkpoint creation most of the time and completes
> successfully. Has anyone tested the checkpoint/restart functionality
> with mpi4py programs? Are there any best practices that I should keep in
> mind while checkpointing mpi4py programs?
>> 
>> Thanks for your time
>> -  Ananda
>> Please do not print this email unless it is absolutely necessary.
>> 
>> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any attachments.
>> 
>> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>> 
>> www.wipro.com
>> 
>> ___
>> users mailing list
>> us...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
> 
> 
> 
> 
> --
> 
> Message: 8
> Date: Mon, 9 Aug 2010 13:50:03 -0700
> From: John Hsu 
> Subject: Re: [OMPI users] deadlock in openmpi 1.5rc5
> To: Open MPI Users 
> Message-ID:
>   

Re: [OMPI users] Memory allocation error when linking with MPI libraries

[Nicolas Deladerriere]

building openmpi with option "--without-memory-manager" fix my problem.

What does it exactly imply to compile with this option ?
I guess all malloc use functions from libc instead of openmpi one, but does
it have an effect on performance or something else ?

Nicolas

2010/8/8 Nysal Jan 

> What interconnect are you using? Infiniband? Use
> "--without-memory-manager" option while building ompi in order to disable
> ptmalloc.
>
> Regards
> --Nysal
>
>
> On Sun, Aug 8, 2010 at 7:49 PM, Nicolas Deladerriere <
> nicolas.deladerri...@gmail.com> wrote:
>
>> Yes, I'am using 24G machine on 64 bit Linux OS.
>> If I compile without wrapper, I did not get any problems.
>>
>> It seems that when I am linking with openmpi, my program use a kind of
>> openmpi implemented malloc. Is it possible to switch it off in order ot only
>> use malloc from libc ?
>>
>> Nicolas
>>
>> 2010/8/8 Terry Frankcombe 
>>
>> You're trying to do a 6GB allocate.  Can your underlying system handle
>>> that?  IF you compile without the wrapper, does it work?
>>>
>>> I see your executable is using the OMPI memory stuff.  IIRC there are
>>> switches to turn that off.
>>>
>>>
>>> On Fri, 2010-08-06 at 15:05 +0200, Nicolas Deladerriere wrote:
>>> > Hello,
>>> >
>>> > I'am having an sigsegv error when using simple program compiled and
>>> > link with openmpi.
>>> > I have reproduce the problem using really simple fortran code. It
>>> > actually does not even use MPI, but just link with mpi shared
>>> > libraries. (problem does not appear when I do not link with mpi
>>> > libraries)
>>> >% cat allocate.F90
>>> >program test
>>> >implicit none
>>> >integer, dimension(:), allocatable :: z
>>> >integer(kind=8) :: l
>>> >
>>> >write(*,*) "l ?"
>>> >read(*,*) l
>>> >
>>> >ALLOCATE(z(l))
>>> >z(1) = 111
>>> >z(l) = 222
>>> >DEALLOCATE(z)
>>> >
>>> >end program test
>>> >
>>> > I am using openmpi 1.4.2 and gfortran for my tests. Here is the
>>> > compilation :
>>> >
>>> >% ./openmpi-1.4.2/build/bin/mpif90 --showme -g -o testallocate
>>> > allocate.F90
>>> >gfortran -g -o testallocate allocate.F90
>>> > -I/s0/scr1/TOMOT_19311_HAL_/openmpi-1.4.2/build/include -pthread
>>> > -I/s0/scr1/TOMOT_19311_HAL_/openmpi-1.4.2/build/lib
>>> > -L/s0/scr1/TOMOT_19311_HAL_/openmpi-1.4.2/build/lib -lmpi_f90
>>> > -lmpi_f77 -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl
>>> > -lutil -lm -ldl -pthread
>>> >
>>> > When I am running that test with different length, I sometimes get a
>>> > "Segmentation fault" error. Here are two examples using two specific
>>> > values, but error happens for many other values of length (I did not
>>> > manage to find which values of lenght gives that error)
>>> >
>>> >%  ./testallocate
>>> > l ?
>>> >16
>>> >Segmentation fault
>>> >% ./testallocate
>>> > l ?
>>> >20
>>> >
>>> > I used debugger with re-compiled version of openmpi using debug flag.
>>> > I got the folowing error in function sYSMALLOc
>>> >
>>> >Program received signal SIGSEGV, Segmentation fault.
>>> >0x2b70b3b3 in sYSMALLOc (nb=640016, av=0x2b930200)
>>> > at malloc.c:3239
>>> >3239set_head(remainder, remainder_size | PREV_INUSE);
>>> >Current language:  auto; currently c
>>> >(gdb) bt
>>> >#0  0x2b70b3b3 in sYSMALLOc (nb=640016,
>>> > av=0x2b930200) at malloc.c:3239
>>> >#1  0x2b70d0db in opal_memory_ptmalloc2_int_malloc
>>> > (av=0x2b930200, bytes=64) at malloc.c:4322
>>> >#2  0x2b70b773 in opal_memory_ptmalloc2_malloc
>>> > (bytes=64) at malloc.c:3435
>>> >#3  0x2b70a665 in opal_memory_ptmalloc2_malloc_hook
>>> > (sz=64, caller=0x2bf8534d) at hooks.c:667
>>> >#4  0x2bf8534d in _gfortran_internal_free ()
>>> > from /usr/lib64/libgfortran.so.1
>>> >#5  0x00400bcc in MAIN__ () at allocate.F90:11
>>> >#6  0x00400c4e in main ()
>>> >(gdb) display
>>> >(gdb) list
>>> >3234  if ((unsigned long)(size) >= (unsigned long)(nb +
>>> > MINSIZE)) {
>>> >3235remainder_size = size - nb;
>>> >3236remainder = chunk_at_offset(p, nb);
>>> >3237av->top = remainder;
>>> >3238set_head(p, nb | PREV_INUSE | (av != _arena ?
>>> > NON_MAIN_ARENA : 0));
>>> >3239set_head(remainder, remainder_size | PREV_INUSE);
>>> >3240check_malloced_chunk(av, p, nb);
>>> >3241return chunk2mem(p);
>>> >3242  }
>>> >3243
>>> >
>>> >
>>> > I also did the same test in C and I got the same problem.
>>> >
>>> > Does someone has any idea that could help me understand what's going
>>> > on ?
>>> >
>>> > Regards
>>> > Nicolas
>>> >
>>> > ___
>>> > users mailing list
>>> > us...@open-mpi.org
>>> > 

Re: [OMPI users] Hyper-thread architecture effect on MPI jobs

[Saygin Arkan]

Hi again,

I think the problem is solved. Thanks to Gus, I've tried
mpirun -mca mpi_paffinity_alone 1
while running the program, and I've made a quick search on that, it assures
that every program works on a specific core I guess.
(correct me if I'm wrong).
I've ran over 20 tests, and now it works fine.

Thanks a lot,

Saygin

On Thu, Aug 12, 2010 at 11:39 AM, Saygin Arkan  wrote:

> Hi Gus,
>
> 1 - first of all, turning off hyper-threading is not an option. And it
> gives pretty good results if I can find a way to arrange the cores.
>
> 2 - Actually Eugene (one of her messages in this thread) had suggested to
> arrange the slots.
> I did and wrote the results, it delivers the cores randomly, nothing
> changed.
> but I haven't checked loadbalance option. -byslot or -bynode is not gonna
> help.
>
> 3 - Could you give me a bit more detail how affinity works? or what it does
> actually?
>
> Thanks a lot for your suggestions
>
> Saygin
>
>
> On Wed, Aug 11, 2010 at 6:18 PM, Gus Correa  wrote:
>
>> Hi Saygin
>>
>> You could:
>>
>> 1) turn off hyperthreading (on BIOS), or
>>
>> 2) use the mpirun options (you didn't send your mpirun command)
>> to distribute the processes across the nodes, cores, etc.
>> "man mpirun" is a good resource, see the explanations about
>> the -byslot, -bynode, -loadbalance options.
>>
>> 3) In addition, you can use the mca parameters to set processor affinity
>> in the mpirun command line "mpirun -mca mpi_paffinity_alone 1 ..."
>> I don't know how this will play in a hyperthreaded machine,
>> but it works fine in our dual processor quad-core computers
>> (not hyperthreaded).
>>
>> Depending on your code, hyperthreading may not help performance anyway.
>>
>> I hope this helps,
>> Gus Correa
>>
>> Saygin Arkan wrote:
>>
>>> Hello,
>>>
>>> I'm running mpi jobs in non-homogeneous cluster. 4 of my machines have
>>> the following properties, os221, os222, os223, os224:
>>>
>>> vendor_id   : GenuineIntel
>>> cpu family  : 6
>>> model   : 23
>>> model name  : Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz
>>> stepping: 7
>>> cache size  : 3072 KB
>>> physical id : 0
>>> siblings: 4
>>> core id : 3
>>> cpu cores   : 4
>>> fpu : yes
>>> fpu_exception   : yes
>>> cpuid level : 10
>>> wp  : yes
>>> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
>>> nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx
>>> est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
>>> bogomips: 4999.40
>>> clflush size: 64
>>> cache_alignment : 64
>>> address sizes   : 36 bits physical, 48 bits virtual
>>>
>>> and the problematic, hyper-threaded 2 machines are as follows, os228 and
>>> os229:
>>>
>>> vendor_id   : GenuineIntel
>>> cpu family  : 6
>>> model   : 26
>>> model name  : Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz
>>> stepping: 5
>>> cache size  : 8192 KB
>>> physical id : 0
>>> siblings: 8
>>> core id : 3
>>> cpu cores   : 4
>>> fpu : yes
>>> fpu_exception   : yes
>>> cpuid level : 11
>>> wp  : yes
>>> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
>>> nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl
>>> vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm ida
>>> bogomips: 5396.88
>>> clflush size: 64
>>> cache_alignment : 64
>>> address sizes   : 36 bits physical, 48 bits virtual
>>>
>>>
>>> The problem is: those 2 machines seem to be having 8 cores (virtually,
>>> actualy core number is 4).
>>> When I submit an MPI job, I calculated the comparison times in the
>>> cluster. I got strange results.
>>>
>>> I'm running the job on 6 nodes, 3 core per node. And sometimes ( I can
>>> say 1/3 of the tests) os228 or os229 returns strange results. 2 cores are
>>> slow (slower than the first 4 nodes) but the 3rd core is extremely fast.
>>>
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - RANK(0) Printing
>>> Times...
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os221 RANK(1)
>>>  :38 sec
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os222 RANK(2)
>>>  :38 sec
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os224 RANK(3)
>>>  :38 sec
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os228 RANK(4)
>>>  :37 sec
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os229 RANK(5)
>>>  :34 sec
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os223 RANK(6)
>>>  :38 sec
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os221 RANK(7)
>>>  :39 sec
>>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os222 RANK(8)
>>>  :37 sec
>>> 2010-08-05 14:30:58,926 50672 

Re: [OMPI users] How to program with openmpi under MFC?

[lyb]

Hi,
Some other information supply. the function breaks at the 3rd ASSERT. 
Send you the picture. thanks



Hello,
 the message is,
Unhandle exception at 0x7835b701 (mfc80ud.dll) : 0xC005: conflit 
while read 0xf78e9e00.


thanks.


 Hi,

I personally haven't try to program MPI with MFC, but in principle it 
should work. What kind of error did you get, was there any error 
message? Thanks.


Shiqing



On 2010-8-12 9:13 AM, lyb wrote:

Hi,

I have a MFC project, and need to add mpi functions in it,  and  
choose openmpi.

but I  searched all of mail list ,  not. find the answer.

And I try to call mpi functions under MFC, as follows,

int ompi_test(int *argc, char **argv)
{
int rank, size;

MPI_Init(argc, );
MPI_Comm_rank(MPI_COMM_WORLD, );
MPI_Comm_size(MPI_COMM_WORLD, );
printf("Hello, world, I am %d of %d\n", rank, size);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();

return 0;
}
void CSchedulerDlg::OnBnClickedButton1()
{
ompi_test(NULL, NULL);
}

but break at MPI_Init(argc, );.

So what should I do?
Can anybody help me?

Thanks in advance.

Best Regards.



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

Re: [OMPI users] How to program with openmpi under MFC?

[lyb]

Hello,
 the message is,
Unhandle exception at 0x7835b701 (mfc80ud.dll) : 0xC005: conflit 
while read 0xf78e9e00.


thanks.


 Hi,

I personally haven't try to program MPI with MFC, but in principle it 
should work. What kind of error did you get, was there any error 
message? Thanks.


Shiqing



On 2010-8-12 9:13 AM, lyb wrote:

Hi,

I have a MFC project, and need to add mpi functions in it,  and  
choose openmpi.

but I  searched all of mail list ,  not. find the answer.

And I try to call mpi functions under MFC, as follows,

int ompi_test(int *argc, char **argv)
{
int rank, size;

MPI_Init(argc, );
MPI_Comm_rank(MPI_COMM_WORLD, );
MPI_Comm_size(MPI_COMM_WORLD, );
printf("Hello, world, I am %d of %d\n", rank, size);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();

return 0;
}
void CSchedulerDlg::OnBnClickedButton1()
{
ompi_test(NULL, NULL);
}

but break at MPI_Init(argc, );.

So what should I do?
Can anybody help me?

Thanks in advance.

Best Regards.



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

Re: [OMPI users] Hyper-thread architecture effect on MPI jobs

[Saygin Arkan]

Hi Gus,

1 - first of all, turning off hyper-threading is not an option. And it gives
pretty good results if I can find a way to arrange the cores.

2 - Actually Eugene (one of her messages in this thread) had suggested to
arrange the slots.
I did and wrote the results, it delivers the cores randomly, nothing
changed.
but I haven't checked loadbalance option. -byslot or -bynode is not gonna
help.

3 - Could you give me a bit more detail how affinity works? or what it does
actually?

Thanks a lot for your suggestions

Saygin

On Wed, Aug 11, 2010 at 6:18 PM, Gus Correa  wrote:

> Hi Saygin
>
> You could:
>
> 1) turn off hyperthreading (on BIOS), or
>
> 2) use the mpirun options (you didn't send your mpirun command)
> to distribute the processes across the nodes, cores, etc.
> "man mpirun" is a good resource, see the explanations about
> the -byslot, -bynode, -loadbalance options.
>
> 3) In addition, you can use the mca parameters to set processor affinity
> in the mpirun command line "mpirun -mca mpi_paffinity_alone 1 ..."
> I don't know how this will play in a hyperthreaded machine,
> but it works fine in our dual processor quad-core computers
> (not hyperthreaded).
>
> Depending on your code, hyperthreading may not help performance anyway.
>
> I hope this helps,
> Gus Correa
>
> Saygin Arkan wrote:
>
>> Hello,
>>
>> I'm running mpi jobs in non-homogeneous cluster. 4 of my machines have the
>> following properties, os221, os222, os223, os224:
>>
>> vendor_id   : GenuineIntel
>> cpu family  : 6
>> model   : 23
>> model name  : Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz
>> stepping: 7
>> cache size  : 3072 KB
>> physical id : 0
>> siblings: 4
>> core id : 3
>> cpu cores   : 4
>> fpu : yes
>> fpu_exception   : yes
>> cpuid level : 10
>> wp  : yes
>> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
>> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
>> constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est
>> tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
>> bogomips: 4999.40
>> clflush size: 64
>> cache_alignment : 64
>> address sizes   : 36 bits physical, 48 bits virtual
>>
>> and the problematic, hyper-threaded 2 machines are as follows, os228 and
>> os229:
>>
>> vendor_id   : GenuineIntel
>> cpu family  : 6
>> model   : 26
>> model name  : Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz
>> stepping: 5
>> cache size  : 8192 KB
>> physical id : 0
>> siblings: 8
>> core id : 3
>> cpu cores   : 4
>> fpu : yes
>> fpu_exception   : yes
>> cpuid level : 11
>> wp  : yes
>> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
>> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
>> rdtscp lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx
>> est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm ida
>> bogomips: 5396.88
>> clflush size: 64
>> cache_alignment : 64
>> address sizes   : 36 bits physical, 48 bits virtual
>>
>>
>> The problem is: those 2 machines seem to be having 8 cores (virtually,
>> actualy core number is 4).
>> When I submit an MPI job, I calculated the comparison times in the
>> cluster. I got strange results.
>>
>> I'm running the job on 6 nodes, 3 core per node. And sometimes ( I can say
>> 1/3 of the tests) os228 or os229 returns strange results. 2 cores are slow
>> (slower than the first 4 nodes) but the 3rd core is extremely fast.
>>
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - RANK(0) Printing
>> Times...
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os221 RANK(1)
>>  :38 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os222 RANK(2)
>>  :38 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os224 RANK(3)
>>  :38 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os228 RANK(4)
>>  :37 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os229 RANK(5)
>>  :34 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os223 RANK(6)
>>  :38 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os221 RANK(7)
>>  :39 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os222 RANK(8)
>>  :37 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os224 RANK(9)
>>  :38 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os228 RANK(10)
>>  :*48 sec*
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os229 RANK(11)
>>  :35 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os223 RANK(12)
>>  :38 sec
>> 2010-08-05 14:30:58,926 50672 DEBUG [0x7fcadf98c740] - os221 RANK(13)
>>  :37 sec
>> 2010-08-05 14:30:58,926 50673 DEBUG [0x7fcadf98c740] - os222 RANK(14)
>>  :37 sec
>> 2010-08-05 14:30:58,926 50673 DEBUG [0x7fcadf98c740] - os224 RANK(15)
>> 

Re: [OMPI users] Hyper-thread architecture effect on MPI jobs

[Saygin Arkan]

for
...
rank 13=os221 slot=2
rank 14=os222 slot=2
rank 15=os224 slot=2
rank 16=os228 slot=4
rank 17=os229 slot=4

I've tried and here are the results, same thing happened.
2010-08-12 11:09:28,814 59759 DEBUG [0x7fbd3fdce740] - RANK(0) Printing
Times...
2010-08-12 11:09:28,814 59759 DEBUG [0x7fbd3fdce740] - os221 RANK(1):24
sec
2010-08-12 11:09:28,814 59759 DEBUG [0x7fbd3fdce740] - os222 RANK(2):27
sec
2010-08-12 11:09:28,814 59759 DEBUG [0x7fbd3fdce740] - os224 RANK(3):27
sec
2010-08-12 11:09:28,814 59759 DEBUG [0x7fbd3fdce740] - os228 RANK(4):41
sec
2010-08-12 11:09:28,814 59759 DEBUG [0x7fbd3fdce740] - os229 RANK(5):42
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os223 RANK(6):27
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os221 RANK(7):28
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os222 RANK(8):22
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os224 RANK(9):22
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os228 RANK(10):*40
sec*
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os229 RANK(11):24
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os223 RANK(12):26
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os221 RANK(13):28
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os222 RANK(14):27
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os224 RANK(15):27
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os228 RANK(16):19
sec
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - os229 RANK(17):*43
sec*
2010-08-12 11:09:28,815 59759 DEBUG [0x7fbd3fdce740] - TOTAL CORRELATION
TIME: 43 sec

for
...
rank 12=os223 slot=2
rank 13=os221 slot=2
rank 14=os222 slot=2
rank 15=os224 slot=2
rank 16=os228 slot=2
rank 17=os229 slot=2

here are the results
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os221 RANK(1):23
sec
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os222 RANK(2):23
sec
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os224 RANK(3):24
sec
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os228 RANK(4):20
sec
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os229 RANK(5):20
sec
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os223 RANK(6):24
sec
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os221 RANK(7):23
sec
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os222 RANK(8):22
sec
2010-08-12 11:19:33,916 54609 DEBUG [0x7f22881b5740] - os224 RANK(9):22
sec
2010-08-12 11:19:33,917 54609 DEBUG [0x7f22881b5740] - os228 RANK(10):19
sec
2010-08-12 11:19:33,917 54609 DEBUG [0x7f22881b5740] - os229 RANK(11):*35
sec*
2010-08-12 11:19:33,917 54609 DEBUG [0x7f22881b5740] - os223 RANK(12):23
sec
2010-08-12 11:19:33,917 54609 DEBUG [0x7f22881b5740] - os221 RANK(13):23
sec
2010-08-12 11:19:33,917 54609 DEBUG [0x7f22881b5740] - os222 RANK(14):23
sec
2010-08-12 11:19:33,917 54609 DEBUG [0x7f22881b5740] - os224 RANK(15):23
sec
2010-08-12 11:19:33,917 54609 DEBUG [0x7f22881b5740] - os228 RANK(16):19
sec
2010-08-12 11:19:33,917 54609 DEBUG [0x7f22881b5740] - os229 RANK(17):*37
sec*

Again the same thing happened. I also tried to give the slots 0, 3, 7 and
some other combinations, but it didn't change the result. Sometimes it gave
pretty normal, then I got some strange ones again.
*I guess specifiying the slot number doesn't affect the BIOS rank
choice.*The last test was as follows:

2010-08-12 11:25:02,599 55467 DEBUG [0x7f15af87a740] - os221 RANK(1):24
sec
2010-08-12 11:25:02,599 55467 DEBUG [0x7f15af87a740] - os222 RANK(2):23
sec
2010-08-12 11:25:02,599 55467 DEBUG [0x7f15af87a740] - os224 RANK(3):23
sec
*2010-08-12 11:25:02,599 55467 DEBUG [0x7f15af87a740] - os228 RANK(4):40
sec*
2010-08-12 11:25:02,599 55467 DEBUG [0x7f15af87a740] - os229 RANK(5):20
sec
2010-08-12 11:25:02,599 55467 DEBUG [0x7f15af87a740] - os223 RANK(6):24
sec
2010-08-12 11:25:02,599 55467 DEBUG [0x7f15af87a740] - os221 RANK(7):24
sec
2010-08-12 11:25:02,599 55467 DEBUG [0x7f15af87a740] - os222 RANK(8):22
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os224 RANK(9):22
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os228 RANK(10):20
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os229 RANK(11):21
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os223 RANK(12):23
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os221 RANK(13):24
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os222 RANK(14):24
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os224 RANK(15):23
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os228 RANK(16):38
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - os229 RANK(17):21
sec
2010-08-12 11:25:02,599 55468 DEBUG [0x7f15af87a740] - TOTAL CORRELATION
TIME: 40 

Re: [OMPI users] How to program with openmpi under MFC?

[Shiqing Fan]

 Hi,

I personally haven't try to program MPI with MFC, but in principle it 
should work. What kind of error did you get, was there any error 
message? Thanks.


Shiqing



On 2010-8-12 9:13 AM, lyb wrote:

Hi,

I have a MFC project, and need to add mpi functions in it,  and  
choose openmpi.

but I  searched all of mail list ,  not. find the answer.

And I try to call mpi functions under MFC, as follows,

int ompi_test(int *argc, char **argv)
{
int rank, size;

MPI_Init(argc, );
MPI_Comm_rank(MPI_COMM_WORLD, );
MPI_Comm_size(MPI_COMM_WORLD, );
printf("Hello, world, I am %d of %d\n", rank, size);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();

return 0;
}
void CSchedulerDlg::OnBnClickedButton1()
{
ompi_test(NULL, NULL);
}

but break at MPI_Init(argc, );.

So what should I do?
Can anybody help me?

Thanks in advance.

Best Regards.



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




--
--
Shiqing Fan  http://www.hlrs.de/people/fan
High Performance Computing   Tel.: +49 711 685 87234
  Center Stuttgart (HLRS)Fax.: +49 711 685 65832
Address:Allmandring 30   email: f...@hlrs.de
70569 Stuttgart

[OMPI users] How to program with openmpi under MFC?

[lyb]

Hi,

I have a MFC project, and need to add mpi functions in it,  and  choose 
openmpi.

but I  searched all of mail list ,  not. find the answer.

And I try to call mpi functions under MFC, as follows,

int ompi_test(int *argc, char **argv)
{
int rank, size;

MPI_Init(argc, );
MPI_Comm_rank(MPI_COMM_WORLD, );
MPI_Comm_size(MPI_COMM_WORLD, );
printf("Hello, world, I am %d of %d\n", rank, size);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();

return 0;
}
void CSchedulerDlg::OnBnClickedButton1()
{
ompi_test(NULL, NULL);
}

but break at MPI_Init(argc, );.

So what should I do?
Can anybody help me?

Thanks in advance.

Best Regards.