dolfin team mailing list archive

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

On Mon, 2006-02-13 at 10:27 -0600, Anders Logg wrote:
> On Mon, Feb 13, 2006 at 05:06:50PM +0100, Johan Jansson wrote:
> > On Mon, Feb 13, 2006 at 09:39:14AM -0600, Anders Logg wrote:
> > > On Mon, Feb 13, 2006 at 02:46:04PM +0100, Johan Jansson wrote:
> > > 
> > > > I think two remaining features to implement are:
> > > > 
> > > > 1. Loading Functions (DiscreteFunction) from file.
> > > 
> > > ok, which format do we want to do initially? DOLFIN XML?
> > > 
> > > Maybe we should also consider some binary format that is quicker to
> > > write and parse? Could be useful mostly during computations (and less
> > > useful for storing solutions for future reference) for example when
> > > solving the dual problem and linearizing around a previously computed
> > > solution (or time sequence of solutions) that doesn't fit in memory.
> > 
> > Isn't a natural candidate the VTK format? This is the standard output
> > format for DOLFIN, isn't it natural to be able to read it back in?
> 
> The output is currently limited to values at vertices. Do we want to
> support reading and writing arbitrary functions? 

Definitely.


> Since we define
> discrete Functions as triples (vector, mesh, element), we would have
> to read and write all three. It's no problem reading and writing the
> vector and the mesh since it's all data, but the element is more code
> than data (dofmap(), vertexeval() etc), so it's more difficult to
> store to a file.
> 

I would limit it (as a start) to vector, and vector + mesh.  A
description of the element type could be written as a comment in the XML
file and function as a reminder to help the user in the future.

Garth

> Perhaps we could precompile a number of basic element types (we
> already have linears precompiled) and the element type would only be a
> string?
> 
> One way would be to support the VTK format for linears (values at
> vertices) and have a more general DOLFIN XML format that supports all
> types of elements.
> 
> > > > 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.
> > > 
> > 
> > Ok, great! I'm sorry, I didn't realize this was what you added last
> > week.
> > 
> > I think interpolation is enough, projection can wait.
> 
> ok, good.
> 
> > > 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.
> 
> ok. We just need to decide how general we want to be.
> 
> /Anders
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev