Good, I think this is a simple way to handle functions. Weather we use i
or comp doesn't matter on my part.
As for time dependent functions, I think a solution of the form you
suggest is good in the case of functions given by expressions. For time
dependent functions given as FE functions in discrete time, such as a
computed time dependent solution, a user could also declare a function
for example given by interpolation in time based on FE functions in
discrete time, and where for large problems one would typically write to
file.
So, there are various ways to implement specific functions, and I think it
is a good idea to leave much to the user. In particular at this stage, as
we need to focus on getting the basics in place. If it turns out that a
particular type of function would be very useful, we could add it later
on.
/Johan
On Mon, 14 Feb 2005, Anders Logg wrote:
Yes, I think we should add alternative evaluation operators. But I
suggest changing comp to i, and maybe we don't need time. A user that
wants a time-dependent function declares her own function and can just
put in a public member variable called t and use that:
In solver:
f.t = 2.0;
In function:
class MyFunction : public Function
{
public:
real operator() (const Point& p)
{
return sin(t)*p.x;
}
real t;
}
/Anders
On Mon, Feb 14, 2005 at 05:52:20PM -0500, Johan Hoffman wrote:
Looks simple and good, I think. How about vector functions (and time
dependent functions)? Should we add alternative operator() functions to
NewFunction to be implemented by the user:
virtual real operator()(const Point& p, int comp)
virtual real operator()(const Point& p, real time)
virtual real operator()(const Point& p, int comp, real time)
or should we introduce new classes?
/Johan
On Mon, 14 Feb 2005, Anders Logg wrote:
I understand your point. However, I just checked in some updates of
NewFunction that lets a user do
class MyFunction : NewFunctionExpression
{
real operator()(const Point& p)
{
return sin(p.x);
}
};
MyFunction f;
Could you take a look and see if you like the new/old solution?
It's not very complicated. The projection just checks if data is null
and in that case calls the user defined evaluation operator.
/Anders
On Mon, Feb 14, 2005 at 03:35:25PM +0100, Johan Jansson wrote:
I'm thinking about how to enable user-defined functions, but I don't
have a clear solution.
The idea right now seems to be to subclass NewFunction, a la:
// Source term
// Example using NewFunction
class F : public NewFunction
{
public:
F(const Mesh& mesh, const NewFiniteElement& element, NewVector& x) :
NewFunction(mesh, element, x)
{
}
virtual real operator()(const Point& p)
{
real pi = DOLFIN_PI;
return 14.0 * pi*pi * sin(pi*p.x) * sin(2.0*pi*p.y) *
sin(3.0*pi*p.z);
}
};
We could have a separate constructor when an expression is given, and
then project the given expression.
I think this is a bit ugly though, it seems unnecessarily complex.
Another solution would be to separate the expression out into a
functor (function class), and the example would be:
class F : Expression
{
virtual real operator()(const Point& p)
{
real pi = DOLFIN_PI;
return 14.0 * pi*pi * sin(pi*p.x) * sin(2.0*pi*p.y) *
sin(3.0*pi*p.z);
}
}
then:
int main()
{
...
F fexpression;
NewFunction f(mesh, element, fexpression);
..
}
This seems much more natural. When we have a function given by the
values of its degrees of freedom, we pass a vector with the dofs to
NewFunction. When we have a function given by an expression, we pass
the expression to NewFunction and it projects it and stores it as
values of the dofs. However, we would need to introduce a new class:
Expression. What do you think?
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
_______________________________________________
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
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
