Discussion:
[Gmsh] double surfaces/lines between adjacent bodies
Zenker, Dr. Matthias
2009-03-11 14:21:15 UTC
Permalink
Hi Elmer and gmsh list,

I use gmsh and Elmer to simulate an electrical current flowing through a
conductive medium between two electrodes. I get the geometry from my CAD
colleagues in STEP format, import it in gmsh, mesh it, read the mesh
with Elmer and do the FEM calculation there. Most of the time, the
calculations are 2D. This works in principle, but there is the following
problem:
Electrode and medium have common surfaces (resp. lines in 2D). When I
get the geometry in STEP format, every part (Electrodes and Medium) has
its own outer surface (line). This leads to double surfaces (lines)
between the adjacent bodies. For geometry and mesh import, this is no
problem, neither for gmsh nor for elmer - the mesh is imported OK in
Elmer. But when I do the simulation, I see that no current flows through
this double surface (although only one of them is defined as physical in
gmsh, and only that one is seen in Elmer).
Removing the double surface/line in gmsh is rather tedious (Identify the
problematic regions where there is a double line between adjacent
surfaces. Delete at least one of the adjacent surfaces. Delete the
corresponding line at the interface. Delete its points. Redefine the
surface(s) which was (were) deleted before. It gets more complicated in
case of only partially overlapping lines which have to be partially
reconstructed.).

Question: How do I deal with this problem? Is there a more elegant (and
less time consuming) way than manual removal of the double lines? (The
autocoherence function in gmsh which is intended to remove double
duplicate entities in geometries is switched on, but does not seem to
have any effect.)
I imagine that this must be a known problem, since doing simulations
with geometries imported from 3D CAD systems is not so uncommon after
all.
Further it is not totally clear to me where the problem really comes
from. I suspect non-identical mesh nodes at the interface, which inhibit
current flow across the border.

Ideas and suggestions are more than welcome...

Thank you,

Matthias

----------------------------------------------------------------
ERBE Elektromedizin GmbH
Dr.rer.nat. Matthias Zenker
Dipl. Phys.
Grundlagenentwicklung Technologie
Waldhoernlestrasse 17
72072 Tuebingen
Phone + 49 7071 - 755 226
Fax + 49 7071 - 755 5226
mailto:***@ERBE-med.de
www.ERBE-med.de
----------------------------------------------------------------


_____________________________________________________________________
ERBE Elektromedizin GmbH
Firmensitz: 72072 Tuebingen
Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
Registergericht: Stuttgart HRB 380137
Peter Raback
2009-03-11 15:14:17 UTC
Permalink
Hi Matthias,

Do the lines share the same nodes?

If yes, then you could include the command line option '-merge eps' in the gmsh import in ElmerGUI/ElmerGrid. This will join nodes that are separated by a distance smaller than eps.

If no, this might be treated by ElmerSolver with the same functionality that is used for the periodic BCs, I think? But then you would have to have to have both lines existing so you can define a linear dependence between them.

BR, Peter

________________________________________
From: Zenker, Dr. Matthias [***@erbe-med.de]
Sent: 11 March 2009 16:21
To: ***@postit.csc.fi; ***@geuz.org
Subject: [Elmerdiscussion] double surfaces/lines between adjacent bodies

Hi Elmer and gmsh list,

I use gmsh and Elmer to simulate an electrical current flowing through a conductive medium between two electrodes. I get the geometry from my CAD colleagues in STEP format, import it in gmsh, mesh it, read the mesh with Elmer and do the FEM calculation there. Most of the time, the calculations are 2D. This works in principle, but there is the following problem:

Electrode and medium have common surfaces (resp. lines in 2D). When I get the geometry in STEP format, every part (Electrodes and Medium) has its own outer surface (line). This leads to double surfaces (lines) between the adjacent bodies. For geometry and mesh import, this is no problem, neither for gmsh nor for elmer - the mesh is imported OK in Elmer. But when I do the simulation, I see that no current flows through this double surface (although only one of them is defined as physical in gmsh, and only that one is seen in Elmer).

