RE: [Libmesh-devel] Regression in event logging?

[KIRK, BENJAMIN (JSC-EG) (NASA) <benjamin.kirk-1@na...>]

Well, if you see something stupid that may be worth asking about...
Sometimes something is implemented in an obvious way but through the course
of refactoring it becomes either un-obvious or inefficient.  In either case
pointing it out wouldn't hurt.  You can always ask off-list if you want to
be rude... :-)

If you do need to perform such an inversion I would suggest doing it through
the DenseMatrix class.  Right now it implements (by hand) lu factorization
without pivoting...  In reality, however, this method is really just a
placeholder for a call to LAPACK (which is guaranteed to be present if PETSc
is there) or replaced altogether with the Boost matrix implementation...

In either case, I assume this would need to be done once per element & you
can cache either the lu factorization or the solution?  Perhaps the data
could then be written to file so at least restarts are quick??

-Ben





-----Original Message-----
From: libmesh-devel-admin@...
[mailto:libmesh-devel-admin@...] On Behalf Of Roy Stogner
Sent: Thursday, November 18, 2004 4:19 PM
To: libmesh-devel@...
Subject: Re: [Libmesh-devel] Regression in event logging?


On Thu, 18 Nov 2004, Benjamin S. Kirk wrote:

> On another note, I'd really like to see the C1-continuous element 
> support
> make it in the library, so please don't hesitate to ask any questions you
may 
> have...

Most of my remaining questions would either be of the form "Why did you
implement this with method X instead of method Y" (for which the answer
would probably be either differing personal preferences or performance
optimizations I don't yet understand) or of the form "Why haven't you done
Z" (for which the answer would probably be "there's only so many hours in
the day").  In either case I'd feel rude asking.

So far John's been able to answer all of the real questions I've had, and my
major obstacle is that I'm finding places (the calculation of coefficients
for determining physical element shape functions as linear combinations of
master element shape functions) where 30 lines of elegant but grossly
inefficient Matlab code translates into 300 lines of efficient but grossly
inelegant C++.

That's just for the 2D macroelement, too - the equivalent function in 1D is
about 10 lines.  If 2D keeps taking forever to debug, then in 3D I'll
probably end up going the "slightly inelegant, moderately inefficient" route
of making Petsc do the work.  I suspect inverting a 40x40 matrix at every
element could eat into run time, though.
---
Roy


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines robust
object and relational technologies, making it a perfect match for Java,
C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

RE: [Libmesh-devel] Regression in event logging?

[KIRK, BENJAMIN (JSC-EG) (NASA) <benjamin.kirk-1@na...>]

Well, if you see something stupid that may be worth asking about...
Sometimes something is implemented in an obvious way but through the course
of refactoring it becomes either un-obvious or inefficient.  In either case
pointing it out wouldn't hurt.  You can always ask off-list if you want to
be rude... :-)

If you do need to perform such an inversion I would suggest doing it through
the DenseMatrix class.  Right now it implements (by hand) lu factorization
without pivoting...  In reality, however, this method is really just a
placeholder for a call to LAPACK (which is guaranteed to be present if PETSc
is there) or replaced altogether with the Boost matrix implementation...

In either case, I assume this would need to be done once per element & you
can cache either the lu factorization or the solution?  Perhaps the data
could then be written to file so at least restarts are quick??

-Ben





-----Original Message-----
From: libmesh-devel-admin@...
[mailto:libmesh-devel-admin@...] On Behalf Of Roy Stogner
Sent: Thursday, November 18, 2004 4:19 PM
To: libmesh-devel@...
Subject: Re: [Libmesh-devel] Regression in event logging?


On Thu, 18 Nov 2004, Benjamin S. Kirk wrote:

> On another note, I'd really like to see the C1-continuous element 
> support
> make it in the library, so please don't hesitate to ask any questions you
may 
> have...

Most of my remaining questions would either be of the form "Why did you
implement this with method X instead of method Y" (for which the answer
would probably be either differing personal preferences or performance
optimizations I don't yet understand) or of the form "Why haven't you done
Z" (for which the answer would probably be "there's only so many hours in
the day").  In either case I'd feel rude asking.

