Divergence free velocity field small domains

[Wouter van Veen]

Hello everybody,

The past week I have been struggling to get a divergence free velocity field using the needs_divfree_projection option set to TRUE. In my previous post about the force fluctuations we went over a lot of options what the problem of the non-divergence free velocity field could be. In order to find out what the problem could be I decided to go back to basics. I have set up a case of a rotating cube. The cube is 10 times as small as the domain and is placed with one edge in the origin. The rotation is performed around the origin. I noticed that if I change the size of the domain (keeping the Reynolds number constant by changing the viscosity) that the divergence of the velocity field increases a lot (and is not the same shape).

I did two simulations one in a 1m by 1m domain and one in a 0.01 by 0.01 meter domain (scaling the cube accordingly). I kept the rotational velocity the same, only changing viscosity by a factor 1e4 to account for the change in size. The velocity fields scale really nicely by a factor 100. The vorticity is exactly the same. The divergence of the velocity field is however completely different (see the attached files) and I don't understand why.

So I think that either I don't understand correctly what the div(u) = 0 condition means or something goes wrong in computing and enforcing the divergence free velocity field. It appears that the divergence of the velocity field has no influence on the results which are both similar for each simulation. So now I have two questions:
- Is the divergence of the velocity field a good verification if the solver worked properly? and if the imposed velocities are correct?
- Is the divergence of the velocity field computed correctly within IBAMR and have other people found the same issues.

If it helps I can upload the two cases to a git repository or something. Let me know what is the best approach!

Thank you again for your help!

Wouter

[Amneet Bhalla]

On Thu, Dec 15, 2016 at 2:45 AM Wouter van Veen <wgva...@gmail.com> wrote:

Hello everybody,

The past week I have been struggling to get a divergence free velocity field using the needs_divfree_projection option set to TRUE. In my previous post about the force fluctuations we went over a lot of options what the problem of the non-divergence free velocity field could be. In order to find out what the problem could be I decided to go back to basics. I have set up a case of a rotating cube. The cube is 10 times as small as the domain and is placed with one edge in the origin. The rotation is performed around the origin. I noticed that if I change the size of the domain (keeping the Reynolds number constant by changing the viscosity) that the divergence of the velocity field increases a lot (and is not the same shape).

I did two simulations one in a 1m by 1m domain and one in a 0.01 by 0.01 meter domain (scaling the cube accordingly). I kept the rotational velocity the same, only changing viscosity by a factor 1e4 to account for the change in size. The velocity fields scale really nicely by a factor 100. The vorticity is exactly the same. The divergence of the velocity field is however completely different (see the attached files) and I don't understand why.

So I think that either I don't understand correctly what the div(u) = 0 condition means or something goes wrong in computing and enforcing the divergence free velocity field. It appears that the divergence of the velocity field has no influence on the results which are both similar for each simulation. So now I have two questions:
- Is the divergence of the velocity field a good verification if the solver worked properly? and if the imposed velocities are correct?

It is not necessary to set div(u) = 0 to impose velocity. The reason is the projection step occurs anyways in the next step. It also does not affect the dynamics, which explains the same velocity. All of these results are discussed in the JCP 2013 paper.

- Is the divergence of the velocity field computed correctly within IBAMR and have other people found the same issues. 

I am not sure what's going on here. It could be a solver issue or some scaling factors in GMRES. It could also be a plotting issue. Send me your code and I will take a look. At what timestep is this plot for non zero div(u) plotted? I will try to reproduce it during weekend.

If it helps I can upload the two cases to a git repository or something. Let me know what is the best approach!

Sure. Send me the repo link.

Thank you again for your help!

Wouter

--


You received this message because you are subscribed to the Google Groups "IBAMR Users" group.


To unsubscribe from this group and stop receiving emails from it, send an email to ibamr-users...@googlegroups.com.


To post to this group, send email to ibamr...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

[Amneet Bhalla]

On Thu, Dec 15, 2016 at 7:40 AM, Amneet Bhalla <mail2...@gmail.com> wrote:

It could also be a plotting issue.

I just looked into the code and it writes out norms of div(u) before and after projection in the log file

https://github.com/IBAMR/IBAMR/blob/master/src/IB/ConstraintIBMethod.cpp#L1881-L1901

Can you check your log file and make sure what you see in VisIt (norm of div(u)) is consistent with your log file

values?

--

--Amneet 

[Wouter van Veen]

I have shared the two test cases on github:

https://github.com/woutervanveen/ibamr_scale_test

Please let me know if it works and if you have any questions. In the log file I indeed see the same difference, that was my first indication that something was "wrong".

Wouter


Op donderdag 15 december 2016 17:05:00 UTC+1 schreef Amneet Bhalla:

[Amneet Bhalla]

Ok, I ran the small domain problem and observed the ksp convergence history. The GMRES solver is declaring convergence due to small value of preconditioned norm of the residual, while the relative norm is still high. If you change the norm type on command line -cib_ksp_norm_type unpreconditioned or use FGMRES solver instead of GMRES (which uses unpreconditioned norm type as default), you can run down the div(u) values to very small number. The command line for latter option is: -cib_ksp_type fgmres

P.S: You are using very dense Lagrangian mesh. We generally recommend 1 Lagrangian point per Eulerian cell for ConstraintIB. You using 3 Lag points per direction per cell (9 in total)  

--
You received this message because you are subscribed to the Google Groups "IBAMR Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ibamr-users+unsubscribe@googlegroups.com.

To post to this group, send email to ibamr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--Amneet 

[Wouter van Veen]

Thank you for running the cases! I will change the GMRES solver to FGMRES tomorrow and see how it performes. I noticed if I use a less dense grid that the velocity field is not smooth inside the object, I will change this back and see how everything performes.

Thank you for your help!

Wouter

Op zondag 25 december 2016 23:11:58 UTC+1 schreef Amneet Bhalla:

To unsubscribe from this group and stop receiving emails from it, send an email to ibamr-users...@googlegroups.com.

To post to this group, send email to ibamr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--Amneet 

[Wouter van Veen]

Dear all,

The solution suggested by Amneet works for me! I did notice that the pressure field changes drastically when changing the GRMES to FGRMES solver. When I compare the result of the FGRMES solver with the solution of the GRMES solver on the larger domain I see the same pressure field (off course scaled). The forces do not change significantly and the velocity and vorticity also remain the same. Is this the result which was expected?

Wouter

Op maandag 26 december 2016 21:51:50 UTC+1 schreef Wouter van Veen:

[Amneet Bhalla]

On Fri, Jan 6, 2017 at 3:23 AM, Wouter van Veen <wgva...@gmail.com> wrote:

The forces do not change significantly and the velocity and vorticity also remain the same. Is this the result which was expected?

Yes.

 Notice that projection to divergence free field does not affect the pressure field after momentum correction is done. It is not an issue of FGMRES vs GMRES, rather it was the solver non-convergence. If your system is badly scaled then there could be a large difference between preconditioned and unpreconditioned norm. You can still use GMRES solver but tell PETSc to use unpreconditioned norm to determine the convergence. 

--

--Amneet