Hi
What are the options "-deb64" and "-1" you are passing to mpirun:
> /usr/local/bin/mpirun -deb64 -1 connectivity_c 2>&1 | tee n=1.connectivity.out
I don't think these are legal options for mpirun (at least they don't
show up in `man mpirun`).
And i think you should add a "-n 4" (for 4 processors)
Furthermore, if you want to specify a host, you have to add "-host hostname1"
if you want to specify several hosts you have to add "-host
hostname1,hostname2,hostname3" (no spaces around the commas)
Jody
On Tue, Apr 7, 2009 at 11:39 AM, Francesco Pietra <chiendar...@gmail.com> wrote:
> Hi Gus:
> I should have set clear at the beginning that on the Zyxel router
> (connected to Internet by dynamic IP afforded by the provider) there
> are three computers. Their host names:
>
> deb32 (desktop debian i386)
>
> deb64 (multisocket debian amd 64 lenny)
>
> tya64 (multisocket debian amd 64 lenny)
>
> The three are ssh passwordless interconnected from the same user
> (myself). I never established connections as root user because I have
> direct access to all tree computers. So, if I slogin as user,
> passwordless connection is established. If I try to slogin as root
> user, it says that the authenticity of the host to which I intended to
> connect can't be established, RSA key fingerprint .. Connect?
>
> Moreover, I appended to the pub keys know to deb64 those that deb64
> had sent to either deb32 or tya64. Whereby, when i command.
>
> With certain programs (conceived for batch run), the execution on
> deb64 is launched from deb32.
>
> ssh 192.168.#.## date (where the numbers stand for hostname)
>
>
> I copied /examples to my deb64 home, chown to me, compiled as user and
> run as user "connectivity". (I have not compild in the openmpi
> directory as this is to root user, while ssh has been adjusted for me
> as user.
>
> Running as user in my home
>
> /usr/local/bin/mpirun -deb64 -1 connectivity_c 2>&1 | tee n=1.connectivity.out
>
> it asked to add the host (himself) to the list on known hosts (on
> repeating the command, that was no more asked). The unabridged output:
>
> ===========
> [deb64:03575] procdir: /tmp/openmpi-sessions-francesco@deb64_0/38647/0/0
> [deb64:03575] jobdir: /tmp/openmpi-sessions-francesco@deb64_0/38647/0
> [deb64:03575] top: openmpi-sessions-francesco@deb64_0
> [deb64:03575] tmp: /tmp
> [deb64:03575] mpirun: reset PATH:
> /usr/local/bin:/usr/local/mcce/bin:/opt/intel/cce/10.1.015/bin:/opt/intel/fce/10.1.015/bin:/home/francesco/gmmx06:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/local/amber10/exe:/usr/local/dock6/bin
> [deb64:03575] mpirun: reset LD_LIBRARY_PATH:
> /usr/local/lib:/opt/intel/mkl/10.0.1.014/lib/em64t:/opt/intel/cce/10.1.015/lib:/opt/intel/fce/10.1.015/lib:/usr/local/lib:/opt/acml4.1.0/gfortran64_mp_int64/lib
> [deb64:03583] procdir: /tmp/openmpi-sessions-francesco@deb64_0/38647/0/1
> [deb64:03583] jobdir: /tmp/openmpi-sessions-francesco@deb64_0/38647/0
> [deb64:03583] top: openmpi-sessions-francesco@deb64_0
> [deb64:03583] tmp: /tmp
> [deb64:03575] [[38647,0],0] node[0].name deb64 daemon 0 arch ffc91200
> [deb64:03575] [[38647,0],0] node[1].name deb64 daemon 1 arch ffc91200
> [deb64:03583] [[38647,0],1] node[0].name deb64 daemon 0 arch ffc91200
> [deb64:03583] [[38647,0],1] node[1].name deb64 daemon 1 arch ffc91200
> --------------------------------------------------------------------------
> mpirun was unable to launch the specified application as it could not
> find an executable:
>
> Executable: -e
> Node: deb64
>
> while attempting to start process rank 0.
> --------------------------------------------------------------------------
> [deb64:03575] sess_dir_finalize: job session dir not empty - leaving
> [deb64:03575] sess_dir_finalize: proc session dir not empty - leaving
> orterun: exiting with status -123
> [deb64:03583] sess_dir_finalize: job session dir not empty - leaving
> =========================
>
> I have changed the command, setting 4 for n and giving the full path
> to the executable "connectivity_c" at no avail. I do not understand
> the message "Executable: -e" in the out file and I feel myself stupid
> enough in this circumstance.
>
> The ssh is working for slogin and ssh to deb 64 date gives the date
> passwordless, both before and after the "connectivity" run. i.e.,
> deb64 knew, and knows, itself.
>
> The output of ompi_info between xxxxxxxxxx should probably clarify
> your other questions.
>
> xxxxxxxxxxxxxxxxxxx
> Package: Open MPI root@deb64 Distribution
> Open MPI: 1.3.1
> Open MPI SVN revision: r20826
> Open MPI release date: Mar 18, 2009
> Open RTE: 1.3.1
> Open RTE SVN revision: r20826
> Open RTE release date: Mar 18, 2009
> OPAL: 1.3.1
> OPAL SVN revision: r20826
> OPAL release date: Mar 18, 2009
> Ident string: 1.3.1
> Prefix: /usr/local
> Configured architecture: x86_64-unknown-linux-gnu
> Configure host: deb64
> Configured by: root
> Configured on: Fri Apr 3 23:03:30 CEST 2009
> Configure host: deb64
> Built by: root
> Built on: Fri Apr 3 23:12:28 CEST 2009
> Built host: deb64
> C bindings: yes
> C++ bindings: yes
> Fortran77 bindings: yes (all)
> Fortran90 bindings: yes
> Fortran90 bindings size: small
> C compiler: gcc
> C compiler absolute: /usr/bin/gcc
> C++ compiler: g++
> C++ compiler absolute: /usr/bin/g++
> Fortran77 compiler: /opt/intel/fce/10.1.015/bin/ifort
> Fortran77 compiler abs:
> Fortran90 compiler: /opt/intel/fce/10.1.015/bin/ifort
> Fortran90 compiler abs:
> C profiling: yes
> C++ profiling: yes
> Fortran77 profiling: yes
> Fortran90 profiling: yes
> C++ exceptions: no
> Thread support: posix (mpi: no, progress: no)
> Sparse Groups: no
> Internal debug support: no
> MPI parameter check: runtime
> Memory profiling support: no
> Memory debugging support: no
> libltdl support: yes
> Heterogeneous support: no
> mpirun default --prefix: no
> MPI I/O support: yes
> MPI_WTIME support: gettimeofday
> Symbol visibility support: yes
> FT Checkpoint support: no (checkpoint thread: no)
> MCA backtrace: execinfo (MCA v2.0, API v2.0, Component v1.3.1)
> MCA memory: ptmalloc2 (MCA v2.0, API v2.0, Component v1.3.1)
> MCA paffinity: linux (MCA v2.0, API v2.0, Component v1.3.1)
> MCA carto: auto_detect (MCA v2.0, API v2.0, Component v1.3.1)
> MCA carto: file (MCA v2.0, API v2.0, Component v1.3.1)
> MCA maffinity: first_use (MCA v2.0, API v2.0, Component v1.3.1)
> MCA maffinity: libnuma (MCA v2.0, API v2.0, Component v1.3.1)
> MCA timer: linux (MCA v2.0, API v2.0, Component v1.3.1)
> MCA installdirs: env (MCA v2.0, API v2.0, Component v1.3.1)
> MCA installdirs: config (MCA v2.0, API v2.0, Component v1.3.1)
> MCA dpm: orte (MCA v2.0, API v2.0, Component v1.3.1)
> MCA pubsub: orte (MCA v2.0, API v2.0, Component v1.3.1)
> MCA allocator: basic (MCA v2.0, API v2.0, Component v1.3.1)
> MCA allocator: bucket (MCA v2.0, API v2.0, Component v1.3.1)
> MCA coll: basic (MCA v2.0, API v2.0, Component v1.3.1)
> MCA coll: hierarch (MCA v2.0, API v2.0, Component v1.3.1)
> MCA coll: inter (MCA v2.0, API v2.0, Component v1.3.1)
> MCA coll: self (MCA v2.0, API v2.0, Component v1.3.1)
> MCA coll: sm (MCA v2.0, API v2.0, Component v1.3.1)
> MCA coll: sync (MCA v2.0, API v2.0, Component v1.3.1)
> MCA coll: tuned (MCA v2.0, API v2.0, Component v1.3.1)
> MCA io: romio (MCA v2.0, API v2.0, Component v1.3.1)
> MCA mpool: fake (MCA v2.0, API v2.0, Component v1.3.1)
> MCA mpool: rdma (MCA v2.0, API v2.0, Component v1.3.1)
> MCA mpool: sm (MCA v2.0, API v2.0, Component v1.3.1)
> MCA pml: cm (MCA v2.0, API v2.0, Component v1.3.1)
> MCA pml: ob1 (MCA v2.0, API v2.0, Component v1.3.1)
> MCA pml: v (MCA v2.0, API v2.0, Component v1.3.1)
> MCA bml: r2 (MCA v2.0, API v2.0, Component v1.3.1)
> MCA rcache: vma (MCA v2.0, API v2.0, Component v1.3.1)
> MCA btl: self (MCA v2.0, API v2.0, Component v1.3.1)
> MCA btl: sm (MCA v2.0, API v2.0, Component v1.3.1)
> MCA btl: tcp (MCA v2.0, API v2.0, Component v1.3.1)
> MCA topo: unity (MCA v2.0, API v2.0, Component v1.3.1)
> MCA osc: pt2pt (MCA v2.0, API v2.0, Component v1.3.1)
> MCA osc: rdma (MCA v2.0, API v2.0, Component v1.3.1)
> MCA iof: hnp (MCA v2.0, API v2.0, Component v1.3.1)
> MCA iof: orted (MCA v2.0, API v2.0, Component v1.3.1)
> MCA iof: tool (MCA v2.0, API v2.0, Component v1.3.1)
> MCA oob: tcp (MCA v2.0, API v2.0, Component v1.3.1)
> MCA odls: default (MCA v2.0, API v2.0, Component v1.3.1)
> MCA ras: slurm (MCA v2.0, API v2.0, Component v1.3.1)
> MCA rmaps: rank_file (MCA v2.0, API v2.0, Component v1.3.1)
> MCA rmaps: round_robin (MCA v2.0, API v2.0, Component v1.3.1)
> MCA rmaps: seq (MCA v2.0, API v2.0, Component v1.3.1)
> MCA rml: oob (MCA v2.0, API v2.0, Component v1.3.1)
> MCA routed: binomial (MCA v2.0, API v2.0, Component v1.3.1)
> MCA routed: direct (MCA v2.0, API v2.0, Component v1.3.1)
> MCA routed: linear (MCA v2.0, API v2.0, Component v1.3.1)
> MCA plm: rsh (MCA v2.0, API v2.0, Component v1.3.1)
> MCA plm: slurm (MCA v2.0, API v2.0, Component v1.3.1)
> MCA filem: rsh (MCA v2.0, API v2.0, Component v1.3.1)
> MCA errmgr: default (MCA v2.0, API v2.0, Component v1.3.1)
> MCA ess: env (MCA v2.0, API v2.0, Component v1.3.1)
> MCA ess: hnp (MCA v2.0, API v2.0, Component v1.3.1)
> MCA ess: singleton (MCA v2.0, API v2.0, Component v1.3.1)
> MCA ess: slurm (MCA v2.0, API v2.0, Component v1.3.1)
> MCA ess: tool (MCA v2.0, API v2.0, Component v1.3.1)
> MCA grpcomm: bad (MCA v2.0, API v2.0, Component v1.3.1)
> MCA grpcomm: basic (MCA v2.0, API v2.0, Component v1.3.1)
> xxxxxxxxxxxxxxxxxxxxxxxxxx
>
> thanks
> francesco
>
> On Mon, Apr 6, 2009 at 11:03 PM, Gus Correa <g...@ldeo.columbia.edu> wrote:
>> Hi Francesco
>>
>>
>> See answers inline.
>>
>> Francesco Pietra wrote:
>>>
>>> Hi Gus:
>>> Partial quick answers below. I have reestablished the ssh connection
>>> so that tomorrow I'll run the tests. Everything that relates to
>>> running amber is on the "parallel computer", where I have access to
>>> everything.
>>>
>>> On Mon, Apr 6, 2009 at 7:53 PM, Gus Correa <g...@ldeo.columbia.edu> wrote:
>>>>
>>>> Hi Francesco, list
>>>>
>>>> Francesco Pietra wrote:
>>>>>
>>>>> On Mon, Apr 6, 2009 at 5:21 PM, Gus Correa <g...@ldeo.columbia.edu>
>>>>> wrote:
>>>>>>
>>>>>> Hi Francesco
>>>>>>
>>>>>> Did you try to run examples/connectivity_c.c,
>>>>>> or examples/hello_c.c before trying amber?
>>>>>> They are in the directory where you untarred the OpenMPI tarball.
>>>>>> It is easier to troubleshoot
>>>>>> possible network and host problems
>>>>>> with these simpler programs.
>>>>>
>>>>> I have found the "examples". Should they be compiled? how? This is my
>>>>> only question here.
>>>>
>>>> cd examples/
>>>> /full/path/to/openmpi/bin/mpicc -o connectivity_c connectivity_c.c
>>>>
>>>> Then run it with, say:
>>>>
>>>> /full/path/to/openmpi/bin/mpirun -host {whatever_hosts_you_want}
>>>> -n {as_many_processes_you_want} connectivity_c
>>>>
>>>> Likewise for hello_c.c
>>>>
>>>>> What's below is info. Although amber parallel
>>>>> would have not compiled with faulty openmpi, I'll run openmpi tests as
>>>>> soon as I understand how.
>>>>>
>>>>>> Also, to avoid confusion,
>>>>>> you may use a full path name to mpirun,
>>>>>> in case you have other MPI flavors in your system.
>>>>>> Often times the mpirun your path is pointing to is not what you
>>>>>> may think it is.
>>>>>
>>>>> which mpirun
>>>>> /usr/local/bin/mpirun
>>>>
>>>> Did you install OpenMPI on /usr/local ?
>>>> When you do "mpirun -help", do you see "mpirun (Open MPI) 1.3"?
>>>
>>> mpirun -help
>>> mpirun (Open MPI) 1.3.1
>>> on the 1st line, then follow the options
>>
>> Ok, it looks like you installed OpenMPI 1.3.1 with the default
>> "--prefix" which is /usr/local.
>>
>>>
>>>
>>>> How about the output of "orte_info" ?
>>>
>>> orte_info was not installed. See below what has been installed.
>>>
>>
>> Sorry, my fault.
>> I meant ompi_info (not orte_info).
>> Please try ompi_info or "ompi_info --config".
>> It will tell you the compilers used to build OpenMPI, etc.
>>
>> I presume all of this is being done in the "parallel computer",
>> i.e., in one of the AMD64 Debian systems, right?
>>
>>>
>>>> Does it show your Intel compilers, etc?
>>>
>>> I guess so, otherwise amber would have not been compiled, but I don't
>>> know the commands to prove it. The intel compilers are on the path:
>>> /opt/intel/cce/10.1.015/bin:/opt/intel/fce/10.1.015/bin and the mkl
>>> are sourced in .bashrc.
>>>
>>
>> Again, all in the AMD64 system, right?
>>
>>>> I ask because many Linux distributions come with one or more flavors
>>>> of MPI (OpenMPI, MPICH, LAM, etc), some compilers also do (PGI for
>>>> instance), some tools (Intel MKL?) may also have their MPI,
>>>> and you end up with a bunch of MPI commands
>>>> on your path that may produce a big mixup.
>>>> This is a pretty common problem that affect new users on this list,
>>>> on the MPICH list, on clustering lists, etc.
>>>> The errors messages often don't help find the source of the problem,
>>>> and people spend a lot of time trying to troubleshoot network,
>>>> etc, when is often just a path problem.
>>>>
>>>> So, this is why when you begin, you may want to use full path
>>>> names, to avoid confusion.
>>>> After the basic MPI functionality is working,
>>>> then you can go and fix your path chain,
>>>> and rely on your path chain.
>>>>
>>>>> there is no other accessible MPI (one application, DOT2, has mpich but
>>>>> it is a static compilation; DOT2 parallelizatuion requires thar the
>>>>> computer knows itself, i.e." ssh hostname date" should afford the date
>>>>> passwordless. The reported issues in testing amber have destroyed this
>>>>> situation: now deb64 has port22 closed, evem to itself.
>>>>>
>>>> Have you tried to reboot the master node, to see if it comes back
>>>> to the original ssh setup?
>>>> You need ssh to be functional to run OpenMPI code,
>>>> including the tests above.
>>>>
>>>>>> I don't know if you want to run on amd64 alone (master node?)
>>>>>> or on a cluster.
>>>>>> In any case, you may use a list of hosts
>>>>>> or a hostfile on the mpirun command line,
>>>>>> to specify where you want to run.
>>>>>
>>>>> With amber I use the parallel computer directly and the amber
>>>>> installation is chown to me. The ssh connection, in this case, only
>>>>> serves to get file from. or send files to, my desktop.
>>>>>
>>>> It is unclear to me what you mean by "the parallel computer directly".
>>>> Can you explain better which computers are in this game?
>>>> Your desktop and a cluster perhaps?
>>>> Are they both Debian 64 Linux?
>>>> Where do you compile the programs?
>>>> Where do you want to run the programs?
>>>>
>>>>> In my .bashrc:
>>>>>
>>>>> (for amber)
>>>>> MPI_HOME=/usr/local
>>>>> export MPI_HOME
>>>>>
>>>>> (for openmpi)
>>>>> if [ "$LD_LIBRARY_PATH" ] ; then
>>>>> export LD_LIBRARY_PATH="$LD_LIBRARY_PATH'/usr/local/lib"
>>>>> else
>>>>> export LD_LIBRARY_PATH="/usr/local/lib"
>>>>> fi
>>>>>
>>>> Is this on your desktop or on the "parallel computer"?
>>>
>>>
>>> On both "parallel computers" (there is my desktop, ssh to two uma-type
>>> dual-opteron "parallel computers". Only one was active when the "test"
>>> problems arose. While the (ten years old) destop is i386, both other
>>> machines are amd64, i.e., all debian lenny. I prepare the input files
>>> on the i386 and use it also as storage for backups.
>>
>> So, you only use your i386 desktop to ssh to the AMD64 machine,
>> and to prepare input files, etc, right?
>> The OpenMPI installation, the compilations you do, and the job runs
>> all happen in the AMD64 system, right?
>>
>> BTW, do you use each of these systems separately on your
>> MPI program runs,
>> or do you use them together?
>> If you use them together, are they connected through a network,
>> and did you setup passowrdless ssh connections between them?
>>
>>> The "parallel
>>> computer" has only the X server and a minimal window for a
>>> two-dimensional graphics of amber.
>>
>> I don't know how amber works, so please tell me.
>> Do you somehow interact with amber while it is running in parallel mode,
>> using this "minimal window for a two dimensional graphics"?
>> Or is this only a data post-processing activity that happens after the
>> parallel run of amber finishes?
>>
>>> The other parallel computer has a
>>> GeForce 6600 card with GLSL support, which I use to elaborate
>>> graphically the outputs from the numerical computations (using VMD,
>>> Chimera and other 64 bit graphical programs).
>>>
>>>
>>>>> There is also
>>>>>
>>>>> MPICH_HOME=/usr/local
>>>>> export MPICH_HOME
>>>>>
>>>>> this is for DOCK, which, with this env variabl, accepts openmpi (at
>>>>> lest it was so with v 1.2.6)
>>>>>
>>>> Oh, well, it looks like there is MPICH already installed on /usr/local.
>>>> So, this may be part of the confusion, the path confusion I referred to.
>>>
>>> No, there is no MPICH installed. With the above export, DOCK (a
>>> docking program from the same developers of Amber) is so kind to use
>>> the executables of openmpi. The export was suggested by the DOCK
>>> developers, and it worked. Unable to explain why.
>>>
>>
>> OK, this may be a way the DOCK developers found to trick their own
>> software (DOCK) to think MPICH is installed in /usr/local,
>> and actually use the OpenMPI libraries instead of MPICH.
>> They may have hardwired on their build scripts the "MPICH_HOME"
>> environment variable as the location where the MPI libraries reside.
>> But which MPI libraries are there may not matter much, I would guess.
>> Just a guess anyway.
>> (I have no idea of what the heck DOCK is or how it works.)
>>
>>> As far as the parallel support is concerned, /usr/local/bin only
>>> contains what openmpi 1.3.1 has installed (resulting from ./configure
>>> cc=/path/icc cxx=/path/icpc F77=path/ifort FC=path/ifort
>>> --with-libnuma=/usr/lib):
>>> mpic++ mpicc mpiCC mpicc-vt mpiCC-vt mpic++-vt mpicxx mpicxx-vt
>>> mpiexec mpif77 mpif77-vt mpif90 mpif90-vt mpirun ompi-clean ompi-info
>>> ompi-ps ompi-server opal-wapper opari orte-clean orted orte-iof
>>> orte-ps orterun otfaux otfcompress otfconfig otfdecompress otfdump
>>> otfmerge vtcc vtcxx vtf77 vtf90 vtfilter vtunify. There is no
>>> orte_info.
>>>
>>
>> Of course not.
>> Doh! I misspelled the name ... :(
>> It is ompi_info for sure.
>>
>>>
>>>> I would suggest installing OpenMPI on a different directory,
>>>> using the --prefix option of the OpenMPI configure script.
>>>> Do configure --help for details about all configuration options.
>>>>
>>>>
>>>>> the intel compilers (compiled ifort and icc, are sourced in both my
>>>>> .bashrc and root home .bashrc.
>>>>>
>>>>> Thanks and apologies for my low level in these affairs. It is the
>>>>> first time I am faced by such problems, with amd64, same intel
>>>>> compilers, and openmpi 1.2.6 everything was in order.
>>>>>
>>>> To me it doesn't look like the problem is related to the new version
>>>> of OpenMPI.
>>>
>>> I asked about that because I am using the same commands, .bashrc, etc
>>> that worked with version 1.2.6. The computers are the same, the only
>>> (non minor) difference is upgrading from amd64 etch to amd64 lenny (or
>>> I am doing mistakes that I have not yet detected).
>>
>> Yes, but I still don't think it is some problem in OpenMPI 1.3.1 that is
>> causing trouble here.
>> If it were, the program would start running, but mpirun is having trouble
>> even to start the programs, right?
>>
>> Since you seem to have also upgraded the Debian release,
>> therefore another part of the system also changed.
>> But still, it may not be related to Debian either.
>> It may be just some confusion on paths, etc.
>>
>> I really encourage you to try to compile and run the programs in the
>> examples directory.
>> They are very clear and simple (as opposed to amber, which hides behind
>> a few layers of software), and even if they fail, the failure will help
>> clarify the nature of the problem, and find a fix.
>>
>> Oh, well, I am afraid I am asking more questions than helping out,
>> but I am trying to understand what is going on.
>>
>> Gus Correa
>>
>>>> Try the test programs with full path names first.
>>>> It may not solve the problem, but it may clarify things a bit.
>>>>
>>>> Gus Correa
>>>> ---------------------------------------------------------------------
>>>> Gustavo Correa
>>>> Lamont-Doherty Earth Observatory - Columbia University
>>>> Palisades, NY, 10964-8000 - USA
>>>> ---------------------------------------------------------------------
>>>>
>>>>> francesco
>>>>>
>>>>>
>>>>>
>>>>>> Do "/full/path/to/openmpi/bin/mpirun --help" for details.
>>>>>>
>>>>>> I am not familiar to amber, but how does it find your openmpi
>>>>>> libraries and compiler wrappers?
>>>>>> Don't you need to give it the paths during configuration,
>>>>>> say,
>>>>>> /configure_amber -openmpi=/full/path/to/openmpi
>>>>>> or similar?
>>>>>>
>>>>>> I hope this helps.
>>>>>> Gus Correa
>>>>>> ---------------------------------------------------------------------
>>>>>> Gustavo Correa
>>>>>> Lamont-Doherty Earth Observatory - Columbia University
>>>>>> Palisades, NY, 10964-8000 - USA
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Francesco Pietra wrote:
>>>>>>>
>>>>>>> I have compiled openmpi 1.3.1 on debian amd64 lenny with icc/ifort
>>>>>>> (10.1.015) and libnuma. Tests passed:
>>>>>>>
>>>>>>> ompi_info | grep libnuma
>>>>>>> MCA affinity: libnuma (MCA v 2.0, API 2.0)
>>>>>>>
>>>>>>> ompi_info | grep maffinity
>>>>>>> MCA affinity: first use (MCA as above)
>>>>>>> MCA affinity: libnuma as above.
>>>>>>>
>>>>>>> Then, I have compiled parallel a molecular dynamics package, amber10,
>>>>>>> without error signals but I am having problems in testing the amber
>>>>>>> parallel installation.
>>>>>>>
>>>>>>> amber10 configure was set as:
>>>>>>>
>>>>>>> ./configure_amber -openmpi -nobintray ifort
>>>>>>>
>>>>>>> just as I used before with openmpi 1.2.6. Could you say if the
>>>>>>> -openmpi should be changed?
>>>>>>>
>>>>>>> cd tests
>>>>>>>
>>>>>>> export DO_PARALLEL='mpirun -np 4'
>>>>>>>
>>>>>>> make test.parallel.MM < /dev/null
>>>>>>>
>>>>>>> cd cytosine && ./Run.cytosine
>>>>>>> The authenticity of host deb64 (which is the hostname) (127.0.1.1)
>>>>>>> can't be established.
>>>>>>> RSA fingerprint .....
>>>>>>> connecting ?
>>>>>>>
>>>>>>> I stopped the ssh daemon, whereby tests were interrupted because deb64
>>>>>>> (i.e., itself) could no more be accessed. Further attempts under these
>>>>>>> conditions failed for the same reason. Now, sshing to deb64 is no more
>>>>>>> possible: port 22 closed. In contrast, sshing from deb64 to other
>>>>>>> computers occurs passwordless. No such problems arose at the time of
>>>>>>> amd64 etch with the same
>>>>>>> configuration of ssh, same compilers, and openmpi 1.2.6.
>>>>>>>
>>>>>>> I am here because the warning from the amber site is that I should to
>>>>>>> learn how to use my installation of MPI. Therefore, if there is any
>>>>>>> clue ..
>>>>>>>
>>>>>>> thanks
>>>>>>> francesco pietra
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
