dolfin team mailing list archive

["Johan Hoffman" <jhoffman@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.

Another important purposed are to postprocess the solution, but also to
use a solution from one problem as a coefficient in another problem. The
other problem may be using a different mesh, and then the mesh (and
possibly the element for interpolation) would be needed.

/Johan


>
> 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
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>