Removing the double surface/line in gmsh is rather tedious (Identify the problematic regions where there is a double line between adjacent surfaces. Delete at least one of the adjacent surfaces. Delete the corresponding line at the interface. Delete its points. Redefine the surface(s) which was (were) deleted before. It gets more complicated in case of only partially overlapping lines which have to be partially reconstructed.).

Question: How do I deal with this problem? Is there a more elegant (and less time consuming) way than manual removal of the double lines? (The autocoherence function in gmsh which is intended to remove double duplicate entities in geometries is switched on, but does not seem to have any effect.)

I imagine that this must be a known problem, since doing simulations with geometries imported from 3D CAD systems is not so uncommon after all.

Further it is not totally clear to me where the problem really comes from. I suspect non-identical mesh nodes at the interface, which inhibit current flow across the border.

Ideas and suggestions are more than welcome...

Thank you,

Matthias

----------------------------------------------------------------
ERBE Elektromedizin GmbH
Dr.rer.nat. Matthias Zenker
Dipl. Phys.
Grundlagenentwicklung Technologie
Waldhoernlestrasse 17
72072 Tuebingen
Phone + 49 7071 - 755 226
Fax + 49 7071 - 755 5226
mailto:***@ERBE-med.de
www.ERBE-med.de<file://www.ERBE-med.de>
----------------------------------------------------------------




ERBE Elektromedizin GmbH
Firmensitz: 72072 Tuebingen
Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
Registergericht: Stuttgart HRB 380137
Zenker, Dr. Matthias
2009-03-12 09:01:30 UTC
Permalink
Hi Peter,

that solves my problem, thank you very much!!
I just processed my test case successfully with the merge option.
The nodes were at least close together, maybe even on identical
coordinates, before the merge was done.
For more complicated cases (e.g. I want to merge nodes in a region where
the node spacing is larger than elsewhere): where can I find more info
(or an example) for the periodic BC thing?
Peter Raback
2009-03-12 20:37:23 UTC
Permalink
Hi,

There are some tests called periodic1 and periodic2 among the source files in trunk/fem/tests. These may show the sif file syntax.

The periodic conditions basically glue the values of two boundaries together so that the are the same. I don't know that this feature would have been used for internal boundaries but I see no reason why it wouldn't work. Maybe Juha as the author sees some? A practical problem is that if you want to glue two boundaries together at the same position it may be tricky with the GUI as its difficult to pick either one. But if you know the boundary indexing by some other means you might be able to write the sif manually.

BR, Peter

________________________________________
From: Zenker, Dr. Matthias [***@erbe-med.de]
Sent: 12 March 2009 11:01
To: Peter Raback; ***@postit.csc.fi; ***@geuz.org
Subject: RE: double surfaces/lines between adjacent bodies

Hi Peter,

that solves my problem, thank you very much!!
I just processed my test case successfully with the merge option.
The nodes were at least close together, maybe even on identical
coordinates, before the merge was done.
For more complicated cases (e.g. I want to merge nodes in a region where
the node spacing is larger than elsewhere): where can I find more info
(or an example) for the periodic BC thing?
Mark van Doesburg
2009-03-11 16:51:10 UTC
Permalink
Hello Matthias,

I have the same problem and am working on a solution. This solution
consists of an algorithm which uses OpenCASCADE to find all overlapping
vertices/edges and surfaces and merge them. This includes partial
overlaps.

With a partial overlap I mean for example a small edge with overlaps a
larger edge in the middle. The algorithm will split the longer edge in
three pieces and the overlapping section is merged. As similar method
is used to merge partially overlapping surfaces.

I was creating this as part of a BRL-CAD reader for gmsh, but it is
probably usefull for all OpenCASCADE models. Unfortunately it is not
yet finished.

regards,

Mark van Doesburg

"Zenker, Dr. Matthias" <***@erbe-med.de> wrote:

Hi Elmer and gmsh list,

