[petsc-users] want some explanations on BC setup

[Jed Brown]

On Fri, 23 Apr 2010 00:59:49 +0000, "Li, Zhisong (lizs)" <lizs at mail.uc.edu> wrote:
>  Hi,
> 
> My objective is to write a primitive variable CFD solver based on SNES
> and TS.

Compressible or incompressible flow?  Is a 2D (topologically) structured
grid sufficient?

> Finally I can switch to primitive variables.

As you may know, discretization is usually significantly different for
shocks or incompressibility, so this won't necessarily be an easy step.
The main reason velocity-vorticity is popular for 2D incompressible flow
is that simple (non-staggered/mixed) discretizations just work.  Also
note that the ex19 discretization is excessively diffusive at high
Reynolds number.  I'm just warning that this transition to primitive
variables involves a lot of choices and may involve complications like
staggered grids and/or TVD spatial discretizations.

> PETSc usually defines F as the function vector and X as solution
> vector. In snes/ex19.c, the BC are setup by manipulating arrays
> pointing to F and X, such as:
> 
> f[j][i].u = x[j][i].u - lid; (line 297)

This is the residual, at convergence, you will see f[j][i].u = 0, or in
other words, x[j][i].u = lid.

> in which x[j][i].u is initialized as zero by other function.

This is an "impulsive start" to the steady-state problem, the initial
condition does not satisfy the boundary conditions.

> Why it's here " - lid" rather than "+ lid"? How about if we use "
> f[j][i].u = - lid " or " x[j][i].u = - lid "?

Hopefully the explanation above explains this.  You aren't normally
supposed to modify the solution vector X in residual evaluation, but
this condition will usually be satisfied identically after the first
iteration.

I think that, at least in some cases, it is okay to project the solution
vector during residual evaluation, but this is more relevant for
variational inequalities and causes additional complications about what
the Jacobian should look like (it won't work correctly with colored or
matrix-free finite difference Jacobians), so I don't recommend it.

> I also found that in TS codes an initial condition at the boundary
> will overwrite the BC setup if they are of different values. Is this a
> bug?

In the appropriate function-space setting, Dirichlet boundary values are
not even part of the solution space (they are known and thus not
something you need to solve for).  There are a variety of ways to
enforce Dirichlet conditions without removing them from the function
space, I don't know what specifically you are asking about TS examples,
but if you use an initial condition that is incompatible with Dirichlet
boundary conditions, it will normally be made consistent at the end of
the first step (we don't have support for automatically determining
consistent initial conditions, this is more of an issue for DAE and
something I plan to address eventually).

> I think TS is something like a structure, but I cannot find
> descriptions of its members like "step","ptime" and "v" in any
> document. To run a TS simulation successfully, does it require a
> NORM_2 of "v" converge?

TS is a class much like SNES and KSP.  It sounds like you are asking
about ex7's MyTSMonitor(), to understand the meaning of it's arguments,
you can refer to the TSMonitorSet() documentation

  http://mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/TS/TSMonitorSet.html

In addition to these arguments, you can query other properties through
the TS.

Jed