Defining faces as physical surfaces in Salome

Mesh generators, CAD programs, and other tools
mzenker
Posts: 1999
Joined: 07 Dec 2009, 11:49
Location: Germany

Re: Defining faces as physical surfaces in Salome

Post by mzenker »

Hi Tibi,

just curious: why do you want to migrate to Salome?

Matthias
tibich72
Posts: 63
Joined: 07 Dec 2009, 05:16

Re: Defining faces as physical surfaces in Salome

Post by tibich72 »

Hi Matthias,

We're doing thermal simulations of electronic circuits: we're building the 3D models, mesh them with Gmsh and then simulate them with Elmer. The complexity of some of the simulated components is too much for Gmsh to handle (crashes, incorrect meshes), so we thought that Salome is more robust for this type of components. We're probably keep Gmsh around, since it seems pretty fast for a lot of the simulations we're doing, but for more complicated models we're going to try to use Salome. What's your experience with Salome? Is there something I should be worried about?

Best,
Tibi
mzenker
Posts: 1999
Joined: 07 Dec 2009, 11:49
Location: Germany

Re: Defining faces as physical surfaces in Salome

Post by mzenker »

Hi Tibi,

I don't have any experience with Salomé, just heard that it is not (yet) considered to be really stable under Windoze. In gmsh, there is the problem that duplicated interfaces between adjacent volumes (or in 2D interface lines between surfaces) cannot be meshed with a conformal mesh (i.e. the nodes at the interface are not the same, so no heat/current can cross). If Salomé workes reliably under Windoze and can solve this kind of problems, I would also consider to migrate.

Best regards,

Matthias
tibich72
Posts: 63
Joined: 07 Dec 2009, 05:16

Re: Defining faces as physical surfaces in Salome

Post by tibich72 »

Hi Matthias,

Yes, the Windows version is not very stable, that's why we're considering using virtual Linux boxes on top of our Windows OS's to run Salome. As for identifying common faces/edges, Salome has the partition algorithm in there, that can identify these common faces -- after that, the mesh is conformal. However, I haven't used that algorithm too much -- it seemed quite slow on a few tests I've done. We have our own algorithms that identify these faces when building the 3D representation, so we don't need Salome's own.

Thanks,
Tibi
tibich72
Posts: 63
Joined: 07 Dec 2009, 05:16

Re: Defining faces as physical surfaces in Salome

Post by tibich72 »

Hi Peter,

I found something that could be the issue. I've been looking through the source code (in release/6.0/elmergrid/src) at file femfilein.c, line 3964:

Code: Select all

/* should this be physical property or material property? */
data->material[noelements] = physind;
OK, so first I've modified it to be matind instead of physind (a variable that stores the material read from the UNV field). No particular change, only that now it was solid #1 that was treated as a boundary condition instead of solid #2. Then, I've simply commented the whole line, and the output is what it should be:

Code: Select all

Elmergrid creating and manipulating meshes:
-------------------------------------------
Scaling mesh with vector [0.001 0.001 0.001]
Initial boundary interval [8,49]
boundary index changed 8 -> 1 in 60 elements
boundary index changed 9 -> 2 in 62 elements
boundary index changed 10 -> 3 in 92 elements
boundary index changed 11 -> 4 in 68 elements
boundary index changed 12 -> 5 in 76 elements
boundary index changed 13 -> 6 in 62 elements
boundary index changed 14 -> 7 in 56 elements
boundary index changed 15 -> 8 in 60 elements
boundary index changed 16 -> 9 in 60 elements
boundary index changed 17 -> 10 in 2776 elements
boundary index changed 18 -> 11 in 854 elements
boundary index changed 19 -> 12 in 70 elements
boundary index changed 20 -> 13 in 82 elements
boundary index changed 21 -> 14 in 114 elements
boundary index changed 22 -> 15 in 114 elements
boundary index changed 23 -> 16 in 94 elements
boundary index changed 24 -> 17 in 146 elements
boundary index changed 25 -> 18 in 282 elements
boundary index changed 26 -> 19 in 282 elements
boundary index changed 27 -> 20 in 234 elements
boundary index changed 28 -> 21 in 272 elements
boundary index changed 29 -> 22 in 1498 elements
boundary index changed 30 -> 23 in 1384 elements
boundary index changed 31 -> 24 in 10 elements
boundary index changed 32 -> 25 in 20 elements
boundary index changed 33 -> 26 in 20 elements
boundary index changed 34 -> 27 in 10 elements
boundary index changed 35 -> 28 in 26 elements
boundary index changed 36 -> 29 in 12 elements
boundary index changed 37 -> 30 in 12 elements
boundary index changed 38 -> 31 in 26 elements
boundary index changed 39 -> 32 in 22 elements
boundary index changed 40 -> 33 in 10 elements
boundary index changed 41 -> 34 in 10 elements
boundary index changed 42 -> 35 in 22 elements
boundary index changed 43 -> 36 in 106 elements
boundary index changed 44 -> 37 in 146 elements
boundary index changed 45 -> 38 in 110 elements
boundary index changed 46 -> 39 in 110 elements
boundary index changed 47 -> 40 in 146 elements
boundary index changed 48 -> 41 in 106 elements
boundary index changed 49 -> 42 in 998 elements
Mapping boundary types from [8 49] to [1 42]                  <---- no weirdness here
So, it seems that this might solve the problem. However, I've run ElmerSolver on the results with both the extra boundary condition and with this fix, and the results were exactly the same. So, there are two possibilities:
- The differences between the simulations on Gmsh and Salome meshes stem from something else and that bug/weirdness did not influence the results or
- The weirdness is still there and it still influences the results, even if it does not appear in the transcript

