Appendix E: DL_POLY_4 INSTALL Notes & README Wisdom

BUILDING

# Building notes * these notes are for building with [cmake](https://cmake.org) * you can pass options to cmake using -DOPTION=value. For a complete list of options inspect [cmake/DLPOLYBuildOptions.cmake](cmake/DLPOLYBuildOptions.cmake) * cmake -L <path to CMakeLists.txt> will show you a list of all available options. * explicit compiler specification can be achieved by using environment variable FC (eg. using Intel ifort FC=ifort) * compiler flags can be altered via FFLAGS, (eg FFLAGS=”-O3 -xHost”) * one also can use cmake-gui or ccmake to setup the build options * to change the install path use -DCMAKE_INSTALL_PREFIX=<path> (-DCMAKE_INSTALL_PREFIX=$HOME/101/DL_POLY) * automatic testing can be done after DL_POLY_4 is built, using make test * to see all the tests available use ctest -N * to run one specific test use ctest -R <TESTNAME> * for a list of all supported targets make help * TODO check it works on Windows…

## Standard MPI `sh git clone https://gitlab.com/ccp5/dl-poly.git cmake -S dl-poly -Bbuild-mpi-pure -DCMAKE_BUILD_TYPE=Release cmake --build build-mpi-pure cmake --install build-mpi-pure `

older version of cmake

`sh mkdir build-mpi-pure pushd build-mpi-pure cmake ../ -DCMAKE_BUILD_TYPE=Release make -j10 make install `

  • will use whatever default MPI is found

Intel Compilers - Intel MPI `sh FC=ifort cmake -S dl-poly -Bbuild-mpi-pure -DCMAKE_BUILD_TYPE=Release -DMPI_Fortran_COMPILER=mpiifort cmake --build build-mpi-pure cmake --install build-mpi-pure `

Intel Compilers - Some default mpi library, other than Intel MPI `sh FC=ifort cmake -S dl-poly -Bbuild-mpi-pure -DCMAKE_BUILD_TYPE=Release cmake --build build-mpi-pure cmake --install build-mpi-pure `

## Serial `sh cmake -S dl-poly -Bbuild-serial -DCMAKE_BUILD_TYPE=Release -DWITH_MPI=OFF cmake --build build-serial cmake --install build-serial ` Intel Compilers `sh FC=ifort cmake -S dl-poly -Bbuild-serial -DCMAKE_BUILD_TYPE=Release -DWITH_MPI=OFF cmake --build build-serial cmake --install build-serial `

## Optimisation flags * gfortran/cray/intel use as options, flags are documented in [cmake/flags.cmake](cmake/flags.cmake)

`sh -DCMAKE_BUILD_TYPE=Release `

`sh FFLAGS="-O3 -mtune=native" `

  • Intel

`sh FFLAGS="-fpp -O3 -xHost -fimf-domain-exclusion=15" `

  • If you plan to run the binary on a different type of a machine than you build it, check the manual of your compiler

for the flags matching the _running machine_

## Debugging, or when things go unexpected * gfortran/cray/intel use as options, flags are documented in [cmake/flags.cmake](cmake/flags.cmake)

`sh -DCMAKE_BUILD_TYPE=Debug ` * other compilers

`sh FFLAGS="desired flags" cmake ../ `

## Building with KIM support ` cmake -S dl-poly -Bbuild-with-kim -DCMAKE_BUILD_TYPE=Release -DWITH_KIM=ON -DCMAKE_INSTALL_PREFIX=mypath cmake --build build-with-kim cmake --install build-with-kim `

## Building with PLUMED support `sh cmake -S dl-poly -Bbuild-with-plumed -DCMAKE_BUILD_TYPE=Release -DWITH_PLUMED=ON -DCMAKE_INSTALL_PREFIX=mypath cmake --build build-with-plumed cmake --install build-with-plumed `

## building with FORD API Documentation

`sh cmake -S dl-poly -Bbuild-with-ford -DDOCS_FORD=On cmake --build build-with-ford -- ford `

# FAQ

## On Ubuntu machines

It was noticed that for some mpi implementations the linking stage fails. You will see a lot of errors claiming undefined references to MPI_* solution

`sh FC=mpif90 FFLAGS="-O3" cmake ../ `

## Intel MPI

Intel MPI Fortran wrapper breaks ifort preprocessing you will get an error on the lines Len_trim(xxx) not supported or similar. solution do not use FC=mpiifort

CODING STYLE

# Coding Style

The programming style of DL_POLY is intended to ensure the code is a consistent, readable and maintainable as possible. The following rules apply throughout the code. Contributors to the code are urged to read and apply this style before submitting code for inclusion consideration.

