Error when exporting am meshes

[SAFedorov]

Hello,
There appears to be a bug when exporting meshes in .am format. It can be reproduced in the following script:

mesh Th = square(10, 10);
savemesh(Th, "square.am");
mesh Th2=readmesh("square.am");
plot(Th2);

As you can see, it creates a mesh, saves it into an am file, and tries to read it out and plot. However, when executing it I get the following error:

Fatal Error Input FortranUnFormattedFile
 Erreur  read Record number = 2
 read position  in file 320 < 4672 =  end on record
 position in the record = 300 length of record = 4652
 file = square.am
 Fatal error in the mesh generator 900
  current line = 3
Meshing error: Bamg
 number : 900,
Meshing error: Bamg
 number : 900,
 err code 5 ,  mpirank 0

When using the text am_fmt, there is no problem. My small investigation showed that the content of the exported .am file looks strange --- in the block (number 2) listing the triangle vertex indices, some indices have nonsensically large integer values, while many are ok, in agreement with what I find if creating a formatted file for the mesh .am_fmt.
The freefem version I use is 4.9 on Windows.

[SAFedorov]

Hello again,
It looks like the problem arises because of extra carriage return symbols inserted in the binary file. The analysis of the content of the .am file generated by the script in my previous message suggests that every byte that happened to correspond to the '\n' symbol is replaced by two bytes, '\r\n'. This also leads to some bytes at the end of the file being lost, because the lengths of the Fortran sections are calculated without accounting for the extra '\r' bytes. My understanding is that the problem can occur because the output file is always open in textual format (in this line), even when saving a mesh in the binary am format.

If anyone is curious, I attach the notebook that examines the am file content.
am_investigation.zip

[frederichecht]

I will a patch for this in next version. Best Regards, Frédéric Hecht.

…

----------------------------------------------------------------------------------------------------------------------------------- Laboratoire Jacques-Louis Lions, UPMC Sorbonne Université BC187, 4 Place Jussieu, 75252 PARIS cedex 05, France Campus Jussieu, Barre 15-25, 3 etage Bureau 307 Projet Alpines , Inria de Paris, 2 rue Simone Iff Voie DQ12 75012 Paris tel: +33 1 44274411, mob: +33 6 62198986, fax: +33 1 44277200 ***@***.*** https://www.ljll.math.upmc.fr/hecht software: FreeFem++ web site: http://www.freefem.org/ff++

Le 19 juin 2022 à 10:32, Sergey Fedorov ***@***.***> a écrit : Hello again, It looks like the problem arises because of extra carriage return symbols inserted in the binary file. The analysis of the content of the .am file generated by the script in my previous message suggests that every byte that happened to correspond to the '\n' symbol is replaced by two bytes, '\r\n'. This also leads to some bytes at the end of the file being lost, because the lengths of the Fortran sections are calculated without accounting for the extra '\r' bytes. My understanding is that the problem can occur because the output file is always open in textual format (in this line <https://github.com/FreeFem/FreeFem-sources/blob/9b88bed4d1079b5af424300e32f876bddc9b4520/src/bamglib/MeshWrite.cpp#:~:text=ofstream%20f(filename%20/*%2Cios%3A%3Atrunc*/)%3B>), even when saving a mesh in the binary am format. If anyone is curious, I attach the notebook that examines the am file content. am_investigation.zip <https://github.com/FreeFem/FreeFem-sources/files/8934986/am_investigation.zip> — Reply to this email directly, view it on GitHub <#231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLPNDCTIKKTPGROG7LCYBTVP3LIHANCNFSM5X3WYZYQ>. You are receiving this because you are subscribed to this thread.

[frederichecht]

The correction in theory

…

Le 19 juin 2022 à 10:32, Sergey Fedorov ***@***.***> a écrit : Hello again, It looks like the problem arises because of extra carriage return symbols inserted in the binary file. The analysis of the content of the .am file generated by the script in my previous message suggests that every byte that happened to correspond to the '\n' symbol is replaced by two bytes, '\r\n'. This also leads to some bytes at the end of the file being lost, because the lengths of the Fortran sections are calculated without accounting for the extra '\r' bytes. My understanding is that the problem can occur because the output file is always open in textual format (in this line <https://github.com/FreeFem/FreeFem-sources/blob/9b88bed4d1079b5af424300e32f876bddc9b4520/src/bamglib/MeshWrite.cpp#:~:text=ofstream%20f(filename%20/*%2Cios%3A%3Atrunc*/)%3B>), even when saving a mesh in the binary am format. If anyone is curious, I attach the notebook that examines the am file content. am_investigation.zip <https://github.com/FreeFem/FreeFem-sources/files/8934986/am_investigation.zip> — Reply to this email directly, view it on GitHub <#231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLPNDCTIKKTPGROG7LCYBTVP3LIHANCNFSM5X3WYZYQ>. You are receiving this because you are subscribed to this thread.