liam-deacon / phaseshifts

Calculate elastic electron atom scattering (EEAS) phase shifts in solid materials for LEED modelling

Hello, World!

I am a natural tinkerer, technology enthuisiast and life-long learner! I love challenges and take pride in the work that I do 🚀

🔧 Tools & Technologies

I've used a lot of different tools and technologies, so here are some highlights:

GitHub Stats

👀 Highlighted Repos

Here are some open source repos I have made:

       

phaseshifts's Issues

Add contributing guidelines

Add CONTRIBUTING.md file at root of repo.

It should describe expectations for prs, issues and community engagement.

Part preparing for collaboration under #17

Dockerise phaseshifts

This would allow for either:

1. A web server with REST API to allow for integration in other modern web stacks
2. Run the phsh.py using docker run and avoid pain of compiling the phaseshifts package from source

Support Python 3.12+

Currently Python 3.12 support is very hacky. We want to be able to support simple installation via pip with pyproject.toml and standard PEP-517 compliant builds.

Windows builds in GitHub Actions fail

Currently Windows builds fail when doing import phaseshifts.lib.libphsh due to: "ImportError: DLL load failed while importing libphsh: The specified module could not be found." which should be addressed to allow proper automated testing.

Add GUI frontend

GUI frontend (Qt ui files are provided in the gui/ directory for anyone wishing to undertake this challenge). Other frontends are welcome (I use Qt due to familiarity).

Clean up code base

There is a lot of unused, generated or preview code in the main branch. Furthermore there is old code that does not run on python 3.

Cleaning up the repository will make it easier for newcomers to navigate, understand and (crucially) contribute to the code themselves.

Add more descriptive labels to assist with project organisation

Useful for github action logic, categorisation (e.g. in release drafter #11) etc.

This can be either automated using tools or done manually and any related config files (such as .github/release-drafter.yml updated accordingly)

Possiblility of EEASiSSS backend

It is worth seeking the possibility of including John Rundgren's EEASiSSS phase shift program as a backend to the phaseshifts package.

1. Contact John Rundgren about including EEASiSSS
2. Reimplement phaseshifts internals to allow multiple backends (depends on 1)
3. Add EEASiSSS as phase shift calculation backend (depends on 2)
4. Add Documentation (depends on 3)

Related

• #90

Issues with compiling fortran code when installing on Python 3.10+

There are issues with compiling when running either:

1. python setup.py build bdist_wheel for python 3.11+
2. pip install -e . fails for Python 3.10+

This appears to be due to the deprecation/removal of numpy.distutils (see https://numpy.org/doc/stable/reference/distutils_status_migration.html#distutils-status-migration)

NOTE: This was observed on Ubuntu 20.04 using gcc/gfortran 7.5.0

Add validators for input files

As mentioned in the documentation the phsh.py module needs .inp, .pmin, .bul, or .bmin input files, but error checking is limited. We therefore need validators to check the files for malformatted input.

It might also be worth validating intermediate files from the phshift2007 program suite so that the user can potentially fix any malformatted files.

• Add validators module
• Identify possible validations

Add complete examples for documentation

The documentation would benefit from one or two complete worked examples so that the user can follow along and verify that things are working as expected.

Such worked examples could also form the foundation for integration/end-to-end tests of the phsh.py wrapper program.

Use as an external library

In order to use the phaseshifts package as an external library then a number of issues need to be resolved first, namely:

• #58
• #16
• #7
• #8
• #6

Publish package to PyPI as part of CI/CD workflow

This has been configured on PyPI at https://pypi.org/manage/project/phaseshifts/settings/publishing/

Therefore need to add publish-to-pypi.yaml GitHub Action workflow and test:

Add EEASiSSS to list of alternatives

Add John Rundgren's Elastic Electron-Atom Scattering in Solids and Solid Surfaces (EEASiSSS)
program to list of alternatives

J. Rundgren Phys. Rev. B 68 125405 (2003)

Add fortran coverage reports

See https://p403n1x87.github.io/running-c-unit-tests-with-pytest.html

In short, use gfortran and compile with -g -fprofile-arcs -ftest-coverage flags and then use gcovr

Python 3.8 build fails

This issue was seen when attempting to build a wheel using Python 3.8 on ubuntu 22.04 and x86-64 architecture. Other platforms and architectures may also be affected.

This is currently preventing a CPython 3.8 linux build in PyPI release process.

Initial Update

The bot created this issue to inform you that pyup.io has been set up on this repo.
Once you have closed it, the bot will open pull requests for updates as soon as they are available.

Add Simple REST API

Add a simple REST API around phsh.py functionality to enable the code to be integrated into web stacks

Add command line wrappers for minimally modified phshift2007 programs

This should be a legitimate option for users who wish to stick as closely as possible to the reference implementation of phsh* programs, albeit with their own potential issues owing to naïve compilation using modern compilers without attempting to address highlighted issues, e.g. gfortran -std=legacy -Wall -frecursive -fcheck-bounds.

Due to the complexities of bundling these programs as part of wheel builds, it may only be possible to bundle the compiled phsh* binaries with the docker container image.

This probably involves a few tasks:

• Bundle compiled (& statically linked) phsh binaries with Docker image
• Bundle phsh binaries with wheels
• Extend wrapper interface to allow selection of backend, e.g. f2py or legacy
• Document selection and use

Add testing for simple and/or common use cases

Currently the only testing that is done is to check that the phaseshifts.lib.libphsh compiled fortran extension is importable, however no tests are done to check the numerical accuracy of the results, nor the behaviour in different scenarios (e.g. checking against various compiler warnings such as #6).

Furthermore no testing is done on the phsh.py script which provides a more user friendly wrapper to run the entire Van Hove program suite to generate the end phaseshifts.

As such tests are needed for the following:

• Unit tests for key fortran functions (exposed via phaseshifts.lib.libphsh) as well as essential python functionality
• Behaviour tests for known model inputs against expected outputs and test things such as concurrent use
• Integration tests for phsh.py

Tutorial notebook env fails to start on mybinder.org

Mybinder.org fails to startup as it attempts to build the dockerfile at the root of the repo, however this file was not intended as a notebook environment.

Automatically publish up to date documentation

Either continue using ReadTheDocs are migrate to Github Pages

Improve Documentation

Tasks include:

• Write jupyter notebook for how to use original phshift2007 package and give worked examples
• Reach out to @GeorgHeld regarding some examples
• Complete notebook example using wrapper
• Test tutorial on http://mybinder.org
• Add notebooks as gallery in sphinx
• Document fortran source using FORD

Compiler warns that wrapped `libphsh` functions are not thread safe due to large arrays not fitting into stack memory

gfortran emits worrying warnings such as the following which may prevent the code from being used concurrently and inhibit its use in downstream python packages:

phaseshifts/lib/libphsh.f:287:40:

  287 |        dimension orb(nrmax,iorbs),rpower(nrmax,0:15)
      |                                        1
Warning: Array ‘rpower’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, moved from stack to static storage.
This makes the procedure unsafe when called recursively, or concurrently from multiple threads. Consider increasing
the ‘-fmax-stack-var-size=’ limit (or use ‘-frecursive’, which implies unlimited ‘-fmax-stack-var-size’) - or change the
code to use an ALLOCATABLE array. If the variable is never accessed concurrently, this warning can be ignored, and
the variable could also be declared with the SAVE attribute. [-Wsurprising]

NOTE: tested with gfortran versions 11 and 12