# Units

All routines employ DL_POLY internal units. Output contains, when relevant, the units.

SIMULATION CONTROL PARAMETERS

simulation temperature (K) 1.0000E+01

simulation pressure (katms) 0.0000E+00

Integration : Leapfrog Verlet Ensemble : NVT Nose-Hoover thermostat relaxation time (ps) 1.0000E-01

selected number of timesteps 5000

# General Style

  • Use modern Fortran free form syntax.

  • Code should be written in Fortran2003/2008 dialect if possible.

  • Check the deprecated features from Fortran 2003/2008 and prior. Avoid using these features.

  • Fortran2008 should be treated with care, since not all compilers implement it.

  • Do not use Common blocks and Block Data, use Modules with public data if constant or a user defined type to group data which changes during runtime.

  • Do not use go to statements

  • Do not use format statements

  • File extension shall be .F90 for any new written code.

  • Indent code blocks by two space characters. Do not use tabs as they are not part of the Fortran standard.

```fortran Subroutine init(T,k,traj)

Class(current_type) :: T Type(trajectory_type),Intent(in) :: traj Real(Kind=dp),Intent(in) :: k(3)

Allocate(T%jk(traj%nFrames,3)) T%k = k T%n = traj%nFrames

End Subroutine init ```

  • Indent Contains statements to the same level as the sorrounding Module, or procedure

```fortran Module my_module

Implicit None

Integer( Kind = wi ), Parameter :: pi = 3.14…

…

Contains

Subroutine my_subroutine(a,b)

…

End Module my_module ```

  • Do not use more than one blank line to separate blocks of code.

  • Code lines shall not exceed 132 characters (the modern Fortran standard limit).

  • Do not write Fortran keywords in ALL capitals. Capitalize the first letter of the statement to make them stand out for the reader.

```fortran
Program dl_poly

Use kinds, Only : wi,wp Implicit None

End Program dl_poly

``` - While Fortran supports multiple statements on a line separated by ;

try to use them sparingly and wisely.

  • Variables, constants and program units should be named in English or using common physics notation. Do not use cryptic names.

  • Try to group variables names based on physical meaning or usage.

```fortran

! Verlet neighbour list data !> Update cells flag Logical, Public :: update = .true. !> Unconditional update flag Logical, Public :: unconditional_update = .false.

!> Tracking points for Verlet neighbour list Real( Kind = wp ), Allocatable, Public :: xbg(:),ybg(:),zbg(:)

!> Largest vdw cutoff, defines Verlet neighbour list radius Real( Kind = wp ), Public :: cutoff !> Padding around cutoff Real( Kind = wp ), Public :: padding !> Actual Verlet neighbour list cutoff (cutoff+padding) Real( Kind = wp ), Public :: cutoff_extended

!> Linked cell list Integer( Kind = wi ), Allocatable, Public :: list(:,:) !> Maximum rank of linked cell list Integer( Kind = wi ), Public :: max_list !> Maximum number of cells per domain Integer( Kind = wi ), Public :: max_cell

```

  • Avoid naming program units, variables, constants using intrinsincs routines or keywords from fortran standard.

  • While Fortran is case insensitive, use for lower case letters for program units, variables and constants.

  • Where more than a word is used in a name use _ as separator (snake case notation).

  • Use the mordern syntax for logical expressions, - == not .eq. - /= not .ne. - &gt; not .gt. - &lt; not .lt. - &gt;= not .ge. - &lt;= not .le. .

  • Prefer positive testing in logical blocks.

```fortran
If (isw == 0) Then

! do some fancy code

Else

! do some not so fancy code

End If

! to
If (isw /= 0) Then

! do some not so fancy code

Else

! do some fancy code

End If

``` - One line If shall be avoided. - Always use the optional separation space for End constructs, e.g.

End If not Endif and End Do not Enddo

  • For program units use the full End: End Subroutine name.

  • Never use Go To statements

  • Use Do … End Do instead of Do … Label Continue

  • Do not use Format.

```fortran

Write(*,20) reclen

20 Format(‘(‘,i0,’a)’)

! replace with

Write(*,’(a,i0,a)’)”(“,reclen,”a)”

```

  • Do not use interactive commands, like Read from keyboard or Pause.

  • Use Implicit None to avoid unwanted side effects. This is only nessecary once per module.

  • Avoid implicit casting of data: use 2.0_wp instead of 2.0 in an expression.

