search

precice / dealii-adapter

A coupled structural solver written with the C++ finite element library deal.II
GNU Lesser General Public License v3.0
19 stars 12 forks source link

including two flap case #39

Closed carme-hp closed 3 years ago

carme-hp commented 3 years ago

With this modifications, the dealii-adapter would support the tutorial case with two perpendicular flaps. Besides FSI3 and PF, now we have the case PFleft and PFright, who only differ from PF by the x coordinates in point_bottom and point_tip.

davidscn commented 3 years ago

@DavidSCN where can we modify the support_points? It looks like you call DoFTools::map_dofs_to_support_points() in adapter.h, but I am not sure what is going on under the hood. Maybe you have an idea?

I will have a look at the deal.II side later.

davidscn commented 3 years ago

Actually, we need an additional step: it looks like we pass the wrong vertices to setMeshVertices and each flap is still located in the middle.

How did you come to this conclusion? Running both cases works just as expected for me. How can I reproduce the issue?

MakisH commented 3 years ago

How did you come to this conclusion? Running both cases works just as expected for me. How can I reproduce the issue?

Exactly, here is the confusing part:

You can reproduce this by adding <export:vtk directory="preCICE-output" /> in the solid1 / solid2 participants in the precice-config.xml and loading the surface meshes in ParaView (and visualizing them e.g. with glyphs).

uekerman commented 3 years ago

Should we unify the definition of PF, PFleft and PFright to avoid the code duplication? In the end only the location in x direction is different, right?

davidscn commented 3 years ago

You can reproduce this by adding in the solid1 / solid2 participants in the precice-config.xml and loading the surface meshes in ParaView (and visualizing them e.g. with glyphs).

Done, looks for me reasonable. Also, selecting other files results in two separate beams.

Should we unify the definition of PF, PFleft and PFright to avoid the code duplication? In the end only the location in x direction is different, right?

Yes. I think a more general 'mesh interface' without the duplication in each code is even a better approach and should be added in case this becomes larger.

carme-hp commented 3 years ago

That's weird, in my case if I visualize in paraview the same files you did in the screenshot the flaps are located in the same position. Can this be a paraview related issue? in my case I use 5.7.0

davidscn commented 3 years ago

If you have doubts about paraview you could directly look into the vtks. Running head -n 20 Solid1_mesh-Fluid.init.vtk prints the following:

# vtk DataFile Version 2.0

ASCII

DATASET UNSTRUCTURED_GRID

POINTS 157 float 

-1.0500000000000000e+00  0.0000000000000000e+00  0.0000000000000000e+00
-1.0500000000000000e+00  5.5555555555555552e-02  0.0000000000000000e+00
-1.0500000000000000e+00  9.5929535914450782e-03  0.0000000000000000e+00
-1.0500000000000000e+00  2.7777777777777776e-02  0.0000000000000000e+00
-1.0500000000000000e+00  4.5962601964110471e-02  0.0000000000000000e+00
-9.4999999999999996e-01  0.0000000000000000e+00  0.0000000000000000e+00
-9.4999999999999996e-01  5.5555555555555552e-02  0.0000000000000000e+00
-9.4999999999999996e-01  9.5929535914450782e-03  0.0000000000000000e+00
-9.4999999999999996e-01  2.7777777777777776e-02  0.0000000000000000e+00
-9.4999999999999996e-01  4.5962601964110471e-02  0.0000000000000000e+00
-1.0500000000000000e+00  1.1111111111111110e-01  0.0000000000000000e+00
-1.0500000000000000e+00  6.5148509147000627e-02  0.0000000000000000e+00

and head -n 20 Solid2_mesh-Fluid.init.vtk the following:

# vtk DataFile Version 2.0

ASCII

DATASET UNSTRUCTURED_GRID

POINTS 157 float 

9.4999999999999996e-01  0.0000000000000000e+00  0.0000000000000000e+00
9.4999999999999996e-01  5.5555555555555552e-02  0.0000000000000000e+00
9.4999999999999996e-01  9.5929535914450782e-03  0.0000000000000000e+00
9.4999999999999996e-01  2.7777777777777776e-02  0.0000000000000000e+00
9.4999999999999996e-01  4.5962601964110471e-02  0.0000000000000000e+00
1.0500000000000000e+00  0.0000000000000000e+00  0.0000000000000000e+00
1.0500000000000000e+00  5.5555555555555552e-02  0.0000000000000000e+00
1.0500000000000000e+00  9.5929535914450782e-03  0.0000000000000000e+00
1.0500000000000000e+00  2.7777777777777776e-02  0.0000000000000000e+00
1.0500000000000000e+00  4.5962601964110471e-02  0.0000000000000000e+00
9.4999999999999996e-01  1.1111111111111110e-01  0.0000000000000000e+00
9.4999999999999996e-01  6.5148509147000627e-02  0.0000000000000000e+00

so that I can directly identify the left and the right flap respectively.

carme-hp commented 3 years ago

Thanks! It is indeed smt related to paraview, when I open the files I see same as you:)

MakisH commented 3 years ago

@carme-hp can it maybe be that the files were out-of-date? What if you completely remove the precice-output directory and run again?

MakisH commented 3 years ago

Should we unify the definition of PF, PFleft and PFright to avoid the code duplication? In the end only the location in x direction is different, right?

Good point. Maybe we could just make the location a parameter in the deal.II adapter?

carme-hp commented 3 years ago

@MakisH you are right! I could visualize it correctly when I completely removed the precice-output and run again. Sorry about the confusion. Maybe we could add the precice-output directory to the Allclean to avoid this problem happening again?

MakisH commented 3 years ago

Maybe we could add the precice-output directory to the Allclean to avoid this problem happening again?

Yes, let's do that!

MakisH commented 3 years ago

I have (not yet) introduced a format checker, but I think the PR doesn't use the .clang-format of this repo. So please format the PR and maybe rebase your branch to the current develop branch.

@DavidSCN This needs some documentation. Related issue: https://github.com/precice/dealii-adapter/issues/42

davidscn commented 3 years ago

Nice as well: this change is backwards-compatible. I did not need to update the tutorials to run it.

Are you sure with this? If we change the parameter file, we also need to change it in the tutorials. Maybe we can define here a default value in order to avoid it. In addition, we need to update the parameter files in this repository.

MakisH commented 3 years ago

Nice as well: this change is backwards-compatible. I did not need to update the tutorials to run it.

Are you sure with this? If we change the parameter file, we also need to change it in the tutorials. Maybe we can define here a default value in order to avoid it. In addition, we need to update the parameter files in this repository.

I thought there was already a default value. If not, there should be. Does it not run out-of-the-box for you?

carme-hp commented 3 years ago

so I put 0.0 as the default value for the flat location, which is the location that we had before. So I expect it works backwards (it did for the flapperpendicular2D case)

davidscn commented 3 years ago

Ah ok, perfect!

Am 17. Dez. 2020, 15:44, um 15:44, carme-hp notifications@github.com schrieb:

so I put 0.0 as the default value for the flat location, which is the location that we had before. So I expect it works backwards (it did for the flapperpendicular2D case)

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/precice/dealii-adapter/pull/39#issuecomment-747480459

davidscn commented 3 years ago

...so that we can see the result of the indentation check..