From: Ingo Schmidt <ingo.schmidt@tu...>  20070214 12:38:09

Hi all, I'm looking for someone with experience applying libmesh to nonlinear structural dynamics, e.g. material and/or large displacements/strains who could answer me some (essential and specific) questions? a) Which "System" (DiffSystem(FEMSystem), NonLinImplicit, TransientSystem) is the best choice? b) It seems that the FEMSystem is in principle a really good framework, but are the necessary changes to consider e.g. the second time derivatives, other time stepping schemes etc. feasible without destroying the given FEMSystem structure? c) I started with the linear case of the problem using the newmarksystem which is inherited from the LinearImplicitSystem class. Is there a chance to extend/use (parts of) my existing code with one of libmesh nonlinear Systems? My specific problem is a numerical model (FEM) for the analysis of dynamic interaction effects of harbour facilities (e.g. quay walls) using the theory of porous media (Biot), that is nonlinear soil dynamics. The PDE/FEM structure is like that:  K(u) Q   u   0 0 u_t]  M 0u_tt fu     +    +    =    0 H   p   Qt S p_t  G 0p_tt fp u: Displacement field p: (pore) pressure Hopefully, there is someone who can help me and give some recommendations/hints. Thanks in advance Sincerely Ingo Schmidt  Dipl.Ing. Ingo Schmidt Institute of Modelling and Computation Hamburg University of Technology Denickestr.17 Building L/ room: 3032 21075 Hamburg http://www.mub.TUHarburg.de 
From: Roy Stogner <roystgnr@ic...>  20070214 13:55:26

On Wed, 14 Feb 2007, Ingo Schmidt wrote: > I'm looking for someone with experience applying libmesh to nonlinear > structural dynamics, e.g. material and/or large displacements/strains > who could answer me some (essential and specific) questions? > > a) Which "System" (DiffSystem(FEMSystem), NonLinImplicit, > TransientSystem) is the best choice? >From your perspective, the best choice may be to start with a LinearImplicitSystem and let your application code add the additional vectors and perform the particular time integration & nonlinear solve strategies that you need. >From my perspective, I'd like to have more FEMSystem users giving me suggestions for make that interface more flexible, but I'll understand if you don't think the additional framework features are worth becoming a guinea pig for new library code. > b) It seems that the FEMSystem is in principle a really good framework, > but are the necessary changes to consider e.g. the second time > derivatives, other time stepping schemes etc. feasible without > destroying the given FEMSystem structure? Keep in mind that "destroying the given FEMSystem structure" is still an option  my latest major change was committed to CVS yesterday. The warning call printed out by "untested();" in the DiffSystem constructor isn't going to be taken out by 0.6.0, and as long as you'd be ready to make simple changes to your code to handle any slight future API breakage, we'd be willing to introduce some slight API breakage on your behalf as well. Second time derivatives could be handled in several ways depending on your formulation  the most obvious that comes to mind would be to introduce a new TimeSolver subclass that treats *_time_derivative() methods as returning weighted second derivatives. I'd have to know the details of the time stepping schemes you have in mind to tell you how feasible they are.  Roy 
From: Ingo Schmidt <ingo.schmidt@tu...>  20070214 15:43:35
Attachments:
Message as HTML

