On Wed, 12 Nov 2008, Benjamin Kirk wrote: > Ah... right again. Right now find_neighbors() blows away all neighbor > information at the beginning, but I am about to change that for another > reason... (finishing the nemesis stuff).
Run your changes by me? find_neighbors() is probably where we need to fix the outstanding bug in ParallelMesh adaptive coarsening, too. > The only other thought that came to mind was on the issue of storing the > restriction/prolongation operators and associated memory overhead. For > single-valued systems it could easily ~double the total memory, provided you > store the same type of matrix at all levels. That was about my estimate, yeah. > If you have multiple unknowns, though, you might be able to do a lot better. > For compressible flows where we've got 2+NDIM unknowns, all approximated in > the same space, I'd think storing a single 'prototypical' > restriction/prolongation operator would work for all the unknowns, Yes, certainly. That would be a very good idea. > Even using Taylor-hood elements with incompressible flows you might be able > to do something clever - like store a single quadratic operator and do > something special to project the linear pressure using it (?) That, on the other hand, sounds like complicated overkill. ;-) --- Roy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
