Problem with UNV-Mesh-reading

[bernd]

Can you post your locale setting?

Code: Select all

$ locale
LANG=de_CH.UTF-8
LANGUAGE=de_CH:de
LC_CTYPE="de_CH.UTF-8"
LC_NUMERIC="de_CH.UTF-8"
LC_TIME="de_CH.UTF-8"
LC_COLLATE="de_CH.UTF-8"
LC_MONETARY="de_CH.UTF-8"
LC_MESSAGES="de_CH.UTF-8"
LC_PAPER="de_CH.UTF-8"
LC_NAME="de_CH.UTF-8"
LC_ADDRESS="de_CH.UTF-8"
LC_TELEPHONE="de_CH.UTF-8"
LC_MEASUREMENT="de_CH.UTF-8"
LC_IDENTIFICATION="de_CH.UTF-8"
LC_ALL=
$

in Switzerland the dot is dezimal delimiter not komma!

[bernd]

changed locale

Code: Select all

$ export LC_NUMERIC="de_DE.UTF-8"

But I can not reproduce the problem. Meshing works quite well.

[ulrich1a]

Ok, the swiss seems to be a little different. With LANG=de_CH.UTF-8 everything is working for me.
Try in the console

Code: Select all

export LC_NUMERIC="de_DE.utf8"

and You will see the problem.

Now what is the problem with gmsh? Does it fail while loading existing files? If yes can you check if there is comma as decimal separator in floating numbers?

The unv-file is loaded, but gives corrupt data. The file generated by Gmsh contains points as decimal separator.
It is even worse, old FreeCAD-documents with meshes showing also a corrupted mesh now.
The same file is ok, when loaded with LC_NUMERIC="C" exported in the console.
So it is obvious, that the setting of LC_NUMERIC to "C" does not work now internally in FreeCAD on Debian, at least for the FEM-workbench.

Ulrich

[bernd]

Try in the console

Code: Select all

export LC_NUMERIC="de_DE.utf8"

and You will see the problem.

I did, see post

changed locale

Code: Select all

$ export LC_NUMERIC="de_DE.UTF-8"

But I can not reproduce the problem. Meshing works quite well.

It is even worse, old FreeCAD-documents with meshes showing also a corrupted mesh now.

FreeCAD uses unv embeded in FCStd to save the meshes. Just unzip an FCStd which contains a mesh and you will see the unv.

[ulrich1a]

The posted file from here https://forum.freecadweb.org/viewtopic. ... 00#p159335 with the failed mesh contains some numbers with points as separator in the header part. The node coordinates have commas as separator.
Formerly created meshes have all points as separator in the FreeCAD document.
So this is the problem. It seems FreeCAD is using internally a mixture of different settings for LC_NUMERIC.

Ulrich

[wmayer]

So this is the problem. It seems FreeCAD is using internally a mixture of different settings for LC_NUMERIC.

OK, can you undo the change I did in the main() function? Actually there is probably a difference between putenv and setlocale because the former sets the environment variable LC_NUMERIC and thus affects child processes, too. Since in FEM a couple of external programs are used and started from FreeCAD this might explain all the problems.

[ulrich1a]

OK, can you undo the change I did in the main() function?

I did and now the meshing is ok again.

Code: Select all

    QFile::setEncodingFunction(myEncoderFunc);
    QFile::setDecodingFunction(myDecoderFunc);
#endif
    std::cerr << "getenv, Set locale is: ";
    char* enviro = getenv("LC_NUMERIC");
    if (enviro != NULL) std::cerr << enviro  << std::endl;
    std::cerr << std::endl;

    std::cerr << "was putenv, Set locale is: ";
    std::cerr << setlocale(LC_NUMERIC, NULL)  << std::endl;
    putenv("LC_NUMERIC=C");
    putenv("PYTHONPATH=");

I put the above code lines in the MainGui.cpp for debugging purpose. The output in the console is:

Code: Select all

getenv, Set locale is: 
was putenv, Set locale is: C

It looks like the environment variable was not set before.

Ulrich

[wmayer]

OK, then I hope all locale related issues are resolved now. git commit b9e8b4f

[Kunda1]

OK, then I hope all locale related issues are resolved now. git commit b9e8b4f

@wmayer is issue #2899 related to this locale issue ?

[ulrich1a]

is issue #2899 related to this locale issue ?

This is something different, as far as I can say.
I can see the described behavior, if I set the number of decimals to 0 in the Preferences for the Units.
I had than this effect, even if I had a visible setting of 2 in the preferences. So this may be due to a missing synchronization of the setting with the displayed setting and may be the original reason for the bug report.

Nevertheless it is an annoying behavior, that input numbers are cut according to a display setting. So for me the bug-report is valid. This was not the case with Version 0.16.

Ulrich