[dune-pdelab] Time-dependent right hand side

["Jö Fahlke"]

Am Mon, 31. Aug 2015, 14:42:17 +0200 schrieb conf86 at web.de:
> Date: Mon, 31 Aug 2015 14:42:17 +0200
> From: conf86 at web.de
> To: Jö Fahlke <jorrit at jorrit.de>, dune-pdelab at dune-project.org
> Subject: Aw: Re: [dune-pdelab] Time-dependent right hand side
> 
> > The local operator is the right place for time-dependent source/sink terms and
> > Neumann boundary conditions.  Time-dependent Dirichlet boundary conditions
> > need to be interpolated in each time step, usually the bcextension is reused
> > for that.  See
> > https://cgit.dune-project.org/repositories/dune-pdelab-howto/tree/src/course-examples/example03_bcextension.hh
> > and
> > https://cgit.dune-project.org/repositories/dune-pdelab-howto/tree/src/course-examples/example03_Q2.hh#n80
> > line 80, observe how the BCExtension instance g is passed to osm.apply().
> 
> Ok, I think I understand that, my question is how to get the time parameter in local operator to define the time-dependent source term. 
> void setTime() didn't work, possibly because I got the line wrong where it has to be put. If I try without I always get the "'time' was not declared in this scope" error.

I think I get it now: You are probably looking at
<https://cgit.dune-project.org/repositories/dune-pdelab-howto/tree/src/course-examples/example03_operator.hh>.
There the localoperator derives from the local operator in
example02_operator.hh (which is a stationary example) and adds some minimal
functionality to make it instationary.  Essentially it just updates the bctype
function once a timestep, making it possible to grow or shrink the Dirichlet
or Neumann regions.  The base local operator does not know anything about
time, it just asks the bctype object during a call to alpha_boundary or
similar for the type of the boundary condition at a certain point, and the
answer of the bctype object depends on the previously set time.

In your case, you probably don't want preStep(), and neither preStage(), you
want indeed setTime().  You can do that the way example03 does, by overriding
setTime() and calling setTime() on the parameter object that defines your
source/sink term.  However, that requires that you do have a seperate
parameter class for that.

If you simply compute your time-dependent term inside one one of the assmebly
methods of the local operator, the default setTime() from
InstationaryLocalOperatorDefaultMethods should be sufficient for you: it
stores the set time internally, and if you derive your localoperator from
InstationaryLocalOperatorDefaultMethods you can retrieve the set time using
getTime() within alpha_volume() etc.  I think this is what you tried
initially, when you ran into the ambiguous overload problem.  I assume that
was caused by one local operator deriving from the other, and both local
operator deriving directly from InstationaryLocalOperatorDefaultMethods.  To
avoid that, it is probably easiest to disregard example03 and avoid deriving
one operator from the other.  That way there should be only one instance of
InstationaryLocalOperatorDefaultMethods in the ancestry of your local operator
and no ambiguity should arise.  Simply fold whatever you were doing in the
derived local operator into to base local operator.

Hope that sounds about right.

Regards,
Jö.


-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729

Spaß mit I18N.  Hier StumpWM/clisp:
WARNUNG: DEFUN/DEFMACRO(GET-WM-CLASS): #<PACKAGE XLIB> ist abgeschlossen.
         Das Schloss umgehen und weitermachen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20150831/7739fa3f/attachment.sig>