R3.4 + OpenMPI 3.0.0 + Rmpi inside macOS – little bit of mess;) As usual, there are no easy solutions when it comes to R and mac;) First of all, I suggest to get clean, isolated copy of OpenMPI so you can be sure that your installation has no issues with mixed libs.

1. Openmpi There Are Not Enough Slots Available In The System Free
2. Openmpi There Are Not Enough Slots Available In The System Game

1. There are not enough slots available in the system to satisfy the 2 slots test-yaspgrid-yaspfactory-1d Either request fewer slots for your application, or make more slots available.
2. There are not enough slots available in the system to satisfy the 12 slots that were requested by the application: / Users / me / Library / app / executable Either request fewer slots for your application, or make more slots available for use. A 'slot' is the Open MPI term for an allocatable unit where we can launch a process.
3. $ mpirun -np 25 python -c 'print 'hey' - There are not enough slots available in the system to satisfy the 25 slots that were requested by the application: python Either request fewer slots for your application, or make more slots available for use.

Contributions and bug reports are welcome from anyone! Some of the bestfeatures in h5py, including thread support, dimension scales, and thescale-offset filter, came from user code contributions.

Since we use GitHub, the workflow will be familiar to many people.If you have questions about the process or about the details of implementingyour feature, always feel free to ask on the Google Groups list, eitherby emailing:

or via the web interface at:

Anyone can post to this list. Your first message will be approved by amoderator, so don’t worry if there’s a brief delay.

This guide is divided into three sections. The first describes how to filea bug report.

The second describes the mechanics ofhow to submit a contribution to the h5py project; for example, how tocreate a pull request, which branch to base your work on, etc.We assume you’re are familiar with Git, the version control system used by h5py.If not, here’s a great place to start.

Finally, we describe the various subsystems inside h5py, and givetechnical guidance as to how to implement your changes.

How to File a Bug Report¶

Bug reports are always welcome! The issue tracker is at:

If you’re unsure whether you’ve found a bug¶

Always feel free to ask on the mailing list (h5py at Google Groups).Discussions there are seen by lots of people and are archived by Google.Even if the issue you’re having turns out not to be a bug in the end, otherpeople can benefit from a record of the conversation.

By the way, nobody will get mad if you file a bug and it turns out to besomething else. That’s just how software development goes.

What to include¶

When filing a bug, there are two things you should include. The first isthe output of h5py.version.info:

The second is a detailed explanation of what went wrong. Unless the bugis really trivial, include code if you can, either via GitHub’sinline markup:

or by uploading a code sample to Github Gist.

How to Get Your Code into h5py¶

This section describes how to contribute changes to the h5py code base.Before you start, be sure to read the h5py license and contributoragreement in “license.txt”. You can find this in the source distribution,or view it online at the main h5py repository at GitHub.

The basic workflow is to clone h5py with git, make your changes in a topicbranch, and then create a pull request at GitHub asking to merge the changesinto the main h5py project.

Here are some tips to getting your pull requests accepted:

1. Let people know you’re working on something. This could mean posting acomment in an open issue, or sending an email to the mailing list. There’snothing wrong with just opening a pull request, but it might save you timeif you ask for advice first.
2. Keep your changes focused. If you’re fixing multiple issues, file multiplepull requests. Try to keep the amount of reformatting clutter small sothe maintainers can easily see what you’ve changed in a diff.
3. Unit tests are mandatory for new features. This doesn’t mean hundreds(or even dozens) of tests! Just enough to make sure the feature works asadvertised. The maintainers will let you know if more are needed.

Clone the h5py repository¶

The best way to do this is by signing in to GitHub and cloning theh5py project directly. You’ll end up with a new repository under youraccount; for example, if your username is yourname, the repositorywould be at http://github.com/yourname/h5py.

Then, clone your new copy of h5py to your local machine:

Create a topic branch for your feature¶

Check out a new branch for the bugfix or feature you’re writing:

The exact name of the branch can be anything you want. For bug fixes, oneapproach is to put the issue number in the branch name.

We develop all changes against the master branch.If we’re making a bugfix release, a bot will backport merged pull requests.

Implement the feature!¶

