[petsc-users] want some explanations on BC setup
Hi, My objective is to write a primitive variable CFD solver based on SNES and TS. As a new user, I plan to start with the tutorial code snes/ex19.c by removing the temperature term. Then I can implement its equations and boundary conditions (BC) into the tutorial code ts/ex7.c for pseudo-transient. Finally I can switch to primitive variables. But I could not fully understand the BC setup in the tutorial codes and could not get a correct result by simply imitating the tutorial codes or my own attempts. 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) in which x[j][i].u is initialized as zero by other function. Why it's here - lid rather than + lid? How about if we use f[j][i].u = - lid or x[j][i].u = - lid ? And in my test runs with a modified ts/ex7.c with equations and BC from snes/ex19.c , only BC with x[j][i] = some numerical value can give a convergent result. 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? 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? Thank you very much. Best regards, Zhisong Li -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20100423/50c9a242/attachment.htm
[petsc-users] want some explanations on BC setup
On Fri, 23 Apr 2010 00:59:49 +, 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
[petsc-users] Building Sieve examples
Hello everybody, when looking for examples using Sieve for unstructured meshes I found these 3 (in http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/Mesh/MeshCreate.html): src/ksp/ksp/examples/tutorials/ex33.c.html http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/src/ksp/ksp/examples/tutorials/ex33.c.html src/ksp/ksp/examples/tutorials/ex35.c.html http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/src/ksp/ksp/examples/tutorials/ex35.c.html src/ksp/ksp/examples/tutorials/ex37.c.html http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/src/ksp/ksp/examples/tutorials/ex37.c.html I have built PETSc configuring --with-sieve successfully. Unfortunately trying to build these examples (make ex35) fails with error messages similar to the one below (and many more): /home/software/mpi/intel/openmpi-1.2.4/bin/mpicxx -o ex35.o -c -O -I/home/uhgd0053/petsc-3.1-p0//src/dm/mesh/sieve -I/home/uhgd0053/petsc-3.1-p0/externalpacka ges/Boost/ -I/opt/software/mpi/intel/openmpi-1.2.4/lib64 -I/home/uhgd0053/petsc-3.1-p0//withsieve/include -I/home/uhgd0053/petsc-3.1-p0//include -I/usr/X11R6/ include -I/home/uhgd0053/petsc-3.1-p0/withsieve/include -I/opt/software/mpi/intel/openmpi-1.2.4/lib64 -I/home/uhgd0053/petsc-3.1-p0/include/sieve -I/home/uhgd 0053/petsc-3.1-p0/externalpackages/Boost/ -I/home/software/mpi/intel/openmpi-1.2.4/include -D__INSDIR__=src/ksp/ksp/examples/tutorials/ ex35.c ex35.c(21): error: name followed by :: must be a class or namespace name PetscErrorCode MeshView_Sieve_Newer(ALE::ObjALE::Two::Mesh, PetscViewer); Without digging deeper into the code, are these examples still working with the current version of PETSc? What am I missing or where can I find up-to-date information? Thanks a lot, Stefan -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20100423/ded3766e/attachment.htm
[petsc-users] configure script for petsc
Hi all,
I'm trying to write a portable configure script for our software that uses
petsc, and needs to deal with petsc installations on a number of different
platforms. In petsc 3.0 I could do
make -f $(PETSC_DIR)/conf/base getlinklibs
and
make -f $(PETSC_DIR)/conf/base getincludedirs
that would work for both installed petsc and petsc in its own build directory
(provided PETSC_ARCH is set correctly of course). In petsc 3.1 conf/base seems
to have disappeared, is the best
way to deal with this to make my own little makefile:
include ${PETSC_DIR}/conf/variables
include ${PETSC_DIR}/conf/rules
and use make -f my_own_little_makefile getlinklibs instead?
Cheers
Stephan
[petsc-users] configure script for petsc
On Fri, 23 Apr 2010, Stephan Kramer wrote:
Hi all,
I'm trying to write a portable configure script for our software that uses
petsc, and needs to deal with petsc installations on a number of different
platforms. In petsc 3.0 I could do
make -f $(PETSC_DIR)/conf/base getlinklibs
and
make -f $(PETSC_DIR)/conf/base getincludedirs
that would work for both installed petsc and petsc in its own build
directory (provided PETSC_ARCH is set correctly of course). In petsc 3.1
conf/base seems to have disappeared, is the best
way to deal with this to make my own little makefile:
include ${PETSC_DIR}/conf/variables
include ${PETSC_DIR}/conf/rules
and use make -f my_own_little_makefile getlinklibs instead?
Yes - this way - you can add more stuff into this makefile - if needed.
If you just do getlinklibs and getincludedirs - then you can probably
just do:
make -f $(PETSC_DIR)/makefile getincludedirs
etc..
Satish
[petsc-users] configure script for petsc
Satish Balay wrote:
On Fri, 23 Apr 2010, Stephan Kramer wrote:
Hi all,
I'm trying to write a portable configure script for our software that uses
petsc, and needs to deal with petsc installations on a number of different
platforms. In petsc 3.0 I could do
make -f $(PETSC_DIR)/conf/base getlinklibs
and
make -f $(PETSC_DIR)/conf/base getincludedirs
that would work for both installed petsc and petsc in its own build
directory (provided PETSC_ARCH is set correctly of course). In petsc 3.1
conf/base seems to have disappeared, is the best
way to deal with this to make my own little makefile:
include ${PETSC_DIR}/conf/variables
include ${PETSC_DIR}/conf/rules
and use make -f my_own_little_makefile getlinklibs instead?
Yes - this way - you can add more stuff into this makefile - if needed.
If you just do getlinklibs and getincludedirs - then you can probably
just do:
make -f $(PETSC_DIR)/makefile getincludedirs
True, except the makefile doesn't make it into a prefix-installed
installation of petsc. Having my own makefile do it works fine -
was just checking if this is indeed the recommended way
Thanks a lot
Cheers
Stephan
etc..
Satish
--
Stephan Kramer s.kramer at imperial.ac.uk
Applied Modelling and Computation Group,
Department of Earth Science and Engineering,
Imperial College London
[petsc-users] configure script for petsc
On Fri, 23 Apr 2010, Stephan Kramer wrote:
Satish Balay wrote:
On Fri, 23 Apr 2010, Stephan Kramer wrote:
Hi all,
I'm trying to write a portable configure script for our software that uses
petsc, and needs to deal with petsc installations on a number of different
platforms. In petsc 3.0 I could do
make -f $(PETSC_DIR)/conf/base getlinklibs
and
make -f $(PETSC_DIR)/conf/base getincludedirs
that would work for both installed petsc and petsc in its own build
directory (provided PETSC_ARCH is set correctly of course). In petsc 3.1
conf/base seems to have disappeared, is the best
way to deal with this to make my own little makefile:
include ${PETSC_DIR}/conf/variables
include ${PETSC_DIR}/conf/rules
and use make -f my_own_little_makefile getlinklibs instead?
Yes - this way - you can add more stuff into this makefile - if needed.
If you just do getlinklibs and getincludedirs - then you can probably
just do:
make -f $(PETSC_DIR)/makefile getincludedirs
True, except the makefile doesn't make it into a prefix-installed
installation of petsc. Having my own makefile do it works fine -
was just checking if this is indeed the recommended way
Ah yes. There is no makefie that you can use in the prefix install. In
this case creating a temporary makefile is the way to go..
Satish
[petsc-users] want some explanations on BC setup
Hi, Jed, Thank you so much for these words. Actually I am working towards a 3D incompressible flow solver with finite volume method. So a driven cavity flow problem of finite difference will be a good starting point. 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. The order of scheme is not a big issue to me. The big troubles I can't work out are: 1. Direct removing temperature terms in snes/ex19.c doesn't give a sensible result except applying option -snes_mf or -snes_mf_operator. 2. Combining snes/ex19.c and ts/ex7.c (no temperature), I could not even get a converging SNES function norm or bounded result if I strictly follow your BC rules. But I can make it converged or bounded by setting BC like f[j][i] = - lid or x[j][i] = - lid with/without -snes_mf. I can send you my modified code (simple and straightforward) if you want. Thank you again. Regards, Zhisong Li
[petsc-users] want some explanations on BC setup
On Fri, 23 Apr 2010 16:01:21 +, Li, Zhisong (lizs) lizs at mail.uc.edu wrote: 1. Direct removing temperature terms in snes/ex19.c doesn't give a sensible result except applying option -snes_mf or -snes_mf_operator. DMMG normally computes the operator using coloring which is essentially the same operation as used for -snes_mf/-snes_mf_operator. You haven't given enough information to explain what's wrong. 2. Combining snes/ex19.c and ts/ex7.c (no temperature), I could not even get a converging SNES function norm or bounded result if I strictly follow your BC rules. But I can make it converged or bounded by setting BC like f[j][i] = - lid or x[j][i] = - lid with/without -snes_mf. I don't believe you are actually doing this since it will not converge: f[j][i] will never go to zero so the norm of the residual will not either. Jed
[petsc-users] want some explanations on BC setup
I don't believe you are actually doing this since it will not converge: f[j][i] will never go to zero so the norm of the residual will not either. Jed Actually here I mean putting only the equations and BC of snes/ex19.c into ts/ex7.c , not the exact program and no DMMG issue. I use x[j][i].u=0.0 or -lid as BC and it converges well. If I use f[j][i].u=x[j][i].u - lid ,x[j][i].u value at the boundary will grow up uncontrollably as time marches. 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. And for the driven cavity problem (snes/ex19.c), it's not fully Dirichlet boundary as omega on solid wall is not fixed and need to be determined. So we can never make IC consistent with BC for this case. You said it will normally be made consistent at the end of the first step I think this is not correct. Here is my test on ts/ex7.c: Change the IC value 0.0 at the boundary (line 249) as nonzero, say 1.5. Leave the BC as f[j][i]=x[j][i] unchanged or fix it as f[j][i] =0.0 (line 189) I also add VecView(x,PETSC_VIEWER_DRAW_WORLD); to view the result. You will find the steady state result completely different because of the IC. I really want go through this IC overwriting problem. Do you have any suggestion? Thank you again. Regards, Zhisong Li