```fortran
If (sw == 1) Then

factor = 2.0_wp*engke*rf

End If

! and not If (sw == 1) factor = 2.0_wp*engke*rf ```

  • Floating point comparisons shall be done with care. Consider the following examples using a tolerance of Epsilon(a) or Tiny(a), - a > tolerance instead of a > 0.0 - a - b > tolerance instead of a > b - abs(a - b) < tolerance instead of a == b .

  • Avoid use of magic numbers, declare constants at the top level of a module and use those instead.

```fortran If (integrator == 1 ) Then ! instead use

Integer( Kind = wi ), Parameter :: VELOCITY_VERLET = 1

…

If (integrator == VELOCITY_VERLET ) Then ```

  • Any new feature shall be turnable on/off from CONTROL file.

  • Any new feature shall be documented in the manual and will cite relevant literature.

## Modular structure

  • All subroutines/functions shall be enclosed by a module.

  • Modules may contain the following:

  • Type declarations

  • Subroutines and functions

  • Paramter definitions (using the Parameter attribute)

  • Interfaces for overloaded procedures

  • Declaration of Public data

  • Modules may NOT contain the following:

  • Variables (_i.e._ specifications without the Parameter attribute)

  • By default everything in a module shall be made private, explicitly make public what is needed outside the module or type using the Public statement.

  • Data which is used only in the defining module should be declared private.

  • Each module should be in a separate file.

  • Module names shall match their file names.

  • When using a module with the Use statement, Only must also be used

  • While overloading operators may be tempting, it is best avoided if you prefer performance to aesthetical beauty.

`fortran Use domains_module, Only : map ` - User derived types should be created to contain data relevant to the module, preferably one per module. - Types may match the module name but append them with _type. - Types shall provide init and Final procedures, optionally a summary

procedure.

  • If provided a summary procedure shall produce valid YAML 1.2 output.

## Specification Statements

  • Align declaration statements clearly separating types and attributes from names.

  • Separate variable declaration block from code block of a subroutine by a blank line.

  • Use separate declaration blocks for routine arguments and local variables.

```fortran !> Calculate the factorial of n Function factorial(n) Result(res)

!> The integer to calculate the factorial of Integer( Kind = wi ), Intent( In ) :: n !> The factorial of n Integer( Kind = wi ) :: res

!> Running total Integer( Kind = wi ) :: total !> Loop iterator Integer( Kind = wi ) :: i

…

```

  • Always use :: to separate types and attributes from names.

  • Use :: as an alignment guide if the list of names is too long.

  • Separate logical declaration blocks can be aligned differently to save screen real estate, e.g. parameters vs internal variables of a routine.

```fortran Integer, Intent( In ) :: imcon,mxshak Real( Kind = wp ), Intent( InOut ) :: xxx(1:mxatms),yyy(1:mxatms),zzz(1:mxatms) Real( Kind = wp ), Intent( Out ) :: strcon(1:9) Real( Kind = wp ), Intent( Out ) :: vircon

Logical :: safe Integer :: fail(1:2),i,j,k,icyc Real( Kind = wp ) :: amti,amtj,dli,dlj, &

gamma,gammi,gammj,tstep2

```

## Comments

  • Comments shall be indented to align with the code

  • Comments shall be written in lower case except for proper nouns and standard abreviations.

  • Comments shall explain what a code does and why, not how it does it. Let the code explain how it is done.

## Ford and Doxygen

  • By conforming to the following style useful developer documentation may be created automatically using either FORD or Doxygen.

  • Comments attached to program units, variables and derived types may be automatically documented.

  • Documentation must precede the declaration of the unit, variable or derived type.

  • Comments to be documented must use the tag “!>” (This is default tag in FORD for a comment preceding the content. In Doxygen, “!>” is the only tag which can both start and continue a comment. So this seems to be the best compromise to make the source compatible with both systems. FORD does not like inline comments).

  • To insert a line break in a multiline comment use a blank comment line.

  • Comments use markdown syntax for formatting.

  • LaTeX style maths may be used to include equations in the documentation.

  • See the example structure for more comprehensive examples of documentation comments.

```fortran !># Example !> !> Author - John Smith !> !> An example program Program example

Use kinds, Only : wi Implicit None

!> Integer counter Integer( Kind = wi ) :: i

…

!> Calculate the factorial of n Function fact(n)

…

```

## Procedures

  • A Function shall be pure (with no side-effects). If side-effect are needed use a Subroutine.

  • All arguments of a Function/Subroutine shall have an Intent attribute (with the exception of the Class in type bound procedures).

  • Avoid using Recursive procedures.

  • When you are passing an array argument to a Subroutine/Function, and the Subroutine/Function does not change the size of the array, you should pass it as an assumed shape array. Memory management of such an array is automatically handled by the Subroutine/Function, and you do not have to worry about having to Allocate or Deallocate your array. It also helps the compiler to optimise the code.

