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 