From: Benjamin S. Kirk <benkirk@cf...>  20040525 12:31:54

It would be possible to code a more generic loop, but in this case you might not want to... For the incompressible NavierStokes equations there are restrictions on stable approximation spaces for the velocity and pressures. In particular, secondorder velocities and first order pressures (like in ex13 are stable), but uniform first order is not. This choice of approximation spaces supports what are known as "checkerboard modes," which are nonphysical pressure oscillations. Right now ex13 assumes that there is a velocity degree of freedom at each node on the boundaries, and that is why the assert breaks when using firstorder velocities. In this case the QUAD9 element has 3 nodes per side, but only two have degrees of freedom. This could be fixed by augmenting the loop to have a test that looks for a DOF at that node... Regardless, the linear velocity is not stable (even with constant pressure), so you will still run into problems unless you "cheat" and throw in an artificial compressibility factor or something. Hope this helps, Ben Michael Schindler wrote: > Hello, > > first of all, I would like to say that I really like your libmesh > project and that it helps me a lot for doing numerics (and science). > > While learning how example 13 works I found a strange error message > which I would consider a bug: > After changing the elementorders of the variables "u" and "v" from > "SECOND" to "FIRST" > > >  diff output  > 110,111c110,111 > < system.add_variable ("u", FIRST); > < system.add_variable ("v", FIRST); >  > >> system.add_variable ("u", SECOND); >> system.add_variable ("v", SECOND); > >  > > then, the boundarysetting loop at lines 579 ff aborts with an > unsatisfied assertion (I have compiled the library in debugmode) > >  program output  > >>ex13: /usr/local/include/libmesh/dense_submatrix.h:227: >> Number & DenseSubMatrix<double>::operator ()(unsigned int, unsigned int): Assertion `i < this>m()' failed. >>Aborted > >  > > Some tracing with simple output shows that this happens at the > specified lines 579 ff. Maybe, it would be better to implement the > boundary with an integral similar to example 3 ? > > Best greetings, > Michael > 