Hope this helps figuring out the problem. I'll try to work under assumption #1, but I think it may be worth looking sometime into this issue -- I don't know if such a crude solution as simply commenting an entire line that saves mesh data would not cause problems in some other places.

Thanks,
Tibi

PS. There are a couple of places in the code that are not correctly protected by the DISABLE_MATC (around feminfo.c:2515) and PARTMETIS (fempre.c:739) pragmas. To perform debugging, I had to create a Visual C++ project and wanted to disable metis and matc, but the code around those lines was still exposed after turning on DISABLE_MATC and turning off PARTMETIS. Again, I've been working on release 6.0 code.
tibich72
Posts: 63
Joined: 07 Dec 2009, 05:16

Re: Defining faces as physical surfaces in Salome

Post by tibich72 »

Hi Peter,

one more result that might help you with debugging the UNV import. I've written a custom .msh mesh exporter to write the Salome mesh in Gmsh format, which can then be read by ElmerGrid. The exporter is a Salome script which works with Salome's internal data structures and not with any exported mesh files. To test my results, I've set a simple case and conducted 3 experiments:
a) Mesh with Gmsh, write .msh
b) Mesh with Salome, write .msh
c) Mesh with Salome, write .unv

I've taken the results of (a) as base case, since those were the most trustworthy (at least according to my experience). The meshes in (b) and (c) were the same, just the output format was different. The weird thing was that, after importing them with ElmerGrid, the results of the simulation were different: (b) was about 2.7% off from base case and (c) was about 13.5% off from the base case for max temperature. 2.7% is not that bad, the quality of the mesh could have that influence on results; 13.5% seems much too different. In addition, it's worrisome that the simulation results of (c) and (b) were different for identical mesh and .sif file. This tells me that there's a problem with either the .msh or the .unv import in ElmerGrid -- however, considering that there are already strange things in the .unv import, the .unv case is more likely to have bugs.

Let me know if you'd like to look at the two mesh files.

Thanks,
Tibi
madstamm
Posts: 37
Joined: 07 Apr 2010, 09:56

Re: Defining faces as physical surfaces in Salome

Post by madstamm »

Dear Tibi,

This script for directly exporting msh files from Salome seems quite useful...
Do you have plans to make it publicly available?

Thank you and best regards,

Mike Stamm
tibich72
Posts: 63
Joined: 07 Dec 2009, 05:16

Re: Defining faces as physical surfaces in Salome

Post by tibich72 »

Hi Mike,

The script is not a very general Salome -> .msh translation. I'm pretty much assuming that the mesh consists only of triangles for faces and of tets for volumes, and that each face and volume is a group (or, in Gmsh parlance, physical faces and physical volumes). For my purposes, this sufficed. I'll have to clean up the script and will update it here, maybe someone else can complete it and make it a general translator between the two.

Best,
Tibi
madstamm
Posts: 37
Joined: 07 Apr 2010, 09:56

Re: Defining faces as physical surfaces in Salome

Post by madstamm »

Hi Tibi,

I think what you describe could suffice for a lot of simple things - certainly worth a test :)

Mike
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Defining faces as physical surfaces in Salome

Post by raback »

Hi
tibich72 wrote:I found something that could be the issue. I've been looking through the source code (in release/6.0/elmergrid/src) at file femfilein.c, line 3964:
Generally, the trunk version is preferable since we only work on it. The fixed revision is intended for special purposes, such as having fixed version for hardware benchmarking etc.

I did add the missing preprocessor instructions for Metis and Matc. Thanx for reporting!

-Peter
Post Reply