From: David Xu <dxu@my...>  20060723 02:31:40

On 7/22/06, Roy Stogner <roystgnr@...> wrote: > > On Sat, 22 Jul 2006, David Xu wrote: > > > On 7/22/06, Roy Stogner <roystgnr@...> wrote: > > > > Are you saying HEX27 and HEX8 will give same level of accuracy in the > > solutions if I don't need quadratic mapping functions? > > Yes. Just ccurious. Does the same rule apply to other types of element? What about Tet, Tri, Quad and Prism. So, is the level of solution accuracy independent with the number of node within the same type of element? What about the difference between different element types in terms of the effect on the quality of the solutions? > It's for solving 2 system matrices in a realvalued generalized eigenvalue > > problem. > > Okay, then the simplest workaround is clear: only build one matrix at > a time. As long as you're just writing them both out to files > anyway, there's no reason you need them both in RAM simultaneously. Yes, that's a great idea. > I went back and tried (30x30x30, HEX27, 3rd order HERMITE). This > > time it didn't blew out the memory, but did take significantly > > longer time to assemble the matrices than (30x30x30, HEX27, 2nd > > order LANGRANGE). Maybe HERMITE is the problem? > > Almost certainly it is. None of our finite element classes are as > optimized as they should be, but I think the Hermite elements may be > worse than average. > > Keep in mind, too, that even if they were equally optimized, the > Hermite assembly would be more expensive. If you're using the default > quadrature order (which is designed for nonlinear problems and may be > gross overkill for you) then I think quadratic hexes will be > calculating at 27 points and cubic hexes will be calculating at 64. That explains why the ouput filesize from hermite is much larger than lagrange. Does that mean, even the matrix dimension is the same, but hermit produces more entries in the matrix, thus it's less sparse? > How to assemble the element matrices outside of libmesh? > > Basically you'd almost do what libMesh does: create a big empty matrix > of the appropriate sparsity pattern, then loop though all the element > matrices and add their entries after looking up the global index for > each local degree of freedom. > > The only difference is that because you know you've got a uniform > grid, you could do that local>global lookup with a few equations > instead of the big data structures that general unstructured grids > require. > > > Do you know any existing code/program that can do that? So, that > > would be, output each element matrix to a file and a problem should > > be able to read in all the element matrices from the file and > > assemble them to system matrices. I'm definitely interested if this > > is doable. > > It's definitely doable, but I don't know of any existing code to do > it. I could script it up in Matlab pretty easily, but the Matlab > sparse matrix format sucks and so I wouldn't want to work with the > result. I might try it using python/numpy/scipy. Thanks for the great tips! David 