## Allocatable Data and Pointers

  • If possible Allocate and Deallocate for an array or pointer shall appear in the same scope.

  • For Allocatable members of a user defined type, allocation shall happen in the init and deallocation in the final subroutine.

  • In all cases, Deallocate in the opposite order you did Allocate.

```fortran

Allocate(xxx(n),Stat = stat) Allocate(yyy(n),Stat = stat) Allocate(zzz(n),Stat = stat)

Deallocate(zzz) Deallocate(yyy) Deallocate(xxx)

```

  • If using Pointer, define it before usage by pointing to Null or using Nullify.

  • Similarly, when a pointer is not used anymore nullify it using the same techniques as above.

CONTRIBUTING

# Contribution workflow and the review process

This document outlines the best practice, using git and CI, which must be followed for all contributions to DL_POLY. Also contained are instructions and tips for managing your fork of the project which will help keep merges clean and avoid many headaches.

## Golden rules

In brief the rules for contribution are as follows,

  • Follow the branch, fix, merge model, from your own fork

  • An issue must be created for every piece of work (bug, feature, etc.)

  • Merge requests will not be accepted without a review

  • New features must have a test

  • All tests must pass, no regressions may be merged

## Issues

### Using issues

  • Open an issue for each piece of work done.

  • Open issues for design discussions. For example the questions Aidan had about link cells/domain decomposition. The answers may be important for newer members.

  • New features, _e.g._ task parallelism by Aidan, shaped particles by Vlad, shall have an issue too, the comments shall be used to provide succint reports on progress.

### Labels

Labels may be assigned to issues to help classify them. Examples include,

  • Testing: as in testing the water. This label shall be attached to things one may think to make one day.

  • Development: this is what I am working now on.

  • Production: anything in this is critical and shall be fixed asap.

  • Design: queries or suggestions about the structure of the program.

  • Leader: for issues relating to new features.

## Review

All merge requests will be reviewed to ensure the integrity of the code.

The reviewer/s have the following responsibilities,

  • Ensuring all contribution rules have been followed

  • Ensuring the [coding style](./coding_style.md) is adhered to

  • Only accepting a merge if all tests have passed

  • Using the comments system to request changes for the submittor to make

## Using the git for development

The Gitlab instance hosts a _devel_ repository, which we will refer to as _devel_. Contributors will work on their own personal copies of the repository by creating _forks_. This allows us to keep _devel_ clean (one commit per merge request, if possible, all commits passing tests) while users may work on their own _fork_, creating commits and changing the code as they see fit.

The _devel_ repository may be cloned as follows,

`sh git clone git@gitlab.com:ccp5/dl-poly.git dl-poly-devel ` A _fork_ is created using the web UI. It may then be cloned for a user called ‘username’ as follows,

`sh git clone git@gitlab.com:username/dl-poly.git dl-poly-fork `

### Branch, fix, merge model:

All work should follow the workflow of branch, fix, merge. Let us assume you have an issue with your code which needs to be fixed.

#### Step 1: Branch from your fork

Create a new branch for the issue on the dashboard of your fork, we will assume the branch is called ‘issueXYZ’. Clone the branch,

`sh $ git clone -b issueXYZ --single-branch git@gitlab.com:username/dl-poly.git dl-poly-issueXYZ `

Alternatively you can create the branch in the cli using

`sh # clone the repository, if you already have a local repository this is not nessecary $ git clone git@gitlab.com:username/dl-poly.git dl-poly-issueXYZ $ pushd dl-poly-issueXYZ # create and checkout a new branch (this is equivilent to git branch followed by git checkout) $ git checkout -b issueXYZ # create a remote tracking branch for you to push your changes to $ git push -u origin issueXYZ `

#### Step 2: Fix the issue and commit your changes

Fix whatever is wrong. Use git status to see which files you have changed and prepare a commit.

`sh # stage changes $ git add <filename|folder> to add the new things # commit the changes with a clear and brief message $ git commit -m "<commit message>" # push the commit to origin $ git push `

#### Step 3a: Merge your branch into devel

On the web interface navigate to _devel_ and create a merge request for your branch on your _fork_. Add any relevant labels or milestones and assign a reviewer. Compare the code and if you are happy click Submit Merge Request.

After the merge request has been submitted tests will be run and your reviewer will be notified.

#### Step 3b: Finalising the merge

If all is OK with the commit your reviewer may set the request to be merged once all tests pass. Otherwise the reviewer may open discussions using the Gitlab comment system to point out issues that may need to be addressed before the commit can be merged.