I use gmsh and Elmer to simulate an electrical current flowing through a
conductive medium between two electrodes. I get the geometry from my CAD
colleagues in STEP format, import it in gmsh, mesh it, read the mesh
with Elmer and do the FEM calculation there. Most of the time, the
calculations are 2D. This works in principle, but there is the following
problem:
Electrode and medium have common surfaces (resp. lines in 2D). When I
get the geometry in STEP format, every part (Electrodes and Medium) has
its own outer surface (line). This leads to double surfaces (lines)
between the adjacent bodies. For geometry and mesh import, this is no
problem, neither for gmsh nor for elmer - the mesh is imported OK in
Elmer. But when I do the simulation, I see that no current flows through
this double surface (although only one of them is defined as physical in
gmsh, and only that one is seen in Elmer).
Removing the double surface/line in gmsh is rather tedious (Identify the
problematic regions where there is a double line between adjacent
surfaces. Delete at least one of the adjacent surfaces. Delete the
corresponding line at the interface. Delete its points. Redefine the
surface(s) which was (were) deleted before. It gets more complicated in
case of only partially overlapping lines which have to be partially
reconstructed.).

Question: How do I deal with this problem? Is there a more elegant (and
less time consuming) way than manual removal of the double lines? (The
autocoherence function in gmsh which is intended to remove double
duplicate entities in geometries is switched on, but does not seem to
have any effect.)
I imagine that this must be a known problem, since doing simulations
with geometries imported from 3D CAD systems is not so uncommon after
all.
Further it is not totally clear to me where the problem really comes
from. I suspect non-identical mesh nodes at the interface, which inhibit
current flow across the border.

Ideas and suggestions are more than welcome...

Thank you,

Matthias

----------------------------------------------------------------
ERBE Elektromedizin GmbH
Dr.rer.nat. Matthias Zenker
Dipl. Phys.
Grundlagenentwicklung Technologie
Waldhoernlestrasse 17
72072 Tuebingen
Phone + 49 7071 - 755 226
Fax + 49 7071 - 755 5226
mailto:***@ERBE-med.de
www.ERBE-med.de
----------------------------------------------------------------


_____________________________________________________________________
ERBE Elektromedizin GmbH
Firmensitz: 72072 Tuebingen
Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
Registergericht: Stuttgart HRB 380137
Zenker, Dr. Matthias
2009-03-12 08:10:47 UTC
Permalink
Hi Mark,

this would be exactly what I need...

Best regards,

Matthias

