ESyS-Particle

General question about the state of the code

Asked by David Hindle

Hiya all.
I am interested in using ESys, migrating from old versions of PFC2d. I was wondering if anyone could give me a brief assessment of how well the code is maintained and functions currently? I see a few people are still using this forum, so there is hope.
Just a check before investing time. IF ESys will continue to function, even in a frozen state, that's fine. However, I am a Linux user, and obviously, library compatibility can quickly become an issue in these cases. Any general ideas or thoughts appreciated.

Many thanks in advance
David Hindle

Question information

Language:
English Edit question
Status:
Solved
For:
ESyS-Particle Edit question
Assignee:
No assignee Edit question
Solved by:
David Hindle
Solved:
Last query:
Last reply:
Revision history for this message
Dion Weatherley (d-weatherley) said : 		#1

Hi David,

Thanks for your interest in ESyS-Particle. The code continues to be maintained on a voluntary basis and is in active use by a number of research groups around the globe. Whilst new features are not added very frequently these days, that largely reflects the maturity of the code. There are no longer critical missing features for most DEM applications. I still monitor the user forum and answer questions as time permits.

ESyS will continue to function for the foreseeable future and is not "frozen" per se. For example, a new interaction group (rotational resistance) was added about a month ago. We also have capacity to address library compatibility issues and improvements exploiting new compiler features from time to time. Fortunately, ESyS-Particle is only reliant upon a few major third party libraries (Python, Boost, MPI, C++) for its core functionality. I do not envisage these libraries to massively change or disappear any time soon.

I hope this helps.

Cheers,

Dion

Revision history for this message
David Hindle (dhindle) said : 		#2

HI Dion
Many thanks for the comprehensive answer. I installed the code and everything seems to be fine (Ubuntu 21.10).
Only thing was to set the correct python for the symbolic link (python39 on my system).
Apart from that, I noticed the test script at the end of the ubuntu 20.04 install page has an underscore in "esys-particle_trunk"
when invoking the mpirun, whilst the installation uses "bzr branch lp:esys-particle esys-particle-trunk" so esys-particle-trunk is completely hyphenated.
If you go through the installation and test procedure using tab to autocomplete commands in the shell, you will end up getting a head-scratching error
"python3: can't open file '/home/david/src/ESyS-Particle/esys-particle_trunk/Doc/Examples/two_particle.py': [Errno 2] No such file or directory"

It would be good to change one or the other form of esys-particle_trunk / esys-particle-trunk to make them consistent with each other throughout the installation instructions on the web page.

Apart from that, many thanks again. I am excited to start using the code properly

Best Wishes
David Hindle

Revision history for this message
Dion Weatherley (d-weatherley) said : 		#3

Hi David,

Glad to hear you were able to install the code without too many difficulties.

I've fixed the "esys-particle-trunk" typo in the FAQ. Thanks for pointing that out.

> Only thing was to set the correct python for the symbolic link (python39 on my system).

Could you please clarify if this was the symbolic link to libboost-python? In other words, this command:

sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_python38.so.1.71.0 /usr/lib/x86_64-linux-gnu/libboost_python3.so

or was it the command to set up the PYTHONPATH enviroment variable?

export PYTHONPATH=/usr/local/lib/python3.8/dist-packages:/usr/local/lib/python3/dist-packages:$PYTHONPATH

I'd appreciate your help to clarify this so I can update the FAQ to benefit future users.

Cheers,

Dion

Revision history for this message
David Hindle (dhindle) said : 		#4

Hi Dion
It was the symbolic link to libboost_python. I should point out, I caught it because I was using autocomplete with the tab key to find the path in the sudo ln -s command. Hence, this led me to the correct libboost_python automatically.

I think a similar issue occurs in other library intensive, linux system software. If you know GMT (Generic Mapping Tools) for instance, an installation will fail after updates changing the version number of netcdf, (also lib-gdal, I think). The workaround in that case is to set a symbolic link with the correct name (for the GMT installation) pointing to whatever version of netcdf is actually installed on the system. It's pretty similar to what seems to be happening with ESyS here. I guess with any update of the Linux system that changes the libboost_python number, an existing ESyS installation could have problems without the link being updated.

Best Wishes
David

Revision history for this message
Dion Weatherley (d-weatherley) said : 		#5

Hi David,

Thanks for that. I've amended the FAQ appropriately.

It is possible that the symbolic link is no longer required but I have not confirmed that myself. Apparently, the lack of this symbolic link for boost-1.71.0 was considered to be a "bug" and there was indication online that it would be fixed in future version releases of boost. We do hit some temporary problems like this from time to time and try to remedy/adapt as soon as possible. This symbolic link issue was rather annoying for us, when ubuntu-20.04 was released, as it was not required for all previous ubuntu releases. For the most part, the ESyS build system is pretty good at finding the correct libraries. I should note that the newer cmake build system for ESyS, does not require that symbolic link in order to find the correct library.

FWIW, I generally do not update the installation notes until the next LTS release, which will be ubuntu-22.04. When that release is available, I will upgrade my own PC and update the installation notes accordingly.

Have fun with ESyS!

Cheers,

Dion