Re: [Libmesh-devel] Example code with upwinding

2008-08-12 Thread Adam C Powell IV
On Tue, 2008-08-12 at 17:31 -0500, Kirk, Benjamin (JSC-EG) wrote: > I will see about sending you a patch to ex9 demonstrating SUPG for a > scalar problem. John is right, for systems it gets a little too > complicated for an example... Thanks, I'd appreciate it! > > - Original Message - >

Re: [Libmesh-devel] Example code with upwinding

2008-08-12 Thread Kirk, Benjamin (JSC-EG)
I will see about sending you a patch to ex9 demonstrating SUPG for a scalar problem. John is right, for systems it gets a little too complicated for an example... -Ben - Original Message - From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: Adam C Powell IV <[EMAIL PROTECTED]> Cc: libmes

Re: [Libmesh-devel] Example code with upwinding

2008-08-12 Thread John Peterson
On Tue, Aug 12, 2008 at 5:15 PM, Adam C Powell IV <[EMAIL PROTECTED]> wrote: > [Sorry to post a -users message to -devel; I can't post to -users.] Interesting. I can see about adding you to the list, if you want? Or is it just an issue with your domain? > I have a very high-Peclet number advect

[Libmesh-devel] Example code with upwinding

2008-08-12 Thread Adam C Powell IV
[Sorry to post a -users message to -devel; I can't post to -users.] I have a very high-Peclet number advection-diffusion problem, and would like to use upwind differencing for the advection terms to reduce numerical diffusion. I don't see this in any of the libmesh examples, but the online galler

Re: [Libmesh-devel] Memory Leak in DofObject?

2008-08-12 Thread John Peterson
On Tue, Aug 12, 2008 at 10:17 AM, Benjamin Kirk <[EMAIL PROTECTED]> wrote: Especially when T is a char - that is 24 bytes on a x86_64 in overhead! >>> >>> Yeah, because of the pointers... I believe sizeof(char) is still 1 on >>> x86_64. That's pretty bad... >> >> A more feasible option might

Re: [Libmesh-devel] Memory Leak in DofObject?

2008-08-12 Thread Benjamin Kirk
>>> Especially when T is a char - that is 24 bytes on a x86_64 in overhead! >> >> Yeah, because of the pointers... I believe sizeof(char) is still 1 on >> x86_64. That's pretty bad... > > A more feasible option might be a single vector. Then take the > current char** and align it out in a strai