Hi Roy, First of all thank you for the really fast answer. Roy Stogner schrieb: > On Wed, 14 Feb 2007, Ingo Schmidt wrote: > >> I'm looking for someone with experience applying libmesh to nonlinear >> structural dynamics, e.g. material and/or large displacements/strains >> who could answer me some (essential and specific) questions? >> >> a) Which "System" (DiffSystem(FEMSystem), NonLinImplicit, >> TransientSystem) is the best choice? > > From your perspective, the best choice may be to start with a > LinearImplicitSystem and let your application code add the additional > vectors and perform the particular time integration & nonlinear solve > strategies that you need. > That's what I thougt first, too. But It would be a pity not to avail the given libmesh structure and implementing such algorithms anew. Furthermore violates that strategy, in my opinion, a bit the philosophy and ideas of libmesh and impair the whole framework (or?). > From my perspective, I'd like to have more FEMSystem users giving me > suggestions for make that interface more flexible, but I'll understand > if you don't think the additional framework features are worth > becoming a guinea pig for new library code. > That would not be the problem. There will be no big difference between bugfixing in libmesh or in my own coding. >> b) It seems that the FEMSystem is in principle a really good framework, >> but are the necessary changes to consider e.g. the second time >> derivatives, other time stepping schemes etc. feasible without >> destroying the given FEMSystem structure? > > Keep in mind that "destroying the given FEMSystem structure" is still > an option  my latest major change was committed to CVS yesterday. > The warning call printed out by "untested();" in the DiffSystem > constructor isn't going to be taken out by 0.6.0, and as long as you'd > be ready to make simple changes to your code to handle any slight > future API breakage, we'd be willing to introduce some slight API > breakage on your behalf as well. > > Second time derivatives could be handled in several ways depending on > your formulation  the most obvious that comes to mind would be to > introduce a new TimeSolver subclass that treats *_time_derivative() > methods as returning weighted second derivatives. I'd have to know > the details of the time stepping schemes you have in mind to tell you > how feasible they are. I'd like to sustain the newmark time stepping scheme and modify it due to different orders of time derivates for the displacement (second) and pressure (first) field. Subsequently, I tinker with the idea of employing a discontinous galerkin method. Therefore the new FEMSystem could be a perfect framework for switching between different time stepping schemes. >  > Roy The other idea was to do multiple inheritance for the newmarksystem class (LinImplSys and NonLinImplSys) but I'm not able to estimate the effort of implementing that (including PETSc interface programming, i.e. SNESSetFunction <http://wwwunix.mcs.anl.gov/petsc/petscas/snapshots/petsccurrent/docs/manualpages/SNES/SNESSetFunction.html>;, SNESSetJacobian <http://wwwunix.mcs.anl.gov/petsc/petscas/snapshots/petsccurrent/docs/manualpages/SNES/SNESSetJacobian.html>;, SNESSetUpdate <http://wwwunix.mcs.anl.gov/petsc/petscas/snapshots/petsccurrent/docs/manualpages/SNES/SNESSetUpdate.html>;, etc... ) and if there will appear some general conflicts in libmesh.... Alltogether the FEMSystem seems to me the best choice. So I will go on to dismantle example 18 to become familiar with that FEMSystem. Is there a chance to get more information about the solved (strong and weak form, discretised in time and space) PDE? I mean I'm not that familiar with fluid dynamics and that NavierStokes stuff. Thanks in advance. Ingo  Dipl.Ing. Ingo Schmidt Institute of Modelling and Computation Hamburg University of Technology Denickestr.17 Building L/ room: 3032 21075 Hamburg http://www.mub.TUHarburg.de 
From: Roy Stogner <roystgnr@ic...>  20070214 17:08:52

