From: David Knezevic <dknezevic@se...>  20130529 20:45:29

In order to model a "film resistance" thermal interface condition, I'm using a mesh with a "crack", and I need to assemble an interface term on the crack. More precisely, I have two mesh subdomains, \Omega_1 and \Omega_2, with coincident boundaries, but which are not connected in the FE sense. Let \Gamma denote the coincident boundary. The term on \Gamma takes the form: \int_\Gamma (u_1  u_2) (v_1  v_2) ds, where u_1, u_2 (resp. v_1, v_2) are the trial (resp. test) functions on either side of \Gamma. This term looks much like an interface term in DG, and I've assembled it using an approach similar to miscellaneous_ex5 (note: I'm using C0 basis functions, but of course the solution is discontinuous across \Gamma). However, when I call solve, I get: [0]PETSC ERROR:  Error Message  [0]PETSC ERROR: Argument out of range! [0]PETSC ERROR: New nonzero at (203,206) caused a malloc! This isn't surprising since the interface term introduces new nonzeros in the sparsity pattern. In order to make this work, it seems I just need to:  Augment the sparsity pattern  Augment the send_list (for it to work in parallel) I see that dof_map has functionality for doing this "augmentation", so I'm going to try those functions out. But also I was wondering if anyone has any example code that demonstrates this, or any comments/suggestions, in case there are any "gotchas" with this type of thing? Also, if there's interest, I'd be happy to use this model problem to make a new libMesh example, since it exercises some functionality that may be worthwhile having in the example suite. David 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20130529 22:29:35

We do this in a thermal analysis code. I can send you some snippets if you like. I plan to add an example demonstrating this using nitsches method for nonmatched boundaries, but I'd be happy to have you beat me! Ben On May 29, 2013, at 3:45 PM, "David Knezevic" <dknezevic@...> wrote: > In order to model a "film resistance" thermal interface condition, I'm > using a mesh with a "crack", and I need to assemble an interface term on > the crack. > > More precisely, I have two mesh subdomains, \Omega_1 and \Omega_2, with > coincident boundaries, but which are not connected in the FE sense. Let > \Gamma denote the coincident boundary. The term on \Gamma takes the form: > > \int_\Gamma (u_1  u_2) (v_1  v_2) ds, > > where u_1, u_2 (resp. v_1, v_2) are the trial (resp. test) functions on > either side of \Gamma. > > This term looks much like an interface term in DG, and I've assembled it > using an approach similar to miscellaneous_ex5 (note: I'm using C0 basis > functions, but of course the solution is discontinuous across \Gamma). > > However, when I call solve, I get: > > [0]PETSC ERROR:  Error Message >  > [0]PETSC ERROR: Argument out of range! > [0]PETSC ERROR: New nonzero at (203,206) caused a malloc! > > This isn't surprising since the interface term introduces new nonzeros > in the sparsity pattern. In order to make this work, it seems I just > need to: >  Augment the sparsity pattern >  Augment the send_list (for it to work in parallel) > > I see that dof_map has functionality for doing this "augmentation", so > I'm going to try those functions out. But also I was wondering if anyone > has any example code that demonstrates this, or any > comments/suggestions, in case there are any "gotchas" with this type of > thing? > > Also, if there's interest, I'd be happy to use this model problem to > make a new libMesh example, since it exercises some functionality that > may be worthwhile having in the example suite. > > David > > >  > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application  at no cost. > Codelevel diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: David Knezevic <dknezevic@se...>  20130529 22:33:43

Snippets would be great, thanks! Also, once it's in good shape I'll make a pull request for a new example based on this. David On 05/29/2013 06:29 PM, Kirk, Benjamin (JSCEG311) wrote: > We do this in a thermal analysis code. I can send you some snippets if you like. > > I plan to add an example demonstrating this using nitsches method for nonmatched boundaries, but I'd be happy to have you beat me! > > Ben > > > > On May 29, 2013, at 3:45 PM, "David Knezevic" <dknezevic@...> wrote: > >> In order to model a "film resistance" thermal interface condition, I'm >> using a mesh with a "crack", and I need to assemble an interface term on >> the crack. >> >> More precisely, I have two mesh subdomains, \Omega_1 and \Omega_2, with >> coincident boundaries, but which are not connected in the FE sense. Let >> \Gamma denote the coincident boundary. The term on \Gamma takes the form: >> >> \int_\Gamma (u_1  u_2) (v_1  v_2) ds, >> >> where u_1, u_2 (resp. v_1, v_2) are the trial (resp. test) functions on >> either side of \Gamma. >> >> This term looks much like an interface term in DG, and I've assembled it >> using an approach similar to miscellaneous_ex5 (note: I'm using C0 basis >> functions, but of course the solution is discontinuous across \Gamma). >> >> However, when I call solve, I get: >> >> [0]PETSC ERROR:  Error Message >>  >> [0]PETSC ERROR: Argument out of range! >> [0]PETSC ERROR: New nonzero at (203,206) caused a malloc! >> >> This isn't surprising since the interface term introduces new nonzeros >> in the sparsity pattern. In order to make this work, it seems I just >> need to: >>  Augment the sparsity pattern >>  Augment the send_list (for it to work in parallel) >> >> I see that dof_map has functionality for doing this "augmentation", so >> I'm going to try those functions out. But also I was wondering if anyone >> has any example code that demonstrates this, or any >> comments/suggestions, in case there are any "gotchas" with this type of >> thing? >> >> Also, if there's interest, I'd be happy to use this model problem to >> make a new libMesh example, since it exercises some functionality that >> may be worthwhile having in the example suite. >> >> David >> >> >>  >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application  at no cost. >> Codelevel diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Libmeshusers mailing list >> Libmeshusers@... >> https://lists.sourceforge.net/lists/listinfo/libmeshusers 