Hi,
Yes, I have found that the code works with periodic boundaries if I don't
refine and it works if I use other boundary conditions with/without
refinement. I can try periodic boundaries and then refine every cell and
see what happens.
I understand it is almost impossible to find the problem
Hi,
There could be many reasons why your code is not working as expected. To
find the problem, try to make the simplify the code as much as possible.
For example, does the code fails if you don't use periodic boundaries? If
it fails, try to simplify even more, for example, don't use periodic
Hi Daniel,
The serial implementation of the code was exiting with error in the
function call to *GridTools::collect_periodic_faces()* so I was looking in
documentation for details on specifically that function. I see now that the
role of the '*direction*' argument is mentioned explicitly
Aaditya,
the documentation says
"[...] More precisely, faces with coordinates only differing in the
direction component are identified."
Hence, it is crucial to choose this correctly. For a cube with standard
coloring faces 2 and 3 share the x-coordinates so direction must be 1.
Best,
Daniel
Hi Mark,
Quick update. I tried running a simulation with an implementation using
the 'Triangulation' object instead and I face the same issue as earlier. It
returns the same error message as in the parallel case. Also, making the
change in the *direction* argument from 0 to 1 for the
Hi Mark,
Thank you for responding. I haven't tried using a standard
'Triangulation' object instead of its parallel counterpart. I will try
another implementation with the appropriate substitutions.
Based on some trials I ran since I posted the question, my code runs
without issues(even on
Hi Aaditya,
on first look your implementation looks good to me. Does the same error
occur when you are using a standard `Triangulation` object instead of a
`parallel::distributed::Triangulation`?
As far as I know, the direction parameter does not matter for scalar fields
(see also step-45).
Hello,
I came across this old thread, and successfully used the provided code in
my own code (https://github.com/l-korous/mhdeal) - thank you Andreas - and
I want to share how I used it:
- here are the (slightly changed) files provided by Andreas:
Dear Daniel,
I just resolved the problem. Because constraints.close function resolves
chains of constraints, It interfered with set_inhomogeinity process. So I
had to issue constraints.close before applying inhomogeinities.
Thank you very much for your helpful hints. I appreciate it.
Hamed
Dear Daniel,
> It seems that you are now constraining all the components, i.e.
> u_x(0,y)=u_x(L,y) and u_y(0,y)=u_y(L,y).
> Is this really what you want to do? Otherwise, you should have a
> ComponentMask in your call to
> DoFTools::make_periodicity_constraints as well, i.e.
>
> You are
Dear Daniel and Timo,
Thank you very much for your advises. I have figured out the problem with
the periodic constraints but I do not know where this problem comes from.
Let me explain the issue more. As I mentioned earlier, I have applied
periodic BC for displacement field and I want to apply
Dear Daniel,
> I would suggest you to look at the constraints in the ConstraintMatrix
> using ConstraintMatrix::print[1] for a mesh consisting of has few cells as
> possible.
> Using DoFTools::map_dofs_to_support_points[2] you can then verify that
> these are correct.
>
Issuing "
I just realized that the problem comes from that part of the code that
applies relative displacement between bottom and top faces, since there is
not corner element distortion when having u_x (0,y)=u_x(L,y)+delta_x and I
uncomment the second part of the code namely,
{
IndexSet
Dear Daniel,
I have applied periodic boundary condition on displacement field for a
square 2D domain and in order to apply boundary displacement I want to
consider relative displacement between pair faces, namely,
u_x (0,y)=u_x(L,y)+delta_x and u_y (x,0)=u_y(x,L)+delta_y , using
Daniel,
You are completely right. The problem was resolved applying your comment.
Thank you very much,
Hamed
--
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
Hamed,
[...]
> I am going to do the same as Bastian, namely periodic boundary condition
> for displacement such that u( 0, y ) = u( 1, y ) + *lambda ,*
> * so I used the recommended above code by Bastian for applying
> inhomogenity to predefined periodicity, in order to have reletive
>
Dear Bastian and Daniel,
> That's what I was assuming. So yesterday I did it with this code :
> // This block add to the periodicity constraint the little
> compression we want
> {
> IndexSet selected_dofs_left;
> std::set< types::boundary_id > boundary_ids_left=
Hej, I found the issue ... I forgot the line
constraints.distribute ( sol );
after the solution routine ... so it was just mainly a visualization issue.
Thanks for the quick response!
El jueves, 22 de septiembre de 2016, 19:26:28 (UTC+2), Daniel Arndt
escribió:
>
> Juan,
>
> [...]
>> 1)
Juan,
[...]
> 1) My first question is about how the "direction" works, is it 1
> correspond to "x" and 2 corresponds to "y"?
>
No, direction 0/1/2 means that the support_points of the dofs to be
identified just differ in the x-/y-/z-component.
What you are doing should be perfectly fine.
>
Daniel,
That's what I was assuming. So yesterday I did it with this code :
// This block add to the periodicity constraint the little
compression we want
{
IndexSet selected_dofs_left;
std::set< types::boundary_id > boundary_ids_left=
std::set();
I agree with Daniel. So in this case, you probably just need to change your
order of operations and set the boundary_id's before doing any refinement.
On Wednesday, June 8, 2016 at 2:07:09 AM UTC+2, Daniel Arndt wrote:
>
> Bastien,
>
> GridTools::collect_periodic_faces stores only the periodic
Bastien,
GridTools::collect_periodic_faces stores only the periodic faces on the
coarsest level.
This information is used in DoFTools::make_periodicity_constraints to
create the corresponding constraints
on the active set of DoFs.
My best guess would be that you don't set the boundary_ids on
Hi Jean-Paul,
Concerning the problem you've pointed out :
1. Ok, I'll take it into account. From now on, let's try to solve this
problem without local refinement. I do not do it anymore here.
2. Thanks for the advice, I've changed my checks.
3. I understand. However, I am almost sure that an
Hi Bastien,
There are a few potential problems here.
1. You're only refining cells along the top edge of your domain.
Periodic boundaries can only have a difference of 1 refinement level
between pairs of faces.
2. You may not be colouring any of your boundaries. This should be a
Hi Daniel.
Thank you for your answer, it worked well to enforce my periodic boundary
conditions on the 1D beam.
Thus, I'm back to the 2D neo-hookean case. Here is the code of my
*make_grid()* function :
template
void Solid::make_grid()
{
GridGenerator::hyper_cube(triangulation, 0.0,
25 matches
Mail list logo
