I am considering a 3D model which will involve a revolving cylindrical object in the center. As for the physics, I suspect I will have to solve vectorial electromagnetic fields (hence Nedelec elements)
In old commercial tools, I would have used a disjoint geometry in which the mesh will rotate only in the revolving domain while that in the rest will be stationary.
I am wondering if there is anything in dolfinx which could make this kind of model challenging or impossible? To translate in dolfinx, I will have two adjacent but unfragmented domains, one of which will be rotating. I will have to enforce continuity conditions of the Maxwell’s equations at the interface between the two domains each of which will probably have different function spaces.
I will appreciate comments from knowledgeable users whether it sounds feasible and if there are existing models I could study.
Hi, without specifying the exact application, I am unable to suggest more than below. It would be much better if you share what you are aiming at. Thanks.
I want the mesh inside the circle to rotate while everything outside the circle will be stationary. As far as I see, I need to do the following:
Create two sub-domains from the geometry, one being the circle (and anything possibly inside it) and the other based on everything outside it.
Define two function spaces corresponding to each sub-domain, create a mixed element out of them and then somehow impose continuity of fields at the interface between the two domains. To start simple, let’s consider that each function space is scalar CG.
Make the mesh inside the circular domain rotate in time with a specified angular velocity while the mesh outside remains unchanged. This naturally means we will need to interpolate on non-matching meshes at the circular interface between the two domains.
About 1), I am unsure how to create subdomains in dolfinx preferably using physical tags in gmsh. I did find some examples using dolfin but it seems the MeshView function is not available in dolfinx. Will it help if instead of creating subdomains out of one combined geometry, I just create two different geometries for each subdomain from the beginning such that each have their own mesh, ct, and ft objects?
About 3), I do not get how to rotate a few selected domains. The suggested approach in another thread of using mesh.geometry.x[:,:] will apparently rotate everything which I do not want.
Thanks a lot for sharing interesting examples. I have managed to create submeshes out of my geometry. Further, it also turned out to be rather easy to rotate a submesh.
I am now wondering about how to solve the problem itself. To accommodate rotational aspect of my problem, I do not fragment the two submeshes in gmsh to all non-conformity at the mutual interface. As a consequence, the interface becomes an external boundary in both submeshes. Below is a zoom in:
I found an example using multiphenicx which can probably do what I need but it assumes the original interface to be internal (dS). I am struggling to understand if the example could be adapted to my situation where the interface is external for both submeshes (ds) and also non-conformal if it matters.
There is also an interesting example using dolfinx_mpc. I am unsure where it creates dofs pairs though. Since the mesh in my case is non-conformal, I wonder if it will cause problems with this approach? @dokken if you are reading, could you kindly clarify?
I’ve only ever used multiphenicsx with conforming meshes, i.e. the interface \Gamma in my tutorial you have linked is common between the subdomains \Omega_1 and \Omega_2.
That being said:
It will be hard to use multiphenicsx and dolfinx_mpc together, because each one of us customizes the assembly of matrices/vectors, so you would need the intersection of the two customizations.
multiphenicsx does not use submeshes. If you would like to try and mimick the dolfinx_mpc demo you linked you would have to construct \Omega_1 and \Omega_2 as two (slightly) separated subdomains in the same mesh (I’m looking at the gmsh part in the demo): however, that would mean that the interface \Gamma would be replaced by \Gamma_1 and \Gamma_2, which (even though their geometrical location may coincide) would be two distinct sets. This means that the lagrange multiplier \lambda in my tutorial would be replaced by \lambda_1 and \lambda_2. If you are able to come up with a weak formulation which states that:
\lambda_1 and \lambda_2 act as multipliers for the condition u_1 = u_2 on the interface, and
\lambda_1 and \lambda_2 must coincide on the interface
then you can formulate this in multiphenicsx. If not, then I doubt you’ll be able to use it. Honestly, I can’t come up myself with such a weak formulation, especially not on a day like today
Thanks a lot for your quick feedback. I recognize the circumstances
I am not looking to mix multiphenics with dolfinx_mpc. Whichever solves the problem would be welcome My hunch is that a weak-form based approach is more suitable. The real problem I am after is transient where the mesh will keep rotating.
I agree that it is two interfaces with non-conforming meshes and that they overlap geometrically. I am myself struggling to write a weak form for it. But then I am not well-grounded in this sort of stuff to begin with. I will be looking around and hopefully if something comes up I will get back to you!
I believe that a weak formulation for that case (using the same notations as in my previous post) would be one that you obtain from the minimization of the following energy J(u_1, u_2, \lambda_1, \lambda_2) = \int_{\Omega_1} |\nabla u_1|^2 + \int_{\Omega_2} |\nabla u_2|^2 + \int_{\Gamma_1} \lambda_1 (u_1 - \Pi_{2,1} u_2) + \int_{\Gamma_2} \lambda_2 (u_2 - \Pi_{1,2} u_1), where:
\Pi_{1,2} is an interpolation operator from \Gamma_1 to \Gamma_2, while \Pi_{2,1} is viceversa
after you formally differentiate w.r.t. u_1, u_2, \lambda_1, \lambda_2, you would still obtain a weak formulation that is linear, because \Pi_{\cdot, \cdot} are linear operators
It would be cool to have a tutorial in multiphenicsx showing this, since it would allow to move the library beyond its current mesh conformity assumption. I could work on it in the next few weeks, but before I start I would need:
a few people confirm that the formulation above is correct
some tips on how to use ufl.Interpolate with/without ffcx. I don’t expect ffcx will pick up the new ufl type, because I can’t see any changes picking it up after it has been introduced in ufl. Custom assemblers (like 1, 2, 3) might come in handy, but I’ve never used them before.
My hunch is that a weak-form based approach is more suitable. The real problem I am after is transient where the mesh will keep rotating.