Re: openmpi versus mpich2
On Sun, Aug 7, 2011 at 11:07 PM, Rodolfo Aramayo raram...@gmail.com wrote: Basic question: Can these two ports be installed side by side: openmpi and mpich2 and which one is better for what purposes or are they equivalent in function and performance? --Thanks --R Provided mpich2 is not installed with +default (conflict is noted in variant description) the two should happily coexist. (I say *should* as I haven't tried it recently.) As to which is better... it depends. They both implement the MPI2 standard, so they both solve the same problem, in many respects. IMHO, OpenMPI is designed to provide lots of run-time adjustments, while MPICH2 tends to be more set at (mpich2) compile time. I'm sure you can find plenty of opinions online with a Google search. I prefer mpich2 as I use mvapich2 on other (linux-based Infiniband cluster) systems, which is itself based on mpich2. Good luck, Eric -- Eric A. Borisch (mpich2 port maintainer) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: openmpi versus mpich2
Coming from the world of high performance computing, MPICH2 and related variants (like mvapich2) tend to enjoy more support than OpenMPI due to performance considerations. I personally use mpich2 myself, but tend to compile my own MPIs, as the multiplicity can get you in trouble (if you link serial libraries to MPI code, you can run into lots of problems if the compiler version used to build the MPI libraries, and therefore the ones you're using to build the MPI code if you use mpicc/mpif90, is not the same as the compiler version you used to build the serial libraries). HTH, Jason On Mon, Aug 8, 2011 at 9:43 AM, Eric A. Borisch ebori...@macports.orgwrote: On Sun, Aug 7, 2011 at 11:07 PM, Rodolfo Aramayo raram...@gmail.com wrote: Basic question: Can these two ports be installed side by side: openmpi and mpich2 and which one is better for what purposes or are they equivalent in function and performance? --Thanks --R Provided mpich2 is not installed with +default (conflict is noted in variant description) the two should happily coexist. (I say *should* as I haven't tried it recently.) As to which is better... it depends. They both implement the MPI2 standard, so they both solve the same problem, in many respects. IMHO, OpenMPI is designed to provide lots of run-time adjustments, while MPICH2 tends to be more set at (mpich2) compile time. I'm sure you can find plenty of opinions online with a Google search. I prefer mpich2 as I use mvapich2 on other (linux-based Infiniband cluster) systems, which is itself based on mpich2. Good luck, Eric -- Eric A. Borisch (mpich2 port maintainer) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users -- Jason M. Swails Quantum Theory Project, University of Florida Ph.D. Candidate 352-392-4032 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: openmpi versus mpich2
On Mon, Aug 8, 2011 at 8:57 AM, Jason Swails jason.swa...@gmail.com wrote: I personally use mpich2 myself, but tend to compile my own MPIs, as the multiplicity can get you in trouble (if you link serial libraries to MPI code, you can run into lots of problems if the compiler version used to build the MPI libraries, and therefore the ones you're using to build the MPI code if you use mpicc/mpif90, is not the same as the compiler version you used to build the serial libraries). HTH, Jason FWIW, The mpich2 port supports a number of underlying compilers through the variants... Hopefully your favorite in the list. -Eric -- Eric A. Borisch ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
corrupted database
Hi, As my Lion freezes very often (https://discussions.apple.com/message/15676049#15676049) my MacPorts database got corrupted somehow during installation of gtk2 i guess. Now I can't continue to install any ports (log from installation of gtk2 below). This is obviously what is described here: https://svn.macports.org/ticket/24858 but I can't find any instruction how to recovery. Please help, MikieMike $ tail -n 100 /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gtk2/gtk2/main.log :debug:main Merging existing variants '' into variants :debug:main new fully merged portvariants: :debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/x11/xorg-libXcomposite :debug:main OS darwin/11.0.0 (Mac OS X 10.7) arch i386 :debug:main org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided :debug:main org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided :debug:main org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided :debug:main adding the default universal variant :debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf :debug:main No need to upgrade! xorg-libXcomposite 0.4.3_0 = xorg-libXcomposite 0.4.3_0 :debug:main epoch: in tree: 0 installed: 0 :debug:main xorg-compositeproto 0.4.2_0 exists in the ports tree :debug:main xorg-compositeproto 0.4.2_0 is the latest installed :debug:main xorg-compositeproto 0.4.2_0 is active :debug:main Merging existing variants '' into variants :debug:main new fully merged portvariants: :debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/x11/xorg-compositeproto :debug:main OS darwin/11.0.0 (Mac OS X 10.7) arch i386 :debug:main org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided :debug:main org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided :debug:main org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided :debug:main only one arch supported, so not adding the default universal variant :debug:main No need to upgrade! xorg-compositeproto 0.4.2_0 = xorg-compositeproto 0.4.2_0 :debug:main epoch: in tree: 0 installed: 0 :debug:main shared-mime-info 0.90_0 exists in the ports tree :debug:main shared-mime-info 0.90_0 is the latest installed :debug:main shared-mime-info 0.90_0 is active :debug:main Merging existing variants '' into variants :debug:main new fully merged portvariants: :debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/shared-mime-info :debug:main OS darwin/11.0.0 (Mac OS X 10.7) arch i386 :debug:main org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided :debug:main org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided :debug:main org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided :debug:main adding the default universal variant :debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf :debug:main No need to upgrade! shared-mime-info 0.90_0 = shared-mime-info 0.90_0 :msg:main --- Computing dependencies for gtk2:info:main .:debug:main Searching for dependency: atk :debug:main Found Dependency: receipt exists for atk :debug:main Searching for dependency: pango :debug:main Found Dependency: receipt exists for pango :debug:main Searching for dependency: gdk-pixbuf2 :debug:main Found Dependency: receipt exists for gdk-pixbuf2 :debug:main Searching for dependency: xorg-libXi :debug:main Found Dependency: receipt exists for xorg-libXi :debug:main Searching for dependency: xorg-libXrandr :debug:main Found Dependency: receipt exists for xorg-libXrandr :debug:main Searching for dependency: xorg-libXcursor :debug:main Found Dependency: receipt exists for xorg-libXcursor :debug:main Searching for dependency: xorg-libXinerama :debug:main Found Dependency: receipt exists for xorg-libXinerama :debug:main Searching for dependency: xorg-libXdamage :debug:main Found Dependency: receipt exists for xorg-libXdamage :debug:main Searching for dependency: xorg-libXcomposite :debug:main Found Dependency: receipt exists for xorg-libXcomposite :debug:main Searching for dependency: xorg-libXfixes :debug:main Found Dependency: receipt exists for xorg-libXfixes :debug:main Searching for dependency:
RE: Python frameworks
Or simpler for the user (perhaps) have an as_python option, the default (this would work for ipython, too), which would set the value based on the selected version of python, e.g. python2.7 - pylint-2.7 (or however it's written in the port select names) Russell ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
On Aug 6, 2011, at 11:20, mark brethen wrote: Would it be best to create a 'pylint' group and use port select? This would reflect the developer's viewpoint: I'm kind of reluctant to handle this in Spyder's code (of course, if it's the only way, we will take action anyway) because there is absolutely no reason for MacPorts to differentiate pylint scripts depending on Python minor version number: after all, this script is an executable that should behaves exactly the same way on any Python version. Of course this would make sense to differentiate pylint executable for Python 2 and Python 3. So the purist in me would tend to say that when pylint is properly installed, the command 'pylint' should work in a terminal. I understand the developer's viewpoint, but he is probably not aware of all of the complexities involving software packaging. We have multiple ports for spyder and pylint in MacPorts (for each of several versions of Python). These can be installed simultaneously, so they cannot install the same files. So none of these can install an executable /opt/local/bin/pylint. We could certainly entertain the idea of making the py*lint ports use the select portgroup, which you've requested here: https://trac.macports.org/ticket/30626 That would help users run pylint by that name, but it is not a solution for other software (like spyder) that wants to run pylint, for reasons explained in Joshua's comments in that ticket. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
On Aug 8, 2011, at 11:43, Russell Jones wrote: Or simpler for the user (perhaps) have an as_python option, the default (this would work for ipython, too), which would set the value based on the selected version of python, e.g. python2.7 - pylint-2.7 (or however it's written in the port select names) I don't understand this as_python suggestion. Are you suggesting that a port, such as py27-pylint, should install different contents (e.g. a pylint symlink, or not), depending on what python has been selected with sudo port select python? If so, I would be strongly against that. port select is exclusively for a user's convenience; no port should change how it installs or functions based on what the user may or may not have port selected. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: openmpi versus mpich2
The developer of the package I want to run (Velvet) told me I should just install 'libgomp' Can you guys translate this for me? Is he talking about openmpi or mpich2?? or something else?? Thanks On Mon, Aug 8, 2011 at 09:21, Eric A. Borisch ebori...@macports.org wrote: On Mon, Aug 8, 2011 at 8:57 AM, Jason Swails jason.swa...@gmail.com wrote: I personally use mpich2 myself, but tend to compile my own MPIs, as the multiplicity can get you in trouble (if you link serial libraries to MPI code, you can run into lots of problems if the compiler version used to build the MPI libraries, and therefore the ones you're using to build the MPI code if you use mpicc/mpif90, is not the same as the compiler version you used to build the serial libraries). HTH, Jason FWIW, The mpich2 port supports a number of underlying compilers through the variants... Hopefully your favorite in the list. -Eric -- Eric A. Borisch ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: openmpi versus mpich2
On Mon, Aug 8, 2011 at 2:19 PM, Rodolfo Aramayo raram...@gmail.com wrote: The developer of the package I want to run (Velvet) told me I should just install 'libgomp' Can you guys translate this for me? Is he talking about openmpi or mpich2?? or something else?? Something else. libgomp is the GNU implementation of the OpenMP parallelization scheme. Note that OpenMPI and mpich2 are both message passing interface (MPI) implementations designed for shared and distributed memory systems (oversimplified; multi-core computers and many multi-core computers networked together) by passing messages between the different threads. OpenMP is a shared memory parallelization scheme that has different syntax and design philosophy to MPI. OpenMP is (from what I've heard) simpler to write and implement than MPI, yet it is limited to shared-memory machines and thus cannot scale as high as MPI. However, if you're just trying to compile code that someone else has already written, you need to know which one they used to parallelize their code and link with those libraries. If the developer of the package you're trying to use says to install libgomp, then just do that (or some other OpenMP implementation if it's available) and leave MPI alone ;). Hope this helps, Jason Thanks On Mon, Aug 8, 2011 at 09:21, Eric A. Borisch ebori...@macports.org wrote: On Mon, Aug 8, 2011 at 8:57 AM, Jason Swails jason.swa...@gmail.com wrote: I personally use mpich2 myself, but tend to compile my own MPIs, as the multiplicity can get you in trouble (if you link serial libraries to MPI code, you can run into lots of problems if the compiler version used to build the MPI libraries, and therefore the ones you're using to build the MPI code if you use mpicc/mpif90, is not the same as the compiler version you used to build the serial libraries). HTH, Jason FWIW, The mpich2 port supports a number of underlying compilers through the variants... Hopefully your favorite in the list. -Eric -- Eric A. Borisch -- Jason M. Swails Quantum Theory Project, University of Florida Ph.D. Candidate 352-392-4032 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: openmpi versus mpich2
And we do no have a port for openmp;(( Thanks --R On Mon, Aug 8, 2011 at 13:25, Jason Swails jason.swa...@gmail.com wrote: On Mon, Aug 8, 2011 at 2:19 PM, Rodolfo Aramayo raram...@gmail.com wrote: The developer of the package I want to run (Velvet) told me I should just install 'libgomp' Can you guys translate this for me? Is he talking about openmpi or mpich2?? or something else?? Something else. libgomp is the GNU implementation of the OpenMP parallelization scheme. Note that OpenMPI and mpich2 are both message passing interface (MPI) implementations designed for shared and distributed memory systems (oversimplified; multi-core computers and many multi-core computers networked together) by passing messages between the different threads. OpenMP is a shared memory parallelization scheme that has different syntax and design philosophy to MPI. OpenMP is (from what I've heard) simpler to write and implement than MPI, yet it is limited to shared-memory machines and thus cannot scale as high as MPI. However, if you're just trying to compile code that someone else has already written, you need to know which one they used to parallelize their code and link with those libraries. If the developer of the package you're trying to use says to install libgomp, then just do that (or some other OpenMP implementation if it's available) and leave MPI alone ;). Hope this helps, Jason Thanks On Mon, Aug 8, 2011 at 09:21, Eric A. Borisch ebori...@macports.org wrote: On Mon, Aug 8, 2011 at 8:57 AM, Jason Swails jason.swa...@gmail.com wrote: I personally use mpich2 myself, but tend to compile my own MPIs, as the multiplicity can get you in trouble (if you link serial libraries to MPI code, you can run into lots of problems if the compiler version used to build the MPI libraries, and therefore the ones you're using to build the MPI code if you use mpicc/mpif90, is not the same as the compiler version you used to build the serial libraries). HTH, Jason FWIW, The mpich2 port supports a number of underlying compilers through the variants... Hopefully your favorite in the list. -Eric -- Eric A. Borisch -- Jason M. Swails Quantum Theory Project, University of Florida Ph.D. Candidate 352-392-4032 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python frameworks
With python27 port installed, and a reverse-engineered local portfile of py26-spyder, I was able to get spyder 2.0.12 running. I do not have multiple python frameworks installed on my mac. If I run python in a terminal window it uses: Mark-Brethens-MacBook-Pro:bin marbre$ python Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type help, copyright, credits or license for more information. Which is installed by the mac os. However, when I run spyder, it shows in its console: Python 2.7.2 (default, Aug 5 2011, 19:07:44) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type copyright, credits or license for more information. /opt/local/bin contains 'python2.7', which is a symbolic link of the same name as the binary it links to. Spyder's pylint widget searches PATH for 'pylint' but I have 'pylint-2.7' in /opt/local/bin, which is a symbolic link; it does not have the same name as the binary it links to. Spyder recognizes IPython even though the symlink in /opt/local/bin has a different name. I don't have an explanation for this. -Mark On Aug 8, 2011, at 11:48 AM, Ryan Schmidt wrote: On Aug 6, 2011, at 11:20, mark brethen wrote: Would it be best to create a 'pylint' group and use port select? This would reflect the developer's viewpoint: I'm kind of reluctant to handle this in Spyder's code (of course, if it's the only way, we will take action anyway) because there is absolutely no reason for MacPorts to differentiate pylint scripts depending on Python minor version number: after all, this script is an executable that should behaves exactly the same way on any Python version. Of course this would make sense to differentiate pylint executable for Python 2 and Python 3. So the purist in me would tend to say that when pylint is properly installed, the command 'pylint' should work in a terminal. I understand the developer's viewpoint, but he is probably not aware of all of the complexities involving software packaging. We have multiple ports for spyder and pylint in MacPorts (for each of several versions of Python). These can be installed simultaneously, so they cannot install the same files. So none of these can install an executable /opt/local/bin/pylint. We could certainly entertain the idea of making the py*lint ports use the select portgroup, which you've requested here: https://trac.macports.org/ticket/30626 That would help users run pylint by that name, but it is not a solution for other software (like spyder) that wants to run pylint, for reasons explained in Joshua's comments in that ticket. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
