On Tue 2008-11-18 12:21, Roy Stogner wrote: > > We might actually also be able to do away with the _p_level as well > > if we are willing to impose some maximum p-level, say 16 or > > whatever... > > I have a fantasy where we some day support spectral elements with > FFT-based techniques to handle p in the 100s... but for now, 15 (4 > bits) would be more than adequate.
Having used p>1000 in 2D and p>100 in 3D, I don't think it's actually useful. The condition number goes like p^4 so you need to solve the linear systems to much higher tolerance than in a lower-order method. Modest order will easily let you hit machine precision and the memory access is nicer anyway. I do think matrix-free tensor products methods are very useful, I just don't think p>15 will ever be important. Anisotropic elements can be useful, for instance in stabilizing the inf-sup constant for high aspect ratio flows. If you store each part of the anisotropic order explicitly per-element, then they would each need some space so you're looking at 12 bits per element. My 3D implementation is completely different from libmesh and uses (1+4f)*sizeof(void*) per element regardless of order (where f is the number of approximation orders used---2 for a mixed Stokes system) plus a constraint matrix (DoF map). The connectivity needs to be present during setup, but then can be discarded. Jed
pgp32mKZt2MUZ.pgp
Description: PGP signature
------------------------------------------------------------------------- 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