You can implement the feature as a number of small changes, or as one bigcommit; there’s no project policy. Double-check to make sure you’veincluded all your files; run gitstatus and check the output.

Run the tests¶

The easiest way to run the tests is withtox:

Write a release note¶

Changes which could affect people building and using h5py after the next releaseshould have a news entry. You don’t need to do this if your changes don’t affectusage, e.g. adding tests or correcting comments.

In the news/ folder, make a copy of TEMPLATE.rst named after your branch.Edit the new file, adding a sentence or two about what you’ve added or fixed.Commit this to git too.

News entries are merged into the what’s new documentsfor each release. They should allow someone to quickly understand what a newfeature is, or whether a bug they care about has been fixed. E.g.:

The Building h5py section is for changes which affect how people build h5pyfrom source. It’s not about how we make prebuilt wheels; changes to that whichmake a visible difference can go in New features or Bug fixes.

Add yourself to the author list¶

If it’s your first time to contribute to this project, you should add yourself intoauthor list and follow the format below:

Push your changes back and open a pull request¶

Push your topic branch back up to your GitHub clone:

Then, create a pull request based on your topic branch.

Work with the maintainers¶

Your pull request might be accepted right away. More commonly, the maintainerswill post comments asking you to fix minor things, like add a few tests, cleanup the style to be PEP-8 compliant, etc.

The pull request page also shows the results of building and testing themodified code on Travis and Appveyor CI and Azure Pipelines.Check back after about 30 minutes to see if the build succeeded,and if not, try to modify your changes to make it work.

When making changes after creating your pull request, just add commits toyour topic branch and push them to your GitHub repository. Don’t try torebase or open a new pull request! We don’t mind having a few extracommits in the history, and it’s helpful to keep all the history togetherin one place.

How to Modify h5py¶

This section is a little more involved, and provides tips on how to modifyh5py. The h5py package is built in layers. Starting from the bottom, theyare:

1. The HDF5 C API (provided by libhdf5)
2. Auto-generated Cython wrappers for the C API (api_gen.py)
3. Low-level interface, written in Cython, using the wrappers from (2)
4. High-level interface, written in Python, with things like h5py.File.
5. Unit test code

Rather than talk about the layers in an abstract way, the parts below areguides to adding specific functionality to various parts of h5py.Most sections span at least two or three of these layers.

Adding a function from the HDF5 C API¶

This is one of the most common contributed changes. The example below showshow one would add the function H5Dget_storage_size,which determines the space on disk used by an HDF5 dataset. This functionis already partially wrapped in h5py, so you can see how it works.

It’s recommended thatyou follow along, if not by actually adding the feature then by at leastopening the various files as we work through the example.

First, get ahold ofthe function signature; the easiest place for this is at the onlineHDF5 Reference Manual.Then, add the function’s C signature to the file api_functions.txt:

This particular signature uses types (hsize_t, hid_t) which are alreadydefined elsewhere. But ifthe function you’re adding needs a struct or enum definition, you canadd it using Cython code to the file api_types_hdf5.pxd.

The next step is to add a Cython function or method which calls the functionyou added. The h5py modules follow the naming conventionof the C API; functions starting with H5D are wrapped in h5d.pyx.

Opening h5d.pyx, we notice that since this function takes a datasetidentifier as the first argument, it belongs as a method on the DatasetIDobject. We write a wrapper method:

The first line of the docstring gives the method signature.This is necessary because Cython will use a “generic” signature likemethod(*args,**kwds) when the file is compiled. The h5py documentationsystem will extract the first line and use it as the signature.

Next, we decide whether we want to add access to this function to thehigh-level interface. That means users of the top-level h5py.Datasetobject will be able to see how much space on disk their files use. Thehigh-level interface is implemented in the subpackage h5py._hl, andthe Dataset object is in module dataset.py. Opening it up, we adda property on the Dataset object:

You’ll see that the low-level DatasetID object is available on thehigh-level Dataset object as obj.id. This is true of all thehigh-level objects, like File and Group as well.

Finally (and don’t skip this step), we write unit tests for this feature.Since the feature is ultimately exposed at the high-level interface, it’s OKto write tests for the Dataset.storagesize property only. Unit tests forthe high-level interface are located in the “tests” subfolder, right neardataset.py.