On Wed, 14 Feb 2007, Ingo Schmidt wrote: > First of all thank you for the really fast answer. I usually check my email first thing after waking up, so early morning Central Time zone is the time to write me if you need a rapid but ungrammatical answer. (Honestly, "suggestions for make"? English is actually my first language, I swear...) > Roy Stogner schrieb: >> On Wed, 14 Feb 2007, Ingo Schmidt wrote: >> >> From your perspective, the best choice may be to start with a >> LinearImplicitSystem and let your application code add the additional >> vectors and perform the particular time integration & nonlinear solve >> strategies that you need. >> > That's what I thougt first, too. But It would be a pity not to avail the > given libmesh structure and implementing such algorithms anew. > Furthermore violates that strategy, in my opinion, a bit the philosophy > and ideas of libmesh and impair the whole framework (or?). I wouldn't actually call it a "framework" yet  libMesh was written as a library, aimed at users who had no trouble using lower level APIs and who were likely to need flexible low level access to implement new FEM ideas. FEMSystem is supposed to be more of a framework, a step in the direction of making common application coding easier while not making uncommon application coding harder, but only time will tell how effective it is. > I'd like to sustain the newmark time stepping scheme and modify it due > to different orders of time derivates for the displacement (second) and > pressure (first) field. I'll need to learn more about it first; I've never used NewmarkSystem myself. On first impressions, the idea of extending a TimeSolver subclass to handle multiple global sparse matrices feels a bit ugly to me, but it could be done. The real question is the interface  obviously if you've got both first and second order time derivatives in your problem, that's not something the current FEMSystem API expects to handle. > Therefore the new FEMSystem could be a perfect framework for > switching between different time stepping schemes. If we can get the APIs right, that's certainly the case. One of the reasons I wrote it in the first place was because I was sick of my time discretizations and spatial discretizations getting unnecessarily interwoven. > The other idea was to do multiple inheritance for the newmarksystem > class (LinImplSys and NonLinImplSys) This strikes me as a horrible idea. libMesh already requires more C++ experience than I'd like to demand from our users. Trying to use multiple inheritance from two classes in the same inheritance hierarchy would require more C++ experience than I'd like to demand from myself. ;) > Alltogether the FEMSystem seems to me the best choice. So I will go on > to dismantle example 18 to become familiar with that FEMSystem. Is there > a chance to get more information about the solved (strong and weak form, > discretised in time and space) PDE? I mean I'm not that familiar with > fluid dynamics and that NavierStokes stuff. I actually don't have a good online reference handy for you myself  I usually solve incompressible flow with a streamfunction or velocity potential formulation. The velocitypressure formulation is simple, though, if your density and viscosity are constant. You've got a vectorvalued variable for velocity v, and a scalar variable (in a lower dimensional finite element space) for pressure. In the strong form, nondimensionalized, with constant Reynolds number Re: dv/dt = Re * (v dot grad)(v)  grad(p) + div(grad(v)) div(v) = 0 In the weak form, you take weighted residuals of the first equation with variations of v, and weighted residuals of the second equation with variations of p, and integrate the grad(p) and div(grad(v)) terms by parts. Example 18 also uses a penalty method to fix velocity boundary conditions and to fix the pressure at a node to make the problem wellposed. This only works well at low Reynolds numbers, and the stabilization and turbulence modeling needed to handle high Re on reasonable grids can get complicated, but none of that is in ex18.  Roy 
From: Ingo Schmidt <ingo.schmidt@tu...>  20070216 13:12:07

