FunctionParser using solution as variable?

[Sam Cox]

Hi all,

Does anyone have any experience with/ideas about how to use FunctionParser with a variable that is not a space variable? By which I mean, how would I go about evaluating a function mu(x,T), where T is a given field (eg a solution vector from a previous timestep)?
My only thought so far is to do a bit of a bodge - create a Point<dim+1> object, with the last component the evaluation of T at the point x. I could pass this into FunctionParser::value, or a std::vector<Point<dim+1> > into FunctionParser::value_list, but that is probably messy, and potentially costly ( I guess it will cost get_quadrature_points() + n_quadrature_points * ( copy Point<dim> components to Point<dim+1>  +   copy T to dim+1 component) to create the input std::vector<Point<dim+1> > ).
Is there a better way than this?

Bests,
Sam

[Timo Heister]

Hey Sam,

yes, the FunctionParser is somewhat limited and I was annoyed by the
same thing in the past. Another limitation is that your solution only
works if dim<3 because we only instantiate FunctionParser for
dim=1,2,3. If you only want to add one scalar quantity you can work
around this by using a "time dependent" FunctionParser and set the
time to the value you want.

All this doesn't help with the fact that FunctionParser is a
Function<dim> and should behave that way if you pass it to something
like integrate_difference(). The expectation is that you can evaluate
using .value() with an arbitrary point and get a result but your
suggestion wouldn't update T correctly.

What you would need is a new object that wraps a DoFHandler, a
solution vector, and a FunctionParser and offer a Function<dim>
interface. Sadly, this will be very inefficient, because you need to
use something like point_value which searches all cells...

> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Timo Heister
http://www.math.clemson.edu/~heister/

[Wolfgang Bangerth]

Sam,

I have a question separate from Timo's. Basically, what it boils down is what
you want to use your function for. You only need to derive something from the
Function<dim> base class is you're going to pass it to deal.II functions such
as VectorTools::interpolate_boundary_values() etc, but if your function mu
depends on anything but just the location, then this is probably not what
you're trying to do.

So, why not just write a function
double mu(const Point<dim> &x, const double T) { ...; return ...; }
? Or do you want to say that you'd like to evaluate an expression that you
don't know at compile time in your function in the same way as the
FunctionParser class does?

Best
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[Sam Cox]

Hi Wolfgang,

The latter - I've a temperature-dependent viscosity term, and I'd like to be able to test out a variety of different viscosity forms. I'd prefer to use FunctionParser as that then doesn't require any deal.II knowledge by the end user (particularly in terms of .get_function_gradients() etc, and the various intermediate variables they introduce), and the choice of the latest wacky viscosity profile could be made at runtime by the user. But overall I think my best bet currently is to just implement a couple of different ones and choose the case I'd like with a parameter in the parameter file. Any other ideas?

Bests,
Sam

[Wolfgang Bangerth]

> The latter - I've a temperature-dependent viscosity term, and I'd like
> to be able to test out a variety of different viscosity forms. I'd
> prefer to use FunctionParser as that then doesn't require any deal.II
> knowledge by the end user (particularly in terms of
> .get_function_gradients() etc, and the various intermediate variables
> they introduce), and the choice of the latest wacky viscosity profile
> could be made at runtime by the user. But overall I think my best bet
> currently is to just implement a couple of different ones and choose the
> case I'd like with a parameter in the parameter file. Any other ideas?

I think in that case, what you probably want to do is clone the existing
FunctionParser class. My suggestion would be to create a class that
essentially does exactly the same FunctionParser but instead of having a
function
double value (const Point<dim> &, const unsigned int)
it would have a function
double value (const std::vector<double> &arguments,
const unsigned int);
It should be relatively straightforward to morph the existing class into
one that takes a number of arguments that is determined at run time, not
at compile time.

I would actually be quite interested in including such a class in the
library. In a second step, it should be easy to make the existing class
use your more generic one.

Want to give it a try?

Best
Wolfgang

[Timo Heister]

Also see https://github.com/dealii/dealii/pull/76 for the start of an
implementation where we decided it doesn't quite fit the way I did it.
:-)

[Sam Cox]

Ok, I'd be interested in doing that at some point after the new year - I've implemented a fixed function for now, but will look into implementing this when I have some time in the new year.

Thanks for your excellent responses as always,
Sam

[Wolfgang Bangerth]

On 12/14/2014 12:01 PM, Sam Cox wrote:
> Ok, I'd be interested in doing that at some point after the new year - I've
> implemented a fixed function for now, but will look into implementing this
> when I have some time in the new year.

Sam: That would of course be most excellent. Let us know if you run into
difficulties!

Best
W.