If changes need to be made you may make more commits onto your branch. When you push your branch to your _fork_ the merge request will be automatically updated to use the latest commit. Reply to the discussions to indicate when and how they have been addressed.

If your branch has become out of sync with _devel_ then conflicts may arise. Sometimes these cannot be automatically resolved and you will need to resolve them by hand. Gitlab provides instructions for this, or you can follow this routine,

`sh # add devel as a remote if you have not already $ git remote add devel git@gitlab.com:ccp5/dl-poly.git # get the changes to devel since you started working on your issue $ git fetch devel # merge these changes into your branch (assuming you want to merge into the master branch on devel) $ git merge devel/devel # resolve any conflicts # push to your fork $ git push `

Alternatively you may use rebase which will replay the changes you made in your branch on top of _devel/devel_ however be sure you understand the differences between merge and rebase

`sh # add devel as a remote if you have not already $ git remote add devel git@gitlab.com:ccp5/dl-poly.git # get the changes to devel since you started working on your issue $ git fetch devel # merge these changes into your branch (assuming you want to merge into the master branch on devel) $ git rebase devel/devel # resolve any conflicts # push to your fork $ git push `

### Advanced git

#### Keeping your fork in sync with project

By adding two remotes, one for _devel_ and one for your _fork_ it is possible to keep your _fork_ in sync with _devel_. This will greatly simplify merge requests.

`sh # clone your fork $ git clone git@gitlab.com:username/dl-poly.git dl-poly-fork pushd dl-poly-fork # add a remote for devel $ git remote add devel git@gitlab.com:ccp5/dl-poly.git `

These commands need to be done only once. git remote -v shall show you the origin and project fetch and push links

`sh $ git remote -v origin  git@gitlab.com:username/dl-poly.git (fetch) origin  git@gitlab.com:username/dl-poly.git (push) devel git@gitlab.com:ccp5/dl-poly.git (fetch) devel git@gitlab.com:ccp5/dl-poly.git (push) `

When you need to sync your _fork_ with _devel_, do the following,

`sh # get the latest commits from devel $ git fetch devel # ensure you are in the master branch of your fork $ git checkout master # merge your master branch into the master branch of devel $ git merge devel/devel # push these changes back to the remote of your fork (origin) $ git push `

of course one can use a similar process to merge any other branch or available projects.

#### Rebasing commits

When working on an issue you may use multiple commits. When you are ready to create a merge request, you should squash your changes into one commit in order to keep _devel_ clean. This is most easily achieved with an interactive rebase.

Assuming you have made five commits,

`sh # rebase your branch five commits before HEAD i.e. where your branch originally diverged $ git rebase -i HEAD~5 # follow the instructions. 'pick' the first commit then 'sqaush' or 'fixup' the rest. # You should now be left with a single commit containing all your changes # Push your commmit to the remote, use --force if you have already pushed this branch to # 'rewrite history' $ git push origin branchname --force ` using force is a powerful and dangerous option. use it only if you know 150% nobody else touched that branch.

#### Cleaning stale branches

Deleting branches from the web interface will get rid of the remotes and not of your local copies. The local branches left behind are called stale branches. To get rid of them

`sh $ git remote prune origin `

To delete a local branch

`sh $ git branch -d localBranch `

if unmerged commits exists but you still want to delete use

`sh $ git branch -D localBranch `

To delete a remote branch on the remote _origin_ use

`sh $ git push -d origin remoteBranch `

## Code Coverage If one builds DL_POLY_4 with -DWITH_COVERAGE=ON two targets will be available make coverage and make runcoverage. First will run the code coverage on all tests from make test.

make runcoverage will run on the inputs which are put by user in CodeAnalysis. If one uses MPI -DMPI_NPROCS, default 4, controls on how many processes the job will run.

LICENCE

GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007

Copyright © 2007 Free Software Foundation, Inc. <https://fsf.org/>

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.

0. Additional Definitions. As used herein, “this License” refers to version 3 of the GNU Lesser General Public License, and the “GNU GPL” refers to version 3 of the GNU General Public License.

“The Library” refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.

An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.

A “Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”.

The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.

1. Exception to Section 3 of the GNU GPL. You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.

2. Conveying Modified Versions. If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:

  1. under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or

b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy. 3. Object Code Incorporating Material from Library Header Files. The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

  1. Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.

b) Accompany the object code with a copy of the GNU GPL and this license document. 4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:

  1. Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.

  2. Accompany the Combined Work with a copy of the GNU GPL and this license document.

  3. For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.

d) Do one of the following: 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user’s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.) 5. Combined Libraries. You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following:

  1. Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.

b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 6. Revised Versions of the GNU Lesser General Public License. The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.

If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy’s public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.