Hi libmesh users, hi Roy, I've got some additional questions concerning that nonlinear libmesh stuff (i.e. examples and structural dynamics). I dismantled and compared the examples 18 and 13 to get the differences. First of all a rather simple question: a) Ex 13 is for Reynolds number equal to one (?), i.e. Ex 18 is slightly more general? (Because I miss some material specific data in ex 13) To handle the problem with that first and second time derivatives in FEMSystem I'm thinking about extending that time_evolvingswitch including the order of the time derivative. The time_stepping scheme should than be able due to that switch to chose the right approximation order for the different variables. Additional memory for the nodal values of velocity and acceleration (required for some time stepping schemes, e.g. Newmark) have to be allocated, e.g. with system.add_vector(). Beyond that specific insertion concerning FEMSystem I've got a really general corresponding to the member element_time_derivative(). Isn't the name too specific to CFD problems or the like? In my case in the beginning I was somewhat confused translating that to my problem (you know with that first and second time derivative...). I didn't expect the system assembling behind that method. But that's really marginally. Thirdly, the TransientSystem<TransientNonlinearImplicitSystem> following ex13 will be the best alternative to the FEMSystem for me. But is there a chance to include the SNESSetUpdate (http://wwwunix.mcs.anl.gov/petsc/petscas/snapshots/petsccurrent/docs/manualpages/SNES/SNESSetUpdate.html) Option into libmesh at the PetscNonlinearSolver.solve() ? That's a really general but also important option necessary for residuals depending on the "current" solution (e.g. nonlinear constitutive laws). OK Roy, it's early morning at central time zone, I'm waiting for your answer and don't care about grammatics... :) No, I'm just kidding...It would be nice to hear your point of view. Best regards and thanks in advance. Ingo Roy Stogner schrieb: > On Wed, 14 Feb 2007, Ingo Schmidt wrote: > >> First of all thank you for the really fast answer. > > I usually check my email first thing after waking up, so early morning > Central Time zone is the time to write me if you need a rapid but > ungrammatical answer. (Honestly, "suggestions for make"? English > is actually my first language, I swear...) > >> Roy Stogner schrieb: >>> On Wed, 14 Feb 2007, Ingo Schmidt wrote: >>> >>> From your perspective, the best choice may be to start with a >>> LinearImplicitSystem and let your application code add the additional >>> vectors and perform the particular time integration & nonlinear solve >>> strategies that you need. >>> >> That's what I thougt first, too. But It would be a pity not to avail the >> given libmesh structure and implementing such algorithms anew. >> Furthermore violates that strategy, in my opinion, a bit the philosophy >> and ideas of libmesh and impair the whole framework (or?). > > I wouldn't actually call it a "framework" yet  libMesh was written as > a library, aimed at users who had no trouble using lower level APIs > and who were likely to need flexible low level access to implement new > FEM ideas. FEMSystem is supposed to be more of a framework, a step in > the direction of making common application coding easier while not > making uncommon application coding harder, but only time will tell how > effective it is. > >> I'd like to sustain the newmark time stepping scheme and modify it due >> to different orders of time derivates for the displacement (second) and >> pressure (first) field. > > I'll need to learn more about it first; I've never used NewmarkSystem > myself. On first impressions, the idea of extending a TimeSolver > subclass to handle multiple global sparse matrices feels a bit ugly to > me, but it could be done. > > The real question is the interface  obviously if you've got both > first and second order time derivatives in your problem, that's not > something the current FEMSystem API expects to handle. > >> Therefore the new FEMSystem could be a perfect framework for >> switching between different time stepping schemes. > > If we can get the APIs right, that's certainly the case. One of the > reasons I wrote it in the first place was because I was sick of my > time discretizations and spatial discretizations getting unnecessarily > interwoven. > >> The other idea was to do multiple inheritance for the newmarksystem >> class (LinImplSys and NonLinImplSys) > > This strikes me as a horrible idea. libMesh already requires more C++ > experience than I'd like to demand from our users. Trying to use > multiple inheritance from two classes in the same inheritance > hierarchy would require more C++ experience than I'd like to demand > from myself. ;) > >> Alltogether the FEMSystem seems to me the best choice. So I will go on >> to dismantle example 18 to become familiar with that FEMSystem. Is there >> a chance to get more information about the solved (strong and weak form, >> discretised in time and space) PDE? I mean I'm not that familiar with >> fluid dynamics and that NavierStokes stuff. > > I actually don't have a good online reference handy for you myself  I > usually solve incompressible flow with a streamfunction or velocity > potential formulation. > > The velocitypressure formulation is simple, though, if your density > and viscosity are constant. You've got a vectorvalued variable for > velocity v, and a scalar variable (in a lower dimensional finite > element space) for pressure. In the strong form, nondimensionalized, > with constant Reynolds number Re: > > dv/dt = Re * (v dot grad)(v)  grad(p) + div(grad(v)) > > div(v) = 0 > > In the weak form, you take weighted residuals of the first equation > with variations of v, and weighted residuals of the second equation > with variations of p, and integrate the grad(p) and div(grad(v)) terms > by parts. > > Example 18 also uses a penalty method to fix velocity boundary > conditions and to fix the pressure at a node to make the problem > wellposed. > > This only works well at low Reynolds numbers, and the stabilization > and turbulence modeling needed to handle high Re on reasonable grids > can get complicated, but none of that is in ex18. >  > Roy  Dipl.Ing. Ingo Schmidt Institute of Modelling and Computation Hamburg University of Technology tel: +49/(0)40/428784483 Denickestr.17 fax: +49/(0)40/428784353 Building L/ room: 3032 email: ingo.schmidt@... 21075 Hamburg http://www.mub.TUHarburg.de 
From: Roy Stogner <roystgnr@ic...>  20070216 14:05:41

On Fri, 16 Feb 2007, Ingo Schmidt wrote: > a) Ex 13 is for Reynolds number equal to one (?), i.e. Ex 18 is slightly > more general? (Because I miss some material specific data in ex 13) Yes, that's right. > To handle the problem with that first and second time derivatives in > FEMSystem I'm thinking about extending that time_evolvingswitch > including the order of the time derivative. The time_stepping scheme > should than be able due to that switch to chose the right approximation > order for the different variables. Additional memory for the nodal > values of velocity and acceleration (required for some time stepping > schemes, e.g. Newmark) have to be allocated, e.g. with system.add_vector(). Here's my best current idea: Ignoring the *_constraint functions for now, how you describe a timedependent problem to FEMSystem is basically: M(u) du/dt = F(u) Where the time_evolving switch tells the system that a du/dt term is involved, and the mass_residual term handles the effects of the mass matrix M(u). Most applications, ex18 included, don't redefine mass_residual because they don't need to; the residual is usually just (du/dt,phi_i)_L2. But what if we add a "time_evolving_second_order" flag and "second_mass_residual" method (or, you know, something with better names) as well? Then for problems with second order time derivatives, you turn both flags on, and if you've got a more complicated left hand side than (d2u/dt2 + du/dt) you override the residual functions as well, and that should completely describe: K(u) d2u/dt2 + M(u) du/dt = F(u) There's one concern that comes up for nonconstant K and M  I'll illustrate it for Euler integration since I don't think I understand Newmark yet: When solving M du/dt = F(u), Euler normally does: (M u^(n+1)  M u^(n)) = Dt * F(u^(theta)), where u^(theta) is an interpolant somewhere in between u^(n) and u^(n+1) depending on the specific method. But when M isn't constant, currently you get: (M(u^(n+1)) u^(n+1)  M(u^(n)) u^(n)) on the left hand side, which depending on your formulation probably isn't what you want, and may not even be consistent. We had a student here who had to resort to a few ugly hacks to get a nonlinear stabilizationbased M working, since he needed: (M(u^(theta)) u^(n+1)  M(u^(theta)) u^(n)) If you might have the same problem then maybe it's time to make something like an "elem_theta_solution" variable available in the API. But again, hopefully with a better name. > Beyond that specific insertion concerning FEMSystem I've got a really > general corresponding to the member element_time_derivative(). > Isn't the name too specific to CFD problems or the like? The name is probably bad in general, since it really corresponds to the parts of the equation that aren't attached to any time derivatives! I was just looking for a name that seemed to accurately distinguish it from element_constraint, since my time integrators need to treat those differently. > Thirdly, the TransientSystem<TransientNonlinearImplicitSystem> following > ex13 will be the best alternative to the FEMSystem for me. But is there > a chance to include the SNESSetUpdate > (http://wwwunix.mcs.anl.gov/petsc/petscas/snapshots/petsccurrent/docs/manualpages/SNES/SNESSetUpdate.html) > Option into libmesh at the PetscNonlinearSolver.solve() ? That's a > really general but also important option necessary for residuals > depending on the "current" solution (e.g. nonlinear constitutive laws). You'll have to ask Ben about that  I think he's currently the only one who's done any work with PETSc's nonlinear solvers... and it can't have been too much work, if he's still got that handrolled Newton loop in ex13! He's probably slacking off, finishing his dissertation and graduating next month and such.  Roy 
From: Ingo Schmidt <ingo.schmidt@tu...>  20070220 14:40:39