It looks like the right file is test_dataset.py. Unit tests areimplemented as methods on custom unittest.UnitTest subclasses;each new feature should be tested by its own new class. In thetest_dataset module, we see there’s already a subclass calledBaseDataset, which implements some simple set-up and cleanup methods andprovides a h5py.File object as obj.f. We’ll base our test class onthat:

This set of tests would be adequate to get a pull request approved. We don’ttest every combination under the sun (different ranks, datasets with morethan 2**32 elements, datasets with the string “kumquat” in the name…), butthe basic, commonly encountered set of conditions.

To build and test our changes, we have to do a few things. First of all,run the file api_gen.py to re-generate the Cython wrappers fromapi_functions.txt:

Then build the project, which recompiles h5d.pyx:

Finally, run the test suite, which includes the two methods we just wrote:

If the tests pass, the feature is ready for a pull request.

Adding a function only available in certain versions of HDF5¶

At the moment, h5py must be backwards-compatible all the way back toHDF5 1.8.4. Starting with h5py 2.2.0, it’s possible to conditionallyinclude functions which only appear in newer versions of HDF5. It’s alsopossible to mark functions which require Parallel HDF5. For example, thefunction H5Fset_mpi_atomicity was introduced in HDF5 1.8.9 and requiresParallel HDF5. Specifiers before the signature in api_functions.txtcommunicate this:

You can specify either, both or none of “MPI” or a version number in “X.Y.Z”format.

In the Cython code, these show up as “preprocessor” defines MPI andHDF5_VERSION. So the low-level implementation (as a method onh5py.h5f.FileID) looks like this:

High-level code can check the version of the HDF5 library, or check to see ifthe method is present on FileID objects.

Testing MPI-only features/code¶

Typically to run code under MPI, mpirun must be used to start the MPIprocesses. Similarly, tests using MPI features (such as collective IO), mustalso be run under mpirun. h5py uses pytest markers (specificallypytest.mark.mpi and other markers frompytest-mpi) to specify which testsrequire usage of mpirun, and will handle skipping the tests as needed. Asimple example of how to do this is:

To run these tests, you’ll need to:

1. Have tox installed (e.g. via pipinstalltox)
2. Have HDF5 built with MPI as per Building against Parallel HDF5

Then running:

should run the tests. You may need to pass HDF5_DIR depending on thelocation of the HDF5 with MPI support. You can choose which python version tobuild against by changing py37 (e.g. py36 runs python 3.6, this is a toxfeature), and test with the minimum version requirements by using mindepsrather than deps.

If you get an error similar to:

then you need to reduce the number of MPI processes you are asking MPI to use.If you have already reduced the number of processes requested (or are runningthe default number which is 2), you will need to look up the documentation foryour MPI implementation for handling this error. On OpenMPI (which is usuallythe default MPI implementation on most systems), running:

will instruct OpenMPI to allow more MPI processes than available cores on yoursystem.

If you need to pass additional environment variables to your MPI implementation,add these variables to the passenv setting in the tox.ini, and send us a PRwith that change noting the MPI implementation.

Overview

Cygwin provides a unix-like environment on a Windows machine, and emulates some of the functionality of a linux distribution. Downloads and more information on Cygwin is available at http://www.cygwin.com/. To compile and run SU2 in Cygwin on a Windows machine, you will need to configure Cygwin with the appropriate packages (listed below), and then continue from within Cygwin as though you were using a linux machine. In summary, the steps are:

1. Download Cygwin installer
2. Install Cygwin, selecting the packages necessary to compile the source code.
3. Download the source code into a directory within cygwin/
4. Install SU2 according to the directions for the linux installation.

Notes on installing Cygwin for first-time or beginner Cygwin users

Openmpi There Are Not Enough Slots Available In The System Free

• It is often recommended to install in a directory rather than the default C: location.
• The Cygwin shell will only be able to access folders that are within the cygwin directory; you will need to install and run SU2 inside the cygwin directory.

Cygwin packages

At the package selection step, search for the following terms and select the associated packages to install. This list is a work-in-progress, and further packages may be required or desired.