So far John's been able to answer all of the real questions I've had, and my
major obstacle is that I'm finding places (the calculation of coefficients
for determining physical element shape functions as linear combinations of
master element shape functions) where 30 lines of elegant but grossly
inefficient Matlab code translates into 300 lines of efficient but grossly
inelegant C++.

That's just for the 2D macroelement, too - the equivalent function in 1D is
about 10 lines.  If 2D keeps taking forever to debug, then in 3D I'll
probably end up going the "slightly inelegant, moderately inefficient" route
of making Petsc do the work.  I suspect inverting a 40x40 matrix at every
element could eat into run time, though.
---
Roy


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines robust
object and relational technologies, making it a perfect match for Java,
C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

RE: [Libmesh-devel] Regression in event logging?

[KIRK, BENJAMIN (JSC-EG) (NASA) <benjamin.kirk-1@na...>]

Yeah, that seems possible...  We already have --disable-optional, seems like
--enable-optional could be used to ./configure for everything.

-Ben

-----Original Message-----
From: libmesh-devel-admin@...
[mailto:libmesh-devel-admin@...] On Behalf Of John
Peterson
Sent: Thursday, November 18, 2004 4:09 PM
To: Benjamin S. Kirk
Cc: libmesh-devel@...
Subject: Re: [Libmesh-devel] Regression in event logging?


Benjamin S. Kirk writes:
 > John recently removed the build_inf_elem() member from the Mesh class, 
 > now it stands alone...  There was a mixup in a perflog call, should be 
 > straightened out now.  Sorry, I don't have --enable-perflog in my 
 > current build otherwise I'd have fixed this already.

Ooops...neither do I.  There really are a lot of --enable-foo commands these
days.  Any chance we could implement --enable-kitchen-sink to turn on
everything for development purposes? :)

-John




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines robust
object and relational technologies, making it a perfect match for Java,
C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

RE: [Libmesh-devel] Regression in event logging?

[Roy Stogner <roystgnr@ic...>]

On Thu, 18 Nov 2004, KIRK, BENJAMIN (JSC-EG) (NASA) wrote:

> If you do need to perform such an inversion I would suggest doing it through
> the DenseMatrix class.  Right now it implements (by hand) lu factorization
> without pivoting...

Hmmm... I need pivoting; there's no fixed ordering of the matrix rows
that can guarantee you won't have a zero on the diagonal, and zero
diagonal entries are pretty much guaranteed to happen for elements
whose master->physical transformation is just a 90 degree rotation.
I suppose I only need it in a very limited sense; I could probably do
it by hand as the matrix is built without making the code too ugly.

> In reality, however, this method is really just a placeholder for a
> call to LAPACK (which is guaranteed to be present if PETSc is there)
> or replaced altogether with the Boost matrix implementation...

Have you seen any recent benchmarks of ublas?  It (like all the C++
linear algebra codes, unfortunately) occasionally had some trouble
keeping up with C/Fortran/Assembly code on a benchmark I ran across
recently:

http://www.linuxclustersinstitute.org/Linux-HPC-Revolution/Archive/PDF03/Mello_U.pdf

But this paper is nearly 2 years old now; the version of ublas they
tested apparantly even predates its addition to Boost.

> In either case, I assume this would need to be done once per element & you
> can cache either the lu factorization or the solution?

Right; the coefficients don't change until the geometry changes.

I don't think it would be worth caching, if only there were some way
to get a solver to take the sparsity pattern into account ahead of
time.  The 2D matrix, for instance, only has 36 (out of 144) non-zero
entries, and only 3 of those are above the main diagonal.  3D will
have many more above-diagonal entries, but the sparsity ratio should
be even better.

What would be ideal is if there were some sort of trick that would
optimize the multiply-by-zero and optimize away the add-zero
operations.  I'd love to be able to write the code in matrix form,
write the sparsity pattern down as a constant, and make something like
that "C++ templates are Turing complete" magic do the rest.

> Perhaps the data could then be written to file so at least restarts
> are quick??

I don't think that's necessary, as long as they can be cached in RAM
elegantly.  Doing these inversions once per mesh refinement shouldn't
be a problem; it's just doing them once per linear solve that could
get ugly.
---
Roy