Hi Roy, Ben and to whom it may concern, too, I've started to implement the (linear) wave equation for structural mechanics (well known: M d2u/dt2+Ku = f) into the NonlinearImplicitSystem framework of libmesh, just to gain some experiences with that stuff. The foundation is the code of example 13 but I'd like to use the NonlinearSolver classes (instead of (implementing) Newton's method + linear_solve) and let PETSc handle the equilibrium iteration at each time step. So, exists there, may be an inofficial, example of libmesh following that idea I can use as "help resource"? If not, what are the reasons of reimplementing Newton's method and doing linear solve instead of using SNES? Something specific with that libmeshpetsc Interface or is it just that complex and horrible SNES environment? The last thing which is the last question (see below) of my last mail I directly adress to Ben upon the advice of Roy. > > >> Thirdly, the TransientSystem<TransientNonlinearImplicitSystem> following >> ex13 will be the best alternative to the FEMSystem for me. But is there >> a chance to include the SNESSetUpdate >> (http://wwwunix.mcs.anl.gov/petsc/petscas/snapshots/petsccurrent/docs/manualpages/SNES/SNESSetUpdate.html) >> >> Option into libmesh at the PetscNonlinearSolver.solve() ? That's a >> really general but also important option necessary for residuals >> depending on the "current" solution (e.g. nonlinear constitutive laws). > > You'll have to ask Ben about that  I think he's currently the only > one who's done any work with PETSc's nonlinear solvers... and it can't > have been too much work, if he's still got that handrolled Newton > loop in ex13! He's probably slacking off, finishing his dissertation > and graduating next month and such. >  > Roy O.K. thanks a lot in advice especially to Ben and all the best for your graduation! Best regards Ingo PS: Actually, is there really no one who's solving structural mechanics problems with libmesh??  Dipl.Ing. Ingo Schmidt Institute of Modelling and Computation Hamburg University of Technology Denickestr.17 Building L/ room: 3032 21075 Hamburg http://www.mub.TUHarburg.de 
From: Martin Lüthi <luethi@va...>  20070220 21:44:19

Ingo Ingo Schmidt writes: > I've started to implement the (linear) wave equation for structural > mechanics (well known: M d2u/dt2+Ku = f) into the Maybe you could rewrite your equation with the standard trick to simplify second order differential equations into a ODE system. Of course you need to double the number of unknowns. In FE matrix notation this would look like M du/dt  Mv = 0 M dv/dt + Ku = f WDYT? Best, Martin 
From: Ingo Schmidt <ingo.schmidt@tu...>  20070221 13:46:08

Hi Martin, Thanks that you attend to my problem. Martin LXthi schrieb: > Ingo > > Ingo Schmidt writes: > > I've started to implement the (linear) wave equation for structural > > mechanics (well known: M d2u/dt2+Ku = f) into the > > Maybe you could rewrite your equation with the standard trick to > simplify second order differential equations into a ODE system. Of > course you need to double the number of unknowns. In FE matrix > notation this would look like > > M du/dt  Mv = 0 > M dv/dt + Ku = f > > WDYT? > > Best, Martin > Is it correct that your suggestion aims to the appliance of the FEMSystem "Framework" for the present problem of the linear wave equation? Referring to this your idea will be a good alternative. But to double the number of DoF will be bad for the coupled problem (3 solid displacements, 3 fluid velocities and 1 pore pressure) I intend to solve actually. Thanks and best regards Ingo  Dipl.Ing. Ingo Schmidt Institute of Modelling and Computation Hamburg University of Technology Denickestr.17 Building L/ room: 3032 21075 Hamburg http://www.mub.TUHarburg.de 
From: Nachiket Gokhale <gokhalen@bu...>  20070220 14:48:39
Attachments:
Message as HTML

Just curious, but I've been wondering if it was possible to implement nonlinear ODE's using the PETSC interface to PVODE ( http://www.llnl.gov/CASC/sundials/)? Nachiket On 2/20/07, Ingo Schmidt <ingo.schmidt@...> wrote: > > Hi Roy, Ben and to whom it may concern, too, > > I've started to implement the (linear) wave equation for structural > mechanics (well known: M d2u/dt2+Ku = f) into the > NonlinearImplicitSystem framework of libmesh, just to gain some > experiences with that stuff. The foundation is the code of example 13 > but I'd like to use the NonlinearSolver classes (instead of > (implementing) Newton's method + linear_solve) and let PETSc handle the > equilibrium iteration at each time step. > So, exists there, may be an inofficial, example of libmesh following > that idea I can use as "help resource"? > If not, what are the reasons of reimplementing Newton's method and doing > linear solve instead of using SNES? Something specific with that > libmeshpetsc Interface or is it just that complex and horrible SNES > environment? > > The last thing which is the last question (see below) of my last mail I > directly adress to Ben upon the advice of Roy. > > > > > >> Thirdly, the TransientSystem<TransientNonlinearImplicitSystem> > following > >> ex13 will be the best alternative to the FEMSystem for me. But is there > >> a chance to include the SNESSetUpdate > >> ( > http://wwwunix.mcs.anl.gov/petsc/petscas/snapshots/petsccurrent/docs/manualpages/SNES/SNESSetUpdate.html > ) > >> > >> Option into libmesh at the PetscNonlinearSolver.solve() ? That's a > >> really general but also important option necessary for residuals > >> depending on the "current" solution (e.g. nonlinear constitutive laws). > > > > You'll have to ask Ben about that  I think he's currently the only > > one who's done any work with PETSc's nonlinear solvers... and it can't > > have been too much work, if he's still got that handrolled Newton > > loop in ex13! He's probably slacking off, finishing his dissertation > > and graduating next month and such. > >  > > Roy > O.K. thanks a lot in advice especially to Ben and all the best for your > graduation! > > Best regards > > Ingo > > PS: Actually, is there really no one who's solving structural mechanics > problems with libmesh?? > >  > Dipl.Ing. Ingo Schmidt > Institute of Modelling and Computation > > Hamburg University of Technology > Denickestr.17 > Building L/ room: 3032 > 21075 Hamburg > > http://www.mub.TUHarburg.de > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Roy Stogner <roystgnr@ic...>  20070220 20:11:40

On Tue, 20 Feb 2007, Nachiket Gokhale wrote: > Just curious, but I've been wondering if it was possible to implement > nonlinear ODE's using the PETSC interface to PVODE ( > http://www.llnl.gov/CASC/sundials/)? Certainly nobody has written the necessary glue code yet, and looking over the PETSc documentation I'm not sure it can be done at all. The page for TSSetProblemType suggests that the most general problem they support is: U_t = f(t, U) Whereas (even for methods for which all variables have a single time derivative involved) finite element systems tend to look like: M U_t = f(t, U) Where M is an L2 mass matrix. I suppose you can do some inexact quadrature tricks to make a diagonal approximation to M for simple elements, but I wouldn't use it for my code. ... Actually, now I notice a TSSetLHSMatrix option which does appear to solve problems with mass matrices. It wouldn't fit perfectly into my FEMSystem framework (which works best with time integrators capable of coping with elementbyelement calculations, not just global residuals and Jacobians), but if you want to brave the PETSc API and write an interface for your own code, that appears to be possible.  Roy 
From: John Peterson <peterson@cf...>  20070220 15:08:39

Ingo Schmidt writes: > If not, what are the reasons of reimplementing Newton's method and doing > linear solve instead of using SNES? Something specific with that > libmeshpetsc Interface or is it just that complex and horrible SNES > environment? Personally, I thought it was because SNES is very Petscspecific ... and the LinearSolver class was designed to be an interface to multiple concrete implementations (PETSc, LasPack, yeah that's basically it so far) ;) We try to pretend that LibMesh doesn't require PETSc (when developing) even though it really does if you want to solve any kind of practical application. John 
From: Roy Stogner <roystgnr@ic...>  20070220 15:16:25

On Tue, 20 Feb 2007, John Peterson wrote: > Personally, I thought it was because SNES is very Petscspecific ... I thought it was mostly because we're lazy. ;) I first wrote the NewtonSolver class as a stopgap to solve problems until I had time to figure out PETSc's SNES API, but now my stopgap works well enough that I'm not motivated to write the glue code needed to switch.  Roy 