> -----Original Message-----
> From: Mark van Doesburg [mailto:***@technolution.nl]
> Sent: Wednesday, March 11, 2009 5:51 PM
> To: Zenker, Dr. Matthias; ***@geuz.org; ***@postit.csc.fi
> Subject: Re: [Gmsh] double surfaces/lines between adjacent bodies
>
> Hello Matthias,
>
> I have the same problem and am working on a solution. This
> solution consists of an algorithm which uses OpenCASCADE to
> find all overlapping vertices/edges and surfaces and merge
> them. This includes partial overlaps.
>
> With a partial overlap I mean for example a small edge with
> overlaps a larger edge in the middle. The algorithm will
> split the longer edge in three pieces and the overlapping
> section is merged. As similar method is used to merge
> partially overlapping surfaces.
>
> I was creating this as part of a BRL-CAD reader for gmsh, but
> it is probably usefull for all OpenCASCADE models.
> Unfortunately it is not yet finished.
>
> regards,
>
> Mark van Doesburg
>
> "Zenker, Dr. Matthias" <***@erbe-med.de> wrote:
>
> Hi Elmer and gmsh list,
>
> I use gmsh and Elmer to simulate an electrical current
> flowing through a
> conductive medium between two electrodes. I get the
> geometry from my CAD
> colleagues in STEP format, import it in gmsh, mesh it,
> read the mesh
> with Elmer and do the FEM calculation there. Most of
> the time, the
> calculations are 2D. This works in principle, but there
> is the following
> problem:
> Electrode and medium have common surfaces (resp. lines
> in 2D). When I
> get the geometry in STEP format, every part (Electrodes
> and Medium) has
> its own outer surface (line). This leads to double
> surfaces (lines)
> between the adjacent bodies. For geometry and mesh
> import, this is no
> problem, neither for gmsh nor for elmer - the mesh is
> imported OK in
> Elmer. But when I do the simulation, I see that no
> current flows through
> this double surface (although only one of them is
> defined as physical in
> gmsh, and only that one is seen in Elmer).
> Removing the double surface/line in gmsh is rather
> tedious (Identify the
> problematic regions where there is a double line
> between adjacent
> surfaces. Delete at least one of the adjacent surfaces.
> Delete the
> corresponding line at the interface. Delete its points.
> Redefine the
> surface(s) which was (were) deleted before. It gets
> more complicated in
> case of only partially overlapping lines which have to
> be partially
> reconstructed.).
>
> Question: How do I deal with this problem? Is there a
> more elegant (and
> less time consuming) way than manual removal of the
> double lines? (The
> autocoherence function in gmsh which is intended to
> remove double
> duplicate entities in geometries is switched on, but
> does not seem to
> have any effect.)
> I imagine that this must be a known problem, since
> doing simulations
> with geometries imported from 3D CAD systems is not so
> uncommon after
> all.
> Further it is not totally clear to me where the problem
> really comes
> from. I suspect non-identical mesh nodes at the
> interface, which inhibit
> current flow across the border.
>
> Ideas and suggestions are more than welcome...
>
> Thank you,
>
> Matthias
>
> ----------------------------------------------------------------
> ERBE Elektromedizin GmbH
> Dr.rer.nat. Matthias Zenker
> Dipl. Phys.
> Grundlagenentwicklung Technologie
> Waldhoernlestrasse 17
> 72072 Tuebingen
> Phone + 49 7071 - 755 226
> Fax + 49 7071 - 755 5226
> mailto:***@ERBE-med.de
> www.ERBE-med.de
> ----------------------------------------------------------------
>
>
>
> _____________________________________________________________________
> ERBE Elektromedizin GmbH
> Firmensitz: 72072 Tuebingen
> Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
> Registergericht: Stuttgart HRB 380137
>
>

_____________________________________________________________________
ERBE Elektromedizin GmbH
Firmensitz: 72072 Tuebingen
Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
Registergericht: Stuttgart HRB 380137
Mark van Doesburg
2009-03-12 08:48:02 UTC
Permalink
Hello Matthias,

I'll post it to the gmsh mailing list as soon as it is usable, I expect
that to be within two weeks. You will need to install OpenCASCADE to
compile it however.

regards,

Mark.


"Zenker, Dr. Matthias" <***@erbe-med.de> wrote:

Hi Mark,

this would be exactly what I need...

Best regards,

Matthias
Zenker, Dr. Matthias
2009-03-12 09:03:08 UTC
Permalink
How about including it into gmsh directly?

Matthias

> -----Original Message-----
> From: Mark van Doesburg [mailto:***@technolution.nl]
> Sent: Thursday, March 12, 2009 9:48 AM
> To: Zenker, Dr. Matthias; ***@technolution.nl;
> ***@geuz.org; ***@postit.csc.fi
> Subject: [Elmerdiscussion] Re: [Gmsh] double surfaces/lines
> between adjacent bodies
>
> Hello Matthias,
>
> I'll post it to the gmsh mailing list as soon as it is
> usable, I expect that to be within two weeks. You will need
> to install OpenCASCADE to compile it however.
>
> regards,
>
> Mark.
>
>
> "Zenker, Dr. Matthias" <***@erbe-med.de> wrote:
>
> Hi Mark,
>
> this would be exactly what I need...
>
> Best regards,
>
> Matthias
>

_____________________________________________________________________
ERBE Elektromedizin GmbH
Firmensitz: 72072 Tuebingen
Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
Registergericht: Stuttgart HRB 380137
Christophe Geuzaine
2009-03-12 19:46:30 UTC
Permalink
Zenker, Dr. Matthias wrote:
> How about including it into gmsh directly?
>

