Hi, sorry for this late reply. I missed it and realized just now. I found the problem, which is simply that if the whole system is fully periodic ( I mean, for example from plane to torus topology) then the 4 corners become effectively fixed (the other possibility would be rigid body motion). The fact that this 4 nodes become fixed, makes that when some eigenstrain is prescribed somewhere, unexpected stress appears close to the corners as the system can't fully relax there. I think this is something one was to live with. I didn't see it with other FEM packages because the solution suffered some post processing before I got it, which smoothed the result and somehow hide this.
On Monday, 2 June 2014 00:59:11 UTC+2, Wolfgang Bangerth wrote: > > On 05/28/2014 10:29 AM, David F wrote: > > Hello, my problem is the following: > > > > I prescribe an eigenstrain value in one element of the grid (i.e., an > inner > > element undergoes a certain transformation and this introduces strain > and > > stress in the rest of the grid), and everything works fine for normal > > boundaries and periodic boundaries. However, if one pays close > attention, for > > the periodic boundary solution in the corners of the grid one can see > some > > parasitic stress that shouldn't be there. > > > > I think the reason is the following: prescribing, let's say, a shear > > eigenstrain in one element, the four corners (in 2D) of the grid deform > in > > opositte directions if the boundary is not periodic, therefore when it > is > > periodic the four corners are in fact "the same", and these 4 opposite > > displacements would add up to 0, effectively fixing the "corner node". > This > > seems to me a natural problem of FEM and periodicity, so I have no clue > how to > > correct this with code. > > > > I have used other FEM packages for solving exactly the same problem I > > described, and somehow this is not happening, so there must be a way to > avoid > > this. I am not sure if it has to do with my implementation of the > periodic > > boundaries, or maybe the way in which deal.ii deals with periodicity is > the > > reason, or maybe I have to apply some kind of postprocessing correction > of > > which I am not aware yet. > > > > Does anyone know why could this be? > > I don't know myself. Maybe someone else does. But I'd like to point out > that > using periodic boundary conditions is equivalent to looking at a problem > where > you have periodic array of sources. Is the element where you prescribe the > eigenstrain by chance close to a corner of your domain? If so, I would > expect > there to be some strain close to the opposite corner as well, simply > because > there is a source (outside your domain) close to that opposite corner. > > It may be worthwhile sending a picture that shows what you are observing. > > > > P.S.: my periodic boundary implementation is a direct extension of > step-45 and > > everything but these small parasitic stress in the corners is pretty > accurate, > > so probably a problem in the code is not reason. Should I try with > > DoFTools::make_periodicity_constraints or do you the problem will be > exactly > > the same? > > Hard to tell. It's probably worth a try. > > Best > W. > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@math.tamu.edu > <javascript:> > www: http://www.math.tamu.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
