Dear Yves and Andriy, Thank you very much for your answers and your solutions.
Best regards Jean-François Le mer. 11 nov. 2020 à 14:43, Yves Renard <yves.ren...@insa-lyon.fr> a écrit : > > ok, I added this possibility. > > Yves > > On 11/11/2020 14:15, Andriy Andreykiv wrote: > > Dear Yves, > > I agree, that would be the simplest solution. > Best regards, > Andriy > > On Wed, 11 Nov 2020 at 13:59, Yves Renard <yves.ren...@insa-lyon.fr> > wrote: > >> >> 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. >> >> Best regards, >> >> Yves >> >> >> >> >> On 11/11/2020 13:30, Andriy Andreykiv wrote: >> >> Jean-François, >> >> 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 <yves.ren...@insa-lyon.fr> >> 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 >> <http://getfem.org/userdoc/xfem.html#xfem> and maybe you could enrich >> your solution with some asymptotic shape functions around the line elements. >> >> Best regards, >> Andriy >> >> >> On Tue, 10 Nov 2020 at 23:39, Jean-François Barthélémy < >> jfrancois.barthel...@gmail.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? >>> >>> Best regards >>> Jean-François >>> >>> >>> -------- Message d'origine -------- >>> De : Andriy Andreykiv <andriy.andrey...@gmail.com> >>> Date : 10/11/2020 22:10 (GMT+01:00) >>> À : Jean-François Barthélémy <jfrancois.barthel...@gmail.com> >>> Objet : Re: Terms on a physical line in 3D >>> >>> Dear Jean-François, >>> >>> 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 was >>> that 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. >>> >>> Best regards, >>> Andriy >>> >>> On Tue, 10 Nov 2020 at 19:13, Jean-François Barthélémy < >>> jfrancois.barthel...@gmail.com> wrote: >>> >>>> Dear Andriy, >>>> >>>> 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 >>>> >>>> Best regards >>>> >>>> Jean-François >>>> >>>> >>>> >>>> >>>> Le mar. 10 nov. 2020 à 16:57, Andriy Andreykiv < >>>> andriy.andrey...@gmail.com> a écrit : >>>> >>>>> Dear Jean-François, >>>>> >>>>> 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. >>>>> >>>>> Best regards, >>>>> Andriy >>>>> >>>>> >>>>> >>>>> On Tue, 10 Nov 2020 at 16:29, Jean-François Barthélémy < >>>>> jfrancois.barthel...@gmail.com> 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 >>>>>> >>>>>> Best regards >>>>>> >>>>>> Jean-François Barthélémy >>>>>> >>>>>> >> -- >> >> Yves Renard (yves.ren...@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 >> >> --------- >> >> > -- > > Yves Renard (yves.ren...@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 > > --------- > >
