I am unsure about how this is a bug from LAMMPS, Ovito or both, but when I try to run a Python script that computes an stl surface file using Ovito’s Python library, LAMMPS seems unable to parse the floating point values correctly.
Even if the surface is not computed by Ovito but Ovito is called, it seems to mess up with file reading afterward. This might be linked to this other issue. I do not understand where this can come from. The only way I could solve this was initially by making only the rank 0 read the file, compute ALL the atom positions and broadcast then to other instances. But this is not really a solution worth implementing and if it worked for my initial computation, it does not seems to hold for my example. So I think the problem is deeper.
Here are the file of a minimum example:
data.in.lmp (1.3 MB)
in2.lmp (527 Bytes)
surface.stl (5.2 MB)
The ovito related lines are commented in the Python script of in2.lmp. When uncommented the code hangs. Forcing utils::numeric to throw an error in create_atoms.cpp leads to the following:
Reading STL object Visualization Toolkit generated SLA File from text file surface.stl
ERROR: Floating point number 53.525156832 in input script or data file is invalid (src/create_atoms.cpp:1174)
Last input line: create_atoms 4 mesh surface.stl units box
ERROR: Error reading triangles from STL mesh file surface.stl: ERROR: Floating point number 53.525156832 in input script or data file is invalid (src/create_atoms.cpp:1174)
Last input line: create_atoms 4 mesh surface.stl units box
(src/create_atoms.cpp:1239)
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[8021,1],0]
Exit code: 1
--------------------------------------------------------------------------
I am a bit puzzled by this situation so any help would be appreciated.
This is a long shot, but maybe this is connected to your system locale? I recall a similar problem with LAMMPS-GUI, where the issue was that the decimal point was defined as a comma instead of a dot. What is the output of locale Linux command on your PC?
2 Likes
Oh boy… good catch.
Here was the output:
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
French does use comma as a decimal separator so using export LC_ALL=C.UTF-8 made it run. However it is still unclear to me how the MPI rank 0 could read it in the other context (which added a layer of Python on top of this). I’ll check if this also solves the other problem. Edit: it does. So loading ovito changes the locale used by the C code.
1 Like
FYI, LAMMPS itself does not explicitly set the locale, which means that it operates under the “C” locale and that results in consistent behavior when processing numbers.
However, GUI applications tend to apply the host system locale during initialization. This is what happened and thus caused the issues that @mkanski was referring to. He was not the only victim.
Thus in LAMMPS-GUI we very early on enforce the C locale by forcing the LC_ALL environment variable:
int main(int argc, char *argv[])
{
Q_INIT_RESOURCE(lammpsgui);
#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
// register QList<QString> only needed for Qt5
qRegisterMetaTypeStreamOperators<QList<QString>>("QList<QString>");
#endif
// enforce using the plain ASCII C locale with UTF-8 encoding within the GUI.
qputenv("LC_ALL", "C.UTF-8");
QApplication app(argc, argv);
QCoreApplication::setOrganizationName("The LAMMPS Developers");
QCoreApplication::setOrganizationDomain("lammps.org");
QCoreApplication::setApplicationName("LAMMPS-GUI - QT" stringify(QT_VERSION_MAJOR));
QCoreApplication::setApplicationVersion(LAMMPS_GUI_VERSION);
It may be a good idea to suggest a similar step to the OVITO developers. I consider using native language support a very bad idea for scientific applications. Not only does it produce inconsistent behavior related to numbers, but also it results in illegible system error messages, unless you by chance can guess them or know enough of the foreign language to make sense of them, which is very annoying.
1 Like