Skip to content

Commit 9f5fff1

Browse files
stigrjrobertodr
stigrj
and
robertodr
authored
Prepare v1.0.0 (#336)
* Fix MPI tests (#329) * Add missing electric field energy test * Add MPI launcher command to unit tests * Fix arch-flags * Fix mpi unit tests * Remove set_compile_flag.cmake * Fix integration test launcher * F**k it, let's run single proc, then * Use MPI_INT data type (MPI_INTEGER is Fortran) (#332) * Add build and test action (#334) * Add build and test action * Install Ninja too * Install nlohmann_json, disable arch flags * Clean docs (#323) * Clean docs * Move versioning scheme to CONTRIBUTING.md * Update tools * Update README installation * Remove Stallo tools Not consistent and soon redundant * Update MRCPP (#335) * Bump version 1.0.0 Co-authored-by: Roberto Di Remigio <[email protected]>
1 parent 2d9ce33 commit 9f5fff1

24 files changed

+321
-260
lines changed

‎.github/workflows/build-test.yml

+53
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
name: Build and test MRChem
2+
3+
on:
4+
push:
5+
branches:
6+
- master
7+
- release/*
8+
pull_request:
9+
branches:
10+
- master
11+
- release/*
12+
release:
13+
types:
14+
- created
15+
16+
env:
17+
BUILD_TYPE: Release
18+
19+
jobs:
20+
build:
21+
runs-on: ${{ matrix.os }}
22+
strategy:
23+
matrix:
24+
os: [ubuntu-latest, macos-latest]
25+
26+
steps:
27+
- uses: actions/checkout@v2
28+
29+
- name: Set up Python 3.6
30+
uses: actions/setup-python@v2
31+
with:
32+
python-version: 3.6
33+
34+
- name: Install dependencies
35+
run: |
36+
sudo chown -R $USER $CONDA
37+
$CONDA/bin/conda create --name mrchem python=3.6 eigen mrcpp xcfun nlohmann_json ninja -c conda-forge
38+
- name: Configure
39+
shell: bash
40+
run: |
41+
source $CONDA/bin/activate mrchem
42+
python ./setup --type=$BUILD_TYPE --omp --arch-flags=false --generator=Ninja --prefix=$GITHUB_WORKSPACE/Software/MRChem build --cmake-options="-DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DPYTHON_EXECUTABLE=$CONDA_PREFIX/bin/python"
43+
- name: Build
44+
shell: bash
45+
run: |
46+
source $CONDA/bin/activate mrchem
47+
cmake --build build --config $BUILD_TYPE --target install -- -v -d stats
48+
- name: Test
49+
shell: bash
50+
run: |
51+
cd build
52+
source $CONDA/bin/activate mrchem
53+
ctest -C $BUILD_TYPE --output-on-failure --verbose

‎CHANGELOG.md

+14
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,19 @@
11
# Change log
22

3+
## Version 1.0.0 2020-10-28
4+
5+
### Added
6+
7+
- Installation instructions to README
8+
9+
### Changed
10+
11+
- Updated MRCPP to v1.3.6
12+
13+
### Fixed
14+
15+
- Faulty MPI_INTEGER type
16+
317
## Version 1.0.0-alpha3 2020-10-10
418

519
### Added

‎CONTRIBUTING.md

+99
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
## Versioning scheme
2+
3+
This project adheres to a [semantic versioning scheme](https://semver.org/),
4+
with `MAJOR`.`MINOR`.`PATCH`-`LABEL`
5+
6+
- `MAJOR`: Introduces backward incompatible changes to the API
7+
- `MINOR`: Introduces new features without breaking backward compatibility
8+
- `PATCH`: Only simple bugfixes
9+
- `LABEL`: Marks a pre-released version or release candidate
10+
11+
We will try to keep only a *single* line of development on the `master`
12+
branch, and from this branch off to tag new releases. The type of release
13+
(`MAJOR` or `MINOR`) is determined by the nature of the introduced changes.
14+
`MAJOR` changes should not be introduced lightly, and could be held back at pull
15+
request-level in anticipation of prior `MINOR` release(s). Once a new `MAJOR` is
16+
released, the development on the old `MAJOR` is terminated and no `MINOR` pull
17+
requests will be accepted on top of old `MAJOR`s, only simple `PATCH`es.
18+
19+
## Branching model
20+
21+
In the following, X, Y and Z should *always* be substituted with appropriate
22+
numeric values, they should never appear as 'X', 'Y' or 'Z' in any version or
23+
branch name.
24+
25+
The upstream MRChemSoft/mrchem repository should contain only two kinds of
26+
branches: the `master` branch which represents the main development line, as
27+
well as a separate `release/X.Y` branch for each `MINOR` release. All `PATCH`
28+
releases are applied linearly on the `MINOR` release branches.
29+
30+
### The `master` branch:
31+
32+
<img src="doc/gfx/git-master.png" alt="drawing" width="600"/>
33+
34+
- This branch should *not* carry any release tags
35+
- New features should *always* be directed to this branch
36+
- Bugfixes may be directed to this branch
37+
- Bugfixes may be *cherry-picked* from `release` branches, but *never* merged
38+
- The VERSION file should point to the next *expected* release,
39+
and *always* carry the pre-release label `-alpha`
40+
- When a new `release/X.Y` branch is created, the VERSION file on `master`
41+
is bumped to the next expected `MAJOR`/`MINOR`, i.e. `X.(Y+1).0-alpha` or
42+
`(X+1).0.0-alpha`
43+
44+
### The `release/X.Y` branches:
45+
46+
<img src="doc/gfx/git-release.png" alt="drawing" width="530"/>
47+
48+
- This branch should carry *all* release tags associated with the `X.Y` `MINOR`
49+
release, including `PATCH`es and release candidates `-alpha1`, `-alpha2`, etc
50+
- The VERSION file should point to the *latest* release tag on this branch
51+
- The creation of this branch marks a feature freeze for version `X.Y`
52+
- New features should *never* be directed to this branch
53+
- Bugfixes and release preparations may be directed to this branch
54+
- Bugfixes may be *cherry-picked* from `master`, but *never* merged
55+
56+
## Contributing
57+
58+
All code changes are incorporated through the `fork -> pull request (PR) ->
59+
code review` work flow, with the following principles:
60+
61+
- New features should *always* branch off `master`
62+
- Bugfixes may branch off either `master` or `release/X.Y`
63+
- PRs should *always* be directed back at its original base branch, `master` or
64+
`release/X.Y`
65+
- Bugfixes should be small and specific (cherry-pickable)
66+
- Cherry-picks between `master` and `release` branches will be handled by code
67+
administrators
68+
- All version tagging and changes to the VERSION file will be handled by code
69+
administrators, and should *not* be part of any PR
70+
71+
### Contributing a new feature:
72+
73+
- Always start from latest `master`
74+
- Branch off to a local feature branch
75+
- Implement new feature
76+
- Regularly incorporate the latest changes from `master`, by merging or
77+
(preferably) rebasing
78+
- File PR from the local feature branch back to `master`
79+
80+
### Contributing a bugfix:
81+
82+
- Start from latest appropriate branch, `master` or `release/X.Y`
83+
- Branch off to a local bugfix branch
84+
- Implement bugfix
85+
- Regularly incorporate the latest changes from original branch by *rebasing*
86+
- File PR from the local bugfix branch back to original branch
87+
- Evaluate whether the bugfix should be cherry-picked to other branches
88+
and communicate it to the administrators
89+
90+
91+
## Automatic formatting
92+
93+
You can install Git hooks to keep in check formatting and licensing headers:
94+
95+
```
96+
cd .git/hooks
97+
ln -s ../../.githooks/* .
98+
```
99+

‎README.md

+71-98
Original file line numberDiff line numberDiff line change
@@ -17,102 +17,75 @@ Sciences at UiT - The Arctic University of Norway.
1717
### User support: [mrchem.slack.com](https://join.slack.com/t/mrchem/shared_invite/enQtNTI3MjMzNjM0NTk0LWNkODZjNTMwYmM4NmRmODExMjQzMDc3NThlMzNmNmIyNWQwM2YwOGY0OWY4NmNmNzE4ZmM2NzgxYzUzNDg3NDM)
1818
### Documentation: [mrchem.readthedocs.io](http://mrchem.readthedocs.io)
1919

20-
### Versioning scheme
21-
22-
This project adheres to a [semantic versioning scheme](https://semver.org/),
23-
with `MAJOR`.`MINOR`.`PATCH`-`LABEL`
24-
25-
- `MAJOR`: Introduces backward incompatible changes to the API
26-
- `MINOR`: Introduces new features without breaking backward compatibility
27-
- `PATCH`: Only simple bugfixes
28-
- `LABEL`: Marks a pre-released version or release candidate
29-
30-
We will try to keep only a *single* line of development on the `master`
31-
branch, and from this branch off to tag new releases. The type of release
32-
(`MAJOR` or `MINOR`) is determined by the nature of the introduced changes.
33-
`MAJOR` changes should not be introduced lightly, and could be held back at pull
34-
request-level in anticipation of prior `MINOR` release(s). Once a new `MAJOR` is
35-
released, the development on the old `MAJOR` is terminated and no `MINOR` pull
36-
requests will be accepted on top of old `MAJOR`s, only simple `PATCH`es.
37-
38-
### Branching model
39-
40-
In the following, X, Y and Z should *always* be substituted with appropriate
41-
numeric values, they should never appear as 'X', 'Y' or 'Z' in any version or
42-
branch name.
43-
44-
The upstream MRChemSoft/mrchem repository should contain only two kinds of
45-
branches: the `master` branch which represents the main development line, as
46-
well as a separate `release/X.Y` branch for each `MINOR` release. All `PATCH`
47-
releases are applied linearly on the `MINOR` release branches.
48-
49-
#### The `master` branch:
50-
51-
<img src="doc/gfx/git-master.png" alt="drawing" width="600"/>
52-
53-
- This branch should *not* carry any release tags
54-
- New features should *always* be directed to this branch
55-
- Bugfixes may be directed to this branch
56-
- Bugfixes may be *cherry-picked* from `release` branches, but *never* merged
57-
- The VERSION file should point to the next *expected* release,
58-
and *always* carry the pre-release label `-alpha`
59-
- When a new `release/X.Y` branch is created, the VERSION file on `master`
60-
is bumped to the next expected `MAJOR`/`MINOR`, i.e. `X.(Y+1).0-alpha` or
61-
`(X+1).0.0-alpha`
62-
63-
#### The `release/X.Y` branches:
64-
65-
<img src="doc/gfx/git-release.png" alt="drawing" width="530"/>
66-
67-
- This branch should carry *all* release tags associated with the `X.Y` `MINOR`
68-
release, including `PATCH`es and release candidates `-alpha1`, `-alpha2`, etc
69-
- The VERSION file should point to the *latest* release tag on this branch
70-
- The creation of this branch marks a feature freeze for version `X.Y`
71-
- New features should *never* be directed to this branch
72-
- Bugfixes and release preparations may be directed to this branch
73-
- Bugfixes may be *cherry-picked* from `master`, but *never* merged
74-
75-
### Contributing
76-
77-
All code changes are incorporated through the `fork -> pull request (PR) ->
78-
code review` work flow, with the following principles:
79-
80-
- New features should *always* branch off `master`
81-
- Bugfixes may branch off either `master` or `release/X.Y`
82-
- PRs should *always* be directed back at its original base branch, `master` or
83-
`release/X.Y`
84-
- Bugfixes should be small and specific (cherry-pickable)
85-
- Cherry-picks between `master` and `release` branches will be handled by code
86-
administrators
87-
- All version tagging and changes to the VERSION file will be handled by code
88-
administrators, and should *not* be part of any PR
89-
90-
#### Contributing a new feature:
91-
92-
- Always start from latest `master`
93-
- Branch off to a local feature branch
94-
- Implement new feature
95-
- Regularly incorporate the latest changes from `master`, by merging or
96-
(preferably) rebasing
97-
- File PR from the local feature branch back to `master`
98-
99-
#### Contributing a bugfix:
100-
101-
- Start from latest appropriate branch, `master` or `release/X.Y`
102-
- Branch off to a local bugfix branch
103-
- Implement bugfix
104-
- Regularly incorporate the latest changes from original branch by *rebasing*
105-
- File PR from the local bugfix branch back to original branch
106-
- Evaluate whether the bugfix should be cherry-picked to other branches
107-
and communicate it to the administrators
108-
109-
110-
### Automatic formatting
111-
112-
You can install Git hooks to keep in check formatting and licensing headers:
113-
114-
```
115-
cd .git/hooks
116-
ln -s ../../.githooks/* .
117-
```
20+
21+
## Installation
22+
23+
For optimal performance it is recommended to build from source, as the packaged
24+
builds are quite generic without architecture specific optimizations.
25+
26+
27+
### From source including code examples
28+
29+
To build MRChem from source with MPI+OpenMP parallelization:
30+
31+
$ git clone [email protected]:MRChemSoft/mrchem.git
32+
$ cd mrchem
33+
$ ./setup --prefix=<install-dir> --omp --mpi --cxx=<mpi-compiler> <build-dir>
34+
$ cd <build-dir>
35+
$ make
36+
$ make test
37+
$ make install
38+
39+
All dependencies will be fetched at configure time, if not already available.
40+
For more information on different kinds of builds, see
41+
[installation instructions](http://mrchem.readthedocs.io/en/latest/installation.html).
42+
43+
44+
### Using Conda
45+
46+
[![Anaconda-Server Badge](https://anaconda.org/conda-forge/mrchem/badges/version.svg)](https://anaconda.org/conda-forge/mrchem)
47+
[![Anaconda-Server Badge](https://anaconda.org/conda-forge/mrchem/badges/latest_release_date.svg)](https://anaconda.org/conda-forge/mrchem)
48+
[![Anaconda-Server Badge](https://anaconda.org/conda-forge/mrchem/badges/downloads.svg)](https://anaconda.org/conda-forge/mrchem)
49+
50+
To install MRChem in a Conda environment `myenv`:
51+
52+
$ conda create -n myenv
53+
$ conda activate myenv
54+
$ conda install -c conda-forge mrchem # latest version (OpenMP only)
55+
$ conda install -c conda-forge mrchem=1.0.0 # tagged version (OpenMP only)
56+
$ conda install -c conda-forge mrchem=*=*openmpi* # latest version (MPI+OpenMP)
57+
$ conda install -c conda-forge mrchem=*=*mpich* # latest version (MPI+OpenMP)
58+
59+
To list all available versions
60+
61+
$ conda search -c conda-forge mrchem
62+
63+
64+
### Using Spack
65+
66+
To install MRCPP in a Spack environment `myenv`:
67+
68+
$ spack env create myenv
69+
$ spack env activate myenv
70+
$ spack install mrchem # latest version (MPI+OpenMP)
71+
$ spack install mrchem @1.0.0 # tagged version (MPI+OpenMP)
72+
$ spack install mrchem -mpi # latest version (OpenMP only)
73+
74+
For information on available Spack builds:
75+
76+
$ spack info mrchem
77+
78+
79+
### Using EasyBuild
80+
81+
To install MRChem in an EasyBuild/Lmod environment (only MPI+OpenMP version
82+
available):
83+
84+
$ eb MRChem-<version>-<toolchain> --fetch
85+
$ eb MRChem-<version>-<toolchain> --robot
86+
$ module load MRChem/<version>-<toolchain>
87+
88+
See
89+
[EasyBuild](https://github.com/easybuilders/easybuild-easyconfigs/tree/develop/easybuild/easyconfigs/m/MRChem)
90+
for available `<versions>` and `<toolchains>`.
11891

‎VERSION

+1-1
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
1.0.0-alpha3
1+
1.0.0

‎cmake/compiler_flags/CXXFlags.cmake

+9-6
Original file line numberDiff line numberDiff line change
@@ -19,14 +19,17 @@ set(CMAKE_CXX_EXTENSIONS FALSE)
1919
set(CMAKE_EXPORT_COMPILE_COMMANDS TRUE)
2020

2121
if(ENABLE_ARCH_FLAGS)
22-
include(${CMAKE_CURRENT_LIST_DIR}/set_compiler_flag.cmake)
2322
# iterate over list of flags and use the first one that is compatible with the
2423
# compiler in use
25-
set_compiler_flag(_arch_flag
26-
FLAGS
27-
"-march=native" # valid wth GNU and probably Clang too
28-
"-xHost" # valid with Intel
29-
)
24+
if(CMAKE_CXX_COMPILER_ID MATCHES GNU)
25+
set(_arch_flag "-march=native")
26+
endif()
27+
if(CMAKE_CXX_COMPILER_ID MATCHES Clang)
28+
set(_arch_flag "-march=native")
29+
endif()
30+
if(CMAKE_CXX_COMPILER_ID MATCHES Intel)
31+
set(_arch_flag "-xHost")
32+
endif()
3033
message(STATUS "Adding architecture-specific compiler flag: ${_arch_flag}")
3134
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_arch_flag}")
3235
endif()

0 commit comments

Comments
 (0)