Application of internal velocity boundary conditions

[djbower]

Documenting a relevant conversation from July 31st 2013 with Shijie Zhong:
I think that you both are doing right and reasonable thing here about internal BCs. I have a visiting scholar who has worked a bit on this (for a 2D code), and to use the multi-grid solver, we basically had to put the internal boundary in a grid at the finest level that can be "seen" at every level of sub-grids. This is essentially similar to what Dan has seen.
Dan: if you have to stick with multigrid and do not want to deal with c-g solver, one thing you can try is to use less layers of sub-grid (i.e., to use relatively large number of elements at base level). It may help balance the speed and griding consideration.

Good luck,

Shijie

Hi Dan and Lijun,
FMG should be much much faster than CG. However, the internal vbc need to be seen by the FMG for it to be effective. It sounds like that in Dan's implementation, the internal vbc are only seen by the top two levels of the grids. Depending on the geometry of the internal vbc, it is also challenging for FMG to see every level of grids.
Shijie

[djbower]

Dan Bower [email protected] Tue, 23 Jul 2013, 05:22
to cig-mc
Hi CIG,
I have a CitcomS developer question relating to internal velocity boundary conditions. Broadly speaking, this is what I am doing (for each timestep):
(1) read in internal velocity bcs from file (2) update NODE[level][m][nodel] (turning VBs on, SBs off). This requires a bit of work to be consistent with the multigrid solver, but I think I have that sorted. (3) recall 'get_bcs_id_for_residual' to update zero_resid[level][m][j] and E->num_zero_resid[level][m]
This algorithm appears to work well for simple regional cases (simple meaning, e.g., applying internal velo bcs to a line of nodes at a fixed depth). For global cases, with a more complicated distribution of internal bcs, the solver does not converge (I'm testing with an isoviscous model to keep it simple), e.g.:
Momentum equation force 9.832610840e+04 * residual (050) = 5.075e+04 from 9.833e+04 to 4.916e+02 in 71.19 secs Warning: solver not converging! 0 (000) 71.3 s v=1.245233e+04 p=0.000000e+00 div/v=1.72e+01 dv/v=1.00e+00 dp/p=1.00e+00 step 0 * residual (050) = 1.313e+03 from 4.688e+04 to 4.916e+02 in 71.37 secs Warning: solver not converging! 1 (001) 142.7 s v=7.169507e+03 p=4.552888e+05 div/v=6.55e+00 dv/v=1.26e+00 dp/p=1.00e+00 step 0 * residual (050) = 1.661e+06 from 2.424e+04 to 4.916e+02 in 71.74 secs Warning: solver not converging! 1
Therefore, I have a couple of questions:
(1) I am missing something from my algorithm in 1-3 above?
(2) Does anyone have any guiding principles in applying internal velocity bcs such that a solver (particularly the multigrid in CitcomS) will converge?
Thanks in advance for any suggestions,
Dan
Dan,
You will need to call construct_id() after step (2) to update the id array as well.
Eh
Hi Dan,
In principle, none of get_bcs_id_for_residual() and construct_id() would affect the convergence, because they only affect the value of the global norm of residual, not the convergence.
It is probably still related to 1) how NODE array is set up and 2) how the multigrid solver works together with the internal nodes on which you specified velocities. Since you said that you are quite confident with NODE array, the trouble could be with 2) which is quite tricky, given that at different level of grid, you want that the internal nodes are represented somewhat (ideally), so that the smoothing/projection between different levels does not suddenly jump from seeing the internal nodes to not.
As a first step, I suggest that you switch on conj-grad solver to see what happens. In this way, you can narrow on the cause of the troubles.
Cheers,
Shijie
Hi Shijie, Eh, CIG,
Thanks for your suggestions. The CG solver works in principle (i.e., it jumps through the hoops and returns numbers, although I need to fine-tune my method to achieve better convergence). I think Shijie is right that the interpolation / coarsening might be causing problems. I'll keep exploring!
Thanks,
Dan

[djbower]

An important function to look over is: internal_velocity_bc in lib/BC_util.c. This is the main driver of the internal velocity boundary conditions, and incorporates the suggestions in the above threads. Perhaps it can be improved further though?