On Mon, Nov 18, 2013 at 4:39 PM, Jed Brown <[email protected]> wrote: > Geoffrey Irving <[email protected]> writes: > >> The seems to be a typo in the abstract: >> >> This effect typically limits order to at most *quadratic*, despite >> the favorable accuracy and stability properties offered by *quadratic* >> and higher order discretization > > I guess it sounds funny, but quadratic is the crossover point: too > expensive according to many people, but required by others.
The first real simulation I'm going to run once I get set up will need accurate bending, so I'm now in the latter camp. >> The index notation was the whole point, incidentally, since it >> transparently defines the order of array dimensions in the code. > > Okay, that is a convention that I think you got right, but there are > vectorization reasons to change it in some settings, so if you're going > to build something significant, it would be worth hedging against index > ordering changes. Changing it later will be easy if I have working code to compare against. >> With the current setup I think they need to be arrays of function >> pointers since different fields can live in different function spaces >> and have different quadrature rules. However, the g0,g1,g2,g3 could >> be single arrays, and you could merge all f0,f1,g0,g1,g2,g3,g4 into a >> single array of function pointers for simultaneous residual+Jacobian >> evaluation. Compacting it into a single function pointer always would >> require forcing the use of a single global quadrature rule. I don't >> know if that would ever be a problem. > > Terms would be grouped by quadrature rules, with one function per > quadrature rule. The user would be free to split that evaluation into > parts. If you have two quadrature rules and both need the material > properties, the properties need to be evaluated at both quadrature > rules. That seems reasonable. I don't imagine the support for multiple quadrature rules would get used very much. Geoffrey
