PolyMesh | Create 2D shapes in an instant with the PolyMesh editor | Graphics library

Solved it ! It was silly : there was a problem with the glm headers as they where submodules in both libraries but for some reason where not version matching. So i did have a wrong signature in the exported symbols. Using the headers in the same folder solved the issue.

The mousebutton being pressed is the trigger for ax.format_coord to return the angular coordinates on a 3D plot instead of the cartesian ones. So an option is would be to let the ax.format_coord think that no button is pressed, in which case it would return the usual cartesian x,y,z coordinates as desired.

A bit of a hacky way to achieve this, even though you clicked the mousebutton, would be to set the ax.button_pressed (which stores the current mousebutton) to something unreasonable while calling that function.

TL;DR: source thebashrc from the OpenFOAM installation at the start of the shell script.

After some digging with the OP the issue was initially that the directory containing decomposePar was not in the PATH environment variable.

Unless you have . in your PATH (this is very dangerous, do not do this), changing the current directory to the directory will not have any impact of finding decomposePar. Adding the full path to decomposePar in the shell script allowed decomposePar to be run.

Example:

After a little research I've managed to parse all 3 binary files.

1. boundary file was the easiest because even if the format from the header said that the file is in binary mode that was not the case for me. The file was in plain text (ASCII) so the parsing was easy to make.

2. points file was a little harder to parse because even if the header was in ASCII, the data itself was stored in binary. If you look at the ASCII format for the points file from a polyMesh you will see that we have the number of points and then the points represented as below:

   1681139
   (
   (-0.03975 0.0026372 -0.00919138)
   (-0.03975 0.00280753 -0.00910861)
   (-0.03975 0.00297785 -0.00902584)
   (-0.03975 0.00314818 -0.00894307)
   (-0.03975 0.00331851 -0.0088603)
   (-0.03975 0.00348883 -0.00877753)
   .
   .
   .
   

In binary, the points are represented one after another so everything you need to do is to read chunks of 3 doubles till to reach the end. And that's it for the points.

1. The faces file was a little bit trickier. In ASCII the data is represented as below:

   4789790
   (
   4(702 982 3040 1080)
   4(19 1080 3040 346)
   4(1 346 3040 982)
   4(0 1 982 702)
   4(0 702 1080 19)
   4(0 19 346 1)
   .
   .
   .
   

You have the number of faces (4789790 in this example) then, in front of every face the number of integers (4 in this example) forming the actual face, and the data for that face. In binary, you have the header which is in ASCII and then 2 vectors, one after another. The first one represents indexes for the data stored in the second vector. Why indexes? Well, because the faces don't have a constant number of integers (like in my example 4). You can find faces with 4, 5 or 6 integers and without the indexes telling you the start and end you wouldn't know how to read the data from the second vector. By the way, the indexes and the actual data are both integers.

I've spend some time finding this information, hope this will help anyone who is trying to work with polyMesh files in binary format.