Skip to content

Some adjustments to the Python3 code to account for changes in numpy#3

Open
MarkoRamius wants to merge 3 commits intoParticulateFlow:python3from
SimulationPlatform:python3
Open

Some adjustments to the Python3 code to account for changes in numpy#3
MarkoRamius wants to merge 3 commits intoParticulateFlow:python3from
SimulationPlatform:python3

Conversation

@MarkoRamius
Copy link

The Numeric module of SciPy has been deprecated for quite a while.
In fact, we find a commit changing from Numeric to numpy from 2006
scipy/scipy@574897f

numpy, under its current name numpy, is around since 2006.
https://en.wikipedia.org/wiki/NumPy

With Python-3 being release in 2008, we feel there is no need, let alone
justification, to support a pre-2008 numerics module in the Python-3 branch of LPP.

The code was adjusted such that numpy module is loaded, and if this fails an exception is raised
instead of falling back to the older Numeric module.


We furthermore made some adjustments, which relate to recent versions of numpy specifically.

  • do not use the type np.float; use float

With release of numpy-1.20, the use of the type np.float as an alias for the build-in float type
has been deprecated. With the release of numpy-1.24, this has been finally removed.

https://numpy.org/devdocs/release/1.20.0-notes.html
https://numpy.org/devdocs/release/1.24.0-notes.html

The time between a feature being considered deprecated and being finally removed is not
fixed. However, there is an official policy document discussing this.

https://numpy.org/neps/nep-0023-backwards-compatibility.html

  • do not use atoms != [] to test for atoms being empty; use atoms.size > 0

We have not been able to find the reason why this poses no problem using numpy-1.21.5 on
Python-3.10.12; however with numpy-2.2.6 under Python-3.10.12 this comparison does not work anymore.

The release notes of numpy-1.25 discuss the use of == and != operators on arrays in the Expired Deprecations
section, i.e., these features were removed.

https://numpy.org/doc/2.0/release/1.25.0-notes.html

These changes have so far seen the most limited amount of testing possible, i.e., it works on my machines. My workstation, which is shared with other colleagues, ended up with a more recent numpy installation than standard Ubuntu-22.04 provides.

This was how the discussed issues were finally identified, after I found that lpp stopped working on my workstation but was happily working as expected on other systems I have access to.

We may discuss further testing here.
Nevertheless, I am hereby sharing the fruits of some quite lengthy trouble-shooting.

…meric Python module

The Numeric module of SciPy has been deprecated for quite a while.
In fact, we find a commit changing from Numeric to numpy from 2006
scipy/scipy@574897f

numpy, under its current name numpy, is around since 2006.
https://en.wikipedia.org/wiki/NumPy

With Python-3 being release in 2008, we feel there is no need, let alone
justification, to support a pre-2008 numerics module in the Python-3 branch of LPP.

The code was adjusted such that numpy module is loaded, and if this fails an exception is raised
instead of falling back to the older Numeric module.

--------------------------------------------------------------------------------------------------

We furthermore made some adjustments, which relate to recent versions of numpy specifically.

* do not use the type np.float; use float

With release of numpy-1.20, the use of the type np.float as an alias for the build-in float type
has been deprecated. With the release of numpy-1.24, this has been finally removed.

https://numpy.org/devdocs/release/1.20.0-notes.html
https://numpy.org/devdocs/release/1.24.0-notes.html

The time between a feature being considered deprecated and being finally removed is not
fixed. However, there is an official policy document discussing this.

https://numpy.org/neps/nep-0023-backwards-compatibility.html

* do not use atoms != [] to test for atoms being empty; use atoms.size > 0

We have not been able to find the reason why this poses no problem using numpy-1.21.5 on
Python-3.10.12; however with numpy-2.2.6 under Python-3.10.12 this comparison does not work anymore.

The release notes of numpy-1.25 discuss the use of == and != operators on arrays in the Expired Deprecations
section, i.e., these features were removed.

https://numpy.org/doc/2.0/release/1.25.0-notes.html
@danielque
Copy link
Member

@MarkoRamius
Just as background information for you: The idea behind the python3 branch was to make LPP work with python3 by a) making a minimum set of changes and b) keeping it backwards compatible with python2 (which was still in use on some of our legacy systems at that time ...).

@danielque
Copy link
Member

@MarkoRamius
So if I understand it correctly, the only real issue is the check if atoms != []: in vtk.py?

@MarkoRamius
Copy link
Author

Also the use of np.float as an alias for float caused errors on my system.

Keeping the changes to a minimum and striving for backwards-compatibility are valid goals.
So, feel free to ignore this PR.

However, one major motivation of mine to open it, was to make the issues with newer releases of numpy known and to provide a solution. Since ParticulateFlow is the only active open-source provider of LIGGGHTS, having a PR here achieves more visibility rather than just having a fork over at my organisation.

@danielque
Copy link
Member

Thanks for the clarification. We can certainly think about updating the python3 branch, I just need to think about the best approach of making the backwards compatibility aspect clear to users, e.g. by preserving the current state in a python3_backwards_compatible branch or tagging the current version ...

@MarkoRamius
Copy link
Author

As I noted above, testing as of now is limited to my Ubuntu-22.04 workstation with its non-standard numpy (which caused my initial problems) and an Ubuntu 22.04 virtual machine on my laptop (this should be as standard as Ubuntu-22.04 gets), which had no issues at all.

I propose, we keep this PR open. If I have to opportunity to do more testing, I will post the findings here.

If at some point in the future, the python3 branch needs work done, you can use this branch as a starting point.
It is a good proposal to think of a new branch going forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants