dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

On Mon, 2006-02-13 at 13:42 -0600, Anders Logg wrote:
> On Mon, Feb 13, 2006 at 06:07:34PM +0100, Garth N. Wells wrote:
> > On Mon, 2006-02-13 at 10:53 -0600, Anders Logg wrote:
> > 
> > > ok, let's begin with fixing the XML input/output for Vector. 
> > 
> > Sounds good.
> > 
> > 
> > > Then we
> > > should have what we need to read/write functions + we also need to
> > > decide on which elements to precompile and store.
> > > 
> > > The XML format for Vector is temporarily disabled after the change of
> > > linear algebra backend to PETSc, so it should be easy to fix.
> > > 
> > > There's a lot of different elements we would potentially need to
> > > pregenerate, including different degree polynomials, vector-valued
> > > elements with different number of components, mixed elements etc, so
> > > it's not obvious which we should pick. (Of course if something is
> > > missing in the first set of elements we can always add it later when
> > > someone needs it.)
> > 
> > I would consider leaving this up to the user because of the huge number
> > of elements that this could lead to.
> 
> So the user would have to supply the element? 
> Something like
> 
>      Function u;
>      File file("solution.xml");
>      file >> u;
>      u.attach(element);
> 
> or
> 
>      Function u(element);
>      File file("solution.xml");
>      file >> u;
> 
> What about the mesh? Perhaps it should also be possible to specify the
> mesh so it can be shared between several Functions:
> 
>      Function u(mesh, element);
>      File file("solution.xml");
>      file >> u;
> 
> or perhaps that's not necessary since one can always just save the
> vector:
> 
>      Function u;
>      File file("solutionvector.xml");
>      file >> u.vector();
> 

Yes.  I'm thinking that the main purpose of writing a function to a file
is to allow a particular simulation to be restarted. In the vast
majority of cases, a vector would be enough, and the mesh would be
useful too in case a mesh is thrown away. When restarting a solver, I
would expect that the user would already have the element available.   

Garth

> /Anders
>      
> > >  
> > > > 
> > > > > > > 2. An interface for projecting/interpolating between Functions. The
> > > > > > > main example which requires some manual work in solvers is defining
> > > > > > > the initial values by a UserFunction and wanting to represent that as
> > > > > > > a DiscreteFunction.
> > > > > > 
> > > > > > I'm not sure what you mean. I thought I solved this with the new
> > > > > > functionality I added to the Function class last week. You can define
> > > > > > a Function for the initial value by overloading eval(), or even by
> > > > > > 
> > > > > > Function u = 0.0;
> > > > > > 
> > > > > > and then u can change from being a user-defined Function to a discrete
> > > > > > Function. See new convection-diffusion demo.
> > > > > > 
> > > > > > You can also do
> > > > > > 
> > > > > > Function u(x, mesh, element);
> > > > > > u = f;
> > > > > > 
> > > > > > to interpolate f to u.
> > > > > > 
> > > > > 
> > > > Is the interpolation linear (to the vertexes only), or does it work for
> > > > higher-order elements?
> > > 
> > > Works for all types of elements. The function f is evaluated at all
> > > nodes of the element that defines u.
> > > 
> > Great!
> > 
> > Garth
> > 
> > > /Anders
> > > 
> > > > Garth
> > > > 
> > > > > Ok, great! I'm sorry, I didn't realize this was what you added last
> > > > > week.
> > > > > 
> > > > > I think interpolation is enough, projection can wait.
> > > > > 
> > > > > > I have limited time to work on new features before Geilo, but I can
> > > > > > probably fit something in if I get some help.
> > > > > > 
> > > > > 
> > > > > Yes, I also have limited time. But maybe we can at least start looking
> > > > > at Function input and decide what we should do, i.e. if we should
> > > > > design a DOLFIN XML data format for Functions or use the VTK format.
> > > > > 
> > > > >   Johan
> > > > > 
> > > > > _______________________________________________
> > > > > DOLFIN-dev mailing list
> > > > > DOLFIN-dev@xxxxxxxxxx
> > > > > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> > > 
> > 
> > 
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> > 
> 
-- 
Dr. Garth N. Wells
Faculty of Civil Engineering and Geosciences
Delft University of Technology
Stevinweg 1
2628 CN Delft
The Netherlands

tel.     +31 15 278 7922
fax.     +31 15 278 6383
e-mail   g.n.wells@xxxxxxxxxx
url      http://www.mechanics.citg.tudelft.nl/~garth