Openmpi There Are Not Enough Slots Available In The System Game

Basic

• g++, gcc compiler
• python: install the packages under the python sub-heading
• cpp: all debug, pre-processor, regular expression packages.

Example SU2 installation on WINDOWS 10 using 64-bit Cygwin

The CYGWIN bash shell is used for all steps on the command line. It is automatically available after the first installation step (typically to be launched via the CYGWIN desktop icon).

1. Install CYGWIN (64-bit version) and development packages

   • Download and run:

     Inside the Cygwin Setup GUI use C:cygwin64 for both Root Directory and Local Package Directory. Chose a Download Site close to you (also http mirrors often work better). Continue to complete the bare minimum installation. This will end with a desktop icon named Cygwin64 Terminal. Double-click this to open the shell and launch further commands from there.

     For detailed informations on how to install CYGWIN and selected packages see CYGWIN Installation.

   • Install development tools (dependencies on these packages will be automatically selected by CYGWIN)

     NOTE: A single command installing all required packages in one is given below this list

     1. General build environment tools
        • autoconf
        • autoconf2.5
        • autogen
        • automake
        • automake1.15
        • libtool
        • make
     2. Compilers
        • gcc-g++
        • mingw64-x86_64-gcc-core
        • mingw64-x86_64-gcc-g++
     3. Python
        • python37
        • python37-devel
        • python3-configobj
     4. OpenMPI
        • libopenmpi-devel
        • openmpi
     5. Miscellaneous
        • vim (or any other editor in order to be able to edit files)
        • rsh
        • wget (to be able to download from the command line)
        • zlib-devel

   • All-in-one installation of packages (after the initial minimum installation):

   NOTE: Prepend path to setup-x86_64.exe (depending where it has been downloaded)

2. Configure CYGWINs default mount point (optional, but following steps use a syntax relying on this)

3. Configure OpenMPI

   Because in OpenMPI the C++ interface was removed, the option -lmpi_cxx has to be removed from the linker defaults. We need to check if this option is contained in the wrapper control file. This depends on the installed OpenMPI libraries.

   Assuming the 64-bit CYGWIN is installed in C:cygwin64 and /etc/fstab has been modified as in the previous step:

   If the option is set, then the following lines would be the result of the above grepcommand:

   NOTE: If -lmpi_cxx was not found, skip the next step

   If this is the case, edit mpic++-wrapper-data.txt and remove the -lmpi_cxx options so that the respective lines look like this:

4. Set the Python version for the installation process (for permanent setting add this line to ~/.profile)

5. Get the SU2 source code:

   • Download following file for SU2 version 6.2.0

   • Extract files and change into the folder where the files were extracted to:

     NOTE: This is later the folder where the SU2_HOME variable points to

6. Run the utility for autoconf/automake toolchain setup:

7. Set compiler flags (just to be sure not to use the debug option -g)

8. Create Makefiles:

   NOTE: didn’t yet get tecio working, therefore disabled with --disable-tecio
   NOTE: Removed -DHAVE_EXECINFO_H from metis cppflags (potentially could be solved via gnulib)

9. Compile and link using:

10. Distribute executables, etc. to their intended locations:

11. Reduce size of executables significantly (strip symbols, see also CYGWIN FAQ 6.3. The SU2_CFD.exe is reduced from approx. 600MB to 15MB. Can be omitted if compiled with the -s option to gcc.

    NOTE: This should NOT be necessary if compiler flags are set as shown in step 7

12. Cleanup the installation. This removes also the intermediate big executables from the build folders.

13. Add the $SU2_HOME and $SU2_RUN environment variables to ~/.bashrc (and source ~/.bashrc)

14. Test serial and parallel versions:

    SERIAL command (due to the previous step SU2_CFD.exe should now be available in the path):

    PARALLEL command:Both mpirun and mpiexec do the same; mpiexec is recommended as the standard command.

    If more processes are requested than cores are available an error will be thrown:

    There are not enough slots available in the system.

    On WINDOWS this can be if hyperthreading is active. A system physically having 4 CPUs (cores), would show 8 CPUs in case of hyperthreading. Oversubscribe allows more processes than cores (which not necessarily is faster).