On 7/22/06, **Roy Stogner** <roystgnr@ices.utexas.edu> wrote:

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?

Yes, that's a great idea.

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?

I might try it using python/numpy/scipy. Thanks for the great tips!

David

On Sat, 22 Jul 2006, David Xu wrote:

> On 7/22/06, Roy Stogner <roystgnr@ices.utexas.edu> 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 real-valued 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