|Subject:||Re: Terms on a physical line in 3D|
|Date:||Wed, 11 Nov 2020 14:15:18 +0100|
Dear Jean-François and Andriy,
The simplest way for the import in python of gmsh files with the activated option for the lower dimension elements is to define it as a new format, may be something as "gmsh_with_lower_dim_elt". I can add it, this is very simple to do.
On 11/11/2020 13:30, Andriy Andreykiv wrote:
Yes, I use a classical region to store the elements. A region with line elements is not different from any other region.
Regarding the numerical difficulties you're referring to, well, we didn't have singularities there.We also had a Neuman like term (mixed Dirichlet/Neuman condition that was switching depending on the solution, geomechanical sink), but no issues like yours.You might consider consulting Yves Renard about it. Maybe you can also use special shape functions in the 3D elements around your lines.For example, I know Getfem supports X-Fem and maybe you could enrich your solution with some asymptotic shape functions around the line elements.
On Tue, 10 Nov 2020 at 23:39, Jean-François Barthélémy <email@example.com> wrote:
Thank you very much Andriy. This is clear. It seems that the problem relies on the current limitation of import and not on the assembly implementation. However the documentation made me think that a region in a mesh of dimension N could only store elements of dimension N or faces of dimension N-1 bit not less and as the bricks require a region ID I was afraid that it would be a limitation although of course there is no fundamental problem in integrating lineic terms... In your problem, you also use a classical region ID to store your line terms, don't you?
Well other issues may arise from this kind of term defined on a line: indeed the solution induced by a Neumann lineic term is expected to take infinite values in the vicinity of the line (think about Green function in a conductive or elastic problem which varies as ln(r) close to the line or 1/r for a pointwise Neumann term). Then a linear or nonlinear term involving the local solution at the line itself and contributing to the matrix term (lhs) may cause problem or at least lead to an unreliable solution. Have you encountered such difficulties?
-------- Message d'origine --------De : Andriy Andreykiv <firstname.lastname@example.org>Date : 10/11/2020 22:10 (GMT+01:00)À : Jean-François Barthélémy <email@example.com>Objet : Re: Terms on a physical line in 3D
Unfortunately I don't work in Python interface, so I don't know. But yes, that's add_all_element_type flag.Alternatively, if your line mesh is very simple you could add these elements one by one to the volume mesh, in your Python code.
Yes yes, I'm quite sure the line elements will work in high level generic assembly. That's a generic Getfem behaviour. We're using Getfem in our company and we have boundary conditions,defined on line elements, embedded in a volumetric mesh. We define non-linear terms using high-level assembly on those line elements.
I suspect it's me or my colleague Liang Jin who actually introduced this flag, so that we can import these line elements, because the previous behaviour wasthat these line elements were always skipped.
So, yes, if you are able to recompile getfem and the interface that would be the simplest solution. You might choose to commit your changes to Getfem repo as well.
On Tue, 10 Nov 2020 at 19:13, Jean-François Barthélémy <firstname.lastname@example.org> wrote:
Thank you for your answer.
Is the flag that you mention the boolean "add_all_element_type" which is set to false by default in getfem_import.cc?
I should have mentioned that I was working with the python interface and it seems that this flag cannot be changed from the python interface. The current behavior is that a GMSH physical line is imported as the surface region containing convexes which have an intersection with the line, which is of course not what I need.
Anyway, do you suggest that I recompile getfem and the python API by setting a default true value for this flag in order to get the physical lines properly stored in a region? Afterwards you are sure that a "line" region would work in the high level generic assembly? If this is the case, I wonder why the developers have set this flag to the default false value, do you know why?
Thank you very much
Le mar. 10 nov. 2020 à 16:57, Andriy Andreykiv <email@example.com> a écrit :
Yes, this is possible. It was routinely done before.
You need to have your 3D mesh AND line elements explicitly defined (Getfem doesn't have edges of volume elements as entities).You could use GMSH for that or define the mesh in your code. In GMSH you can assign physical domains to all elements, including your line elements.During the import of your GMSH mesh you would need to set somewhere a flag "not to ignore lower dimension elements", so that your lines are getting properly imported.After importing GMSH mesh into getfem::mesh and having region ID's for the volume as well as for the line elements you can define their interpolations (getfem::mesh_fem),integration methods (getfem::mesh_im), create a getfem::model, add unknown variables and use higher order assembly to define your nonlinear terms.
On Tue, 10 Nov 2020 at 16:29, Jean-François Barthélémy <firstname.lastname@example.org> wrote:
Dear Getfem users,
I have a 3D mesh in which physical lines are identified (ie set of edges). These lines may be on the boundary or in the interior of the domain.
I would like to build a model incorporating (linear and even nonlinear) terms on these lines (ie integration domain of dimension m.dim()-2). This could be used for example to model a concentrated line of current injection in an electric ohmic problem (rhs term) or a lineic domain of high conductivity (contributing then to the matrix term). Is there any way to do so in Getfem?
Thank you in advance
-- Yves Renard (Yves.Renard@insa-lyon.fr) tel : (33) 04.72.43.87.08 INSA-Lyon 20, rue Albert Einstein 69621 Villeurbanne Cedex, FRANCE http://math.univ-lyon1.fr/~renard ---------
|[Prev in Thread]||Current Thread||[Next in Thread]|