Indeed, if you have reliable code for duplicate entity removal in Open
Cascade we would be happy to integrate it into gmsh.

Another useful feature would be automatic splitting of partially
overlapping surfaces. This is something that happens quite a lot when
importing STEP models coming e.g. from Catia.

Christophe

> Matthias
>
>> -----Original Message-----
>> From: Mark van Doesburg [mailto:***@technolution.nl]
>> Sent: Thursday, March 12, 2009 9:48 AM
>> To: Zenker, Dr. Matthias; ***@technolution.nl;
>> ***@geuz.org; ***@postit.csc.fi
>> Subject: [Elmerdiscussion] Re: [Gmsh] double surfaces/lines
>> between adjacent bodies
>>
>> Hello Matthias,
>>
>> I'll post it to the gmsh mailing list as soon as it is
>> usable, I expect that to be within two weeks. You will need
>> to install OpenCASCADE to compile it however.
>>
>> regards,
>>
>> Mark.
>>
>>
>> "Zenker, Dr. Matthias" <***@erbe-med.de> wrote:
>>
>> Hi Mark,
>>
>> this would be exactly what I need...
>>
>> Best regards,
>>
>> Matthias
>>
>
> _____________________________________________________________________
> ERBE Elektromedizin GmbH
> Firmensitz: 72072 Tuebingen
> Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
> Registergericht: Stuttgart HRB 380137
>
>
> _______________________________________________
> gmsh mailing list
> ***@geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
>
>


--
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine
Brenda Ellen Make
2009-03-12 21:19:28 UTC
Permalink
Hi,

Please be careful not to tread on Rule 2: All engineering programs must
not have a smooth work-flow.

(There seems to be some question whether OpenCascade is really open at all?)

http://www.salome-platform.org/forum/?groupid=12&forumid=13&thread=1053
http://www.opencascade.org/occ/license/

Take Care,
Brenda

On 3/12/2009 2:03 AM, Zenker, Dr. Matthias wrote:
> How about including it into gmsh directly?
>
> Matthias
>
>
>> -----Original Message-----
>> From: Mark van Doesburg [mailto:***@technolution.nl]
>> Sent: Thursday, March 12, 2009 9:48 AM
>> To: Zenker, Dr. Matthias; ***@technolution.nl;
>> ***@geuz.org; ***@postit.csc.fi
>> Subject: [Elmerdiscussion] Re: [Gmsh] double surfaces/lines
>> between adjacent bodies
>>
>> Hello Matthias,
>>
>> I'll post it to the gmsh mailing list as soon as it is
>> usable, I expect that to be within two weeks. You will need
>> to install OpenCASCADE to compile it however.
>>
>> regards,
>>
>> Mark.
>>
>>
>> "Zenker, Dr. Matthias"<***@erbe-med.de> wrote:
>>
>> Hi Mark,
>>
>> this would be exactly what I need...
>>
>> Best regards,
>>
>> Matthias
>>
>>
> _____________________________________________________________________
> ERBE Elektromedizin GmbH
> Firmensitz: 72072 Tuebingen
> Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
> Registergericht: Stuttgart HRB 380137
>
>
> _______________________________________________
> gmsh mailing list
> ***@geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sci-Fi eBook focuses on War over Media Rights
http://www.brendamake.com/numbers/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Adam C Powell IV
2009-03-13 14:47:57 UTC
Permalink
On Thu, 2009-03-12 at 14:19 -0700, Brenda Ellen Make wrote:
> Hi,
>
> Please be careful not to tread on Rule 2: All engineering programs must
> not have a smooth work-flow.
>
> (There seems to be some question whether OpenCascade is really open at all?)
>
> http://www.salome-platform.org/forum/?groupid=12&forumid=13&thread=1053
> http://www.opencascade.org/occ/license/

FYI, Debian just accepted OCC last week into main after a four-month
review process. So a major distribution has endorsed Open CASCADE as
free software.

Whether it is GPL-compatible is an open question. Fortunately Elmer's
copyright statement has a GPL linking exception.

Hope this helps,
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
Continue reading on narkive:
Loading...