fem-fenics questions

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

fem-fenics questions

Daniel Kraft
Hi!

I've recently started playing around with fem-fenics, and it works very
well for my application so far.  Here are just some questions I came
across and wanted to discuss:

1) Whenever I run my script using fem-fenics (presumably during the call
to import_ufl_Problem), I see a cc1plus process popping up and using 10
s or so finish.  (This can also be seen with the Poisson example.)  I
understand that this is necessary to compile my UFL form.  Is it
possible to somehow skip this step unless the UFL file was changed?  It
takes a not negligible amount of processing time for my code and I don't
think the UFL file will change often.

2) Since I do not only want to plot the result but also work with it
further, I need to evaluate the result at my grid points.  With linear
Lagrange elements, I "could" use the coefficients obtained directly, but
this is probably a bad idea from the point of view of code design.  Thus
I'm using feval now, but it is not entirely clear to me how it is
supposed to be called.  The doc only says the second argument should be
the "coordinate" of evaluation, but doesn't specify how this coordinate
should look like.  It works for me now if I pass an array of x- and
y-coordinate.  I guess this is how the function is meant to be called?
Is it also possible to invoke it for lots of points at all?  (I think I
read somewhere that this is planned but not yet implemented ... just
checking what the current state is.)  This is a very important feature,
IMHO, for everyone working seriously with the result afterwards (and not
just plotting it).

3) I use different directories for components of my code, and use
addpath to access them.  The code invoking fem-fenics and my UFL file
are in one of those directories (say, A/), but when I try to use it from
a different one (B/), fem-fenics tries to access my UFL file in B/.
I've created a symlink B/problem.ufl -> A/problem.ufl for now, but I
think that UFL files should be read relative to the script using
import_ufl_*.  Or is it designed the way it is for some reason?

Thanks for the great work, I'm just starting to enjoy what you can do
with fem-fenics and it looks very good so far (for my own research's
requirements at least).

Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Marco Vassallo



On Mon, Mar 3, 2014 at 8:53 AM, Daniel Kraft <[hidden email]> wrote:
Hi!

I've recently started playing around with fem-fenics, and it works very
well for my application so far.  Here are just some questions I came
across and wanted to discuss:

1) Whenever I run my script using fem-fenics (presumably during the call
to import_ufl_Problem), I see a cc1plus process popping up and using 10
s or so finish.  (This can also be seen with the Poisson example.)  I
understand that this is necessary to compile my UFL form.  Is it
possible to somehow skip this step unless the UFL file was changed?  It
takes a not negligible amount of processing time for my code and I don't
think the UFL file will change often.

Yes we should improve it. For the moment you can do as follow:

Go to the file generate_makefile.m in the private directory and remove line 59:
 
    rm -f Makefile _@@UFL_NAME@@\n\

In this way the makefile is not removed after you call the import_ufl_problem() function
and thus the file Poisson.ufl should not be compiled again.

Otherwise, you can just comment import_ufl_problem() in your script file after that it has been called the first time.
If you don't change the .ufl file you don't need to run it again.

HTH

Marco

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave


_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Marco Vassallo
In reply to this post by Daniel Kraft



On Mon, Mar 3, 2014 at 8:53 AM, Daniel Kraft <[hidden email]> wrote:

2) Since I do not only want to plot the result but also work with it
further, I need to evaluate the result at my grid points.  With linear
Lagrange elements, I "could" use the coefficients obtained directly, but
this is probably a bad idea from the point of view of code design.  Thus
I'm using feval now, but it is not entirely clear to me how it is
supposed to be called.  The doc only says the second argument should be
the "coordinate" of evaluation, but doesn't specify how this coordinate
should look like.  It works for me now if I pass an array of x- and
y-coordinate.  I guess this is how the function is meant to be called?

Yes, sorry if it wasn't clear. You can add an example on the wiki [1].
 
Is it also possible to invoke it for lots of points at all?  (I think I
read somewhere that this is planned but not yet implemented ... just
checking what the current state is.)  This is a very important feature,
IMHO, for everyone working seriously with the result afterwards (and not
just plotting it).

You are right, I planned to do it. The function feval() is only a wrapper to the dolfin::eval()
function. At the moment I don't know any dolfin function which could evaluate lots of points
at the same time. An easy solution would be to add a for cycle in the feval.cc function
which evaluate the function for all the points given from the user.
I think that we can do either a function with a different signature:
 
  feval ( function function_name, Array<double> x_coordinates,
             Array<double> y_coordinates, Array<double> z_coordinates)

or a function with a similar signature as the one we are using now but receiving a matrix
of points and not an array. What do you think?
If you want to implement it or you have any better idea it would be great.

Marco

Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave


_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Daniel Kraft
In reply to this post by Marco Vassallo
Hi!

On 2014-03-03 11:13, Marco Vassallo wrote:

> On Mon, Mar 3, 2014 at 8:53 AM, Daniel Kraft <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi!
>
>     I've recently started playing around with fem-fenics, and it works very
>     well for my application so far.  Here are just some questions I came
>     across and wanted to discuss:
>
>     1) Whenever I run my script using fem-fenics (presumably during the call
>     to import_ufl_Problem), I see a cc1plus process popping up and using 10
>     s or so finish.  (This can also be seen with the Poisson example.)  I
>     understand that this is necessary to compile my UFL form.  Is it
>     possible to somehow skip this step unless the UFL file was changed?  It
>     takes a not negligible amount of processing time for my code and I don't
>     think the UFL file will change often.
>
> Yes we should improve it. For the moment you can do as follow:
>
> Go to the file generate_makefile.m in the private directory and remove
> line 59:
>  
>     rm -f Makefile _@@UFL_NAME@@\n\
>
> In this way the makefile is not removed after you call the
> import_ufl_problem() function
> and thus the file Poisson.ufl should not be compiled again.
>
> Otherwise, you can just comment import_ufl_problem() in your script file
> after that it has been called the first time.
> If you don't change the .ufl file you don't need to run it again.

Thanks for the suggestions!  I will probably just comment the
import_ufl_Problem line for now, that should be good enough for me.

Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Daniel Kraft
In reply to this post by Marco Vassallo
Hi!

On 2014-03-03 11:39, Marco Vassallo wrote:

> On Mon, Mar 3, 2014 at 8:53 AM, Daniel Kraft <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Is it also possible to invoke it for lots of points at all?  (I think I
>     read somewhere that this is planned but not yet implemented ... just
>     checking what the current state is.)  This is a very important feature,
>     IMHO, for everyone working seriously with the result afterwards (and not
>     just plotting it).
>
> You are right, I planned to do it. The function feval() is only a
> wrapper to the dolfin::eval()
> function. At the moment I don't know any dolfin function which could
> evaluate lots of points
> at the same time. An easy solution would be to add a for cycle in the
> feval.cc function
> which evaluate the function for all the points given from the user.
> I think that we can do either a function with a different signature:
>  
>   feval ( function function_name, Array<double> x_coordinates,
>              Array<double> y_coordinates, Array<double> z_coordinates)
>
> or a function with a similar signature as the one we are using now but
> receiving a matrix
> of points and not an array. What do you think?
> If you want to implement it or you have any better idea it would be great.

I would probably go for this signature anyway -- it seems more intuitive
to do "feval(func, x, y)" instead of "feval(func, [x, y])" since the
former is closer to "func(x, y)".

If it isn't a problem to make the old convention obsolete, I can work on
a patch to change the feval semantics that way (and also to handle
multiple points in a loop).  If we want to keep supporting the old call
(not sure how many users there are already out there), it should be easy
enough to handle that in case feval has only two arguments, and I can
also do that.

What do you think?

Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Marco Vassallo



On Mon, Mar 3, 2014 at 11:50 AM, Daniel Kraft <[hidden email]> wrote:
Hi!

On 2014-03-03 11:39, Marco Vassallo wrote:
> On Mon, Mar 3, 2014 at 8:53 AM, Daniel Kraft <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Is it also possible to invoke it for lots of points at all?  (I think I
>     read somewhere that this is planned but not yet implemented ... just
>     checking what the current state is.)  This is a very important feature,
>     IMHO, for everyone working seriously with the result afterwards (and not
>     just plotting it).
>
> You are right, I planned to do it. The function feval() is only a
> wrapper to the dolfin::eval()
> function. At the moment I don't know any dolfin function which could
> evaluate lots of points
> at the same time. An easy solution would be to add a for cycle in the
> feval.cc function
> which evaluate the function for all the points given from the user.
> I think that we can do either a function with a different signature:
>
>   feval ( function function_name, Array<double> x_coordinates,
>              Array<double> y_coordinates, Array<double> z_coordinates)
>
> or a function with a similar signature as the one we are using now but
> receiving a matrix
> of points and not an array. What do you think?
> If you want to implement it or you have any better idea it would be great.

I would probably go for this signature anyway -- it seems more intuitive
to do "feval(func, x, y)" instead of "feval(func, [x, y])" since the
former is closer to "func(x, y)".

If it isn't a problem to make the old convention obsolete, I can work on
a patch to change the feval semantics that way (and also to handle
multiple points in a loop).  If we want to keep supporting the old call
(not sure how many users there are already out there), it should be easy
enough to handle that in case feval has only two arguments, and I can
also do that.

What do you think?

In my opinion the syntax should be as close as possible to the one from FEniCS python.
You can give a look at what they do for the eval() function and try to reproduce it, even if it makes
my old syntax obsolete.

Marco

Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri


_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Daniel Kraft-2
Hi!

On 2014-03-03 13:01, Marco Vassallo wrote:

> On Mon, Mar 3, 2014 at 11:50 AM, Daniel Kraft <[hidden email]
> <mailto:[hidden email]>> wrote:
>     > I think that we can do either a function with a different signature:
>     >
>     >   feval ( function function_name, Array<double> x_coordinates,
>     >              Array<double> y_coordinates, Array<double> z_coordinates)
>     >
>     > or a function with a similar signature as the one we are using now but
>     > receiving a matrix
>     > of points and not an array. What do you think?
>     > If you want to implement it or you have any better idea it would
>     be great.
>
>     I would probably go for this signature anyway -- it seems more intuitive
>     to do "feval(func, x, y)" instead of "feval(func, [x, y])" since the
>     former is closer to "func(x, y)".
>
>     If it isn't a problem to make the old convention obsolete, I can work on
>     a patch to change the feval semantics that way (and also to handle
>     multiple points in a loop).  If we want to keep supporting the old call
>     (not sure how many users there are already out there), it should be easy
>     enough to handle that in case feval has only two arguments, and I can
>     also do that.
>
>     What do you think?
>
>
> In my opinion the syntax should be as close as possible to the one from
> FEniCS python.
> You can give a look at what they do for the eval() function and try to
> reproduce it, even if it makes
> my old syntax obsolete.
Looking at [1], it seems that they have the same syntax as you proposed.
 I. e., feval(func, [x, y]) or feval(func, [x, y, z]).

  [1]
http://fenicsproject.org/documentation/dolfin/1.3.0/python/programmers-reference/cpp/function/Function.html#dolfin.cpp.function.Function

My suggestion is still the following, which I find more natural:

* Allow feval(func, [coordinates]) as before for compatibility with the
Python version and the old version in fem-fenics.

* Implement feval(func, x, y) and feval(func, x, y, z), which is in my
opinion more natural.

* In the new version, allow x, y and z to be vectors or matrices so that
one can evaluate the function coordinate-wise for a bunch of points at once.

Please let me know what you think about this proposal -- if it is ok,
I'll work on a patch.

Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri


_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Marco Vassallo



On Tue, Mar 4, 2014 at 8:30 AM, Daniel Kraft <[hidden email]> wrote:
Hi!

On 2014-03-03 13:01, Marco Vassallo wrote:
> On Mon, Mar 3, 2014 at 11:50 AM, Daniel Kraft <[hidden email]
> <mailto:[hidden email]>> wrote:
>     > I think that we can do either a function with a different signature:
>     >
>     >   feval ( function function_name, Array<double> x_coordinates,
>     >              Array<double> y_coordinates, Array<double> z_coordinates)
>     >
>     > or a function with a similar signature as the one we are using now but
>     > receiving a matrix
>     > of points and not an array. What do you think?
>     > If you want to implement it or you have any better idea it would
>     be great.
>
>     I would probably go for this signature anyway -- it seems more intuitive
>     to do "feval(func, x, y)" instead of "feval(func, [x, y])" since the
>     former is closer to "func(x, y)".
>
>     If it isn't a problem to make the old convention obsolete, I can work on
>     a patch to change the feval semantics that way (and also to handle
>     multiple points in a loop).  If we want to keep supporting the old call
>     (not sure how many users there are already out there), it should be easy
>     enough to handle that in case feval has only two arguments, and I can
>     also do that.
>
>     What do you think?
>
>
> In my opinion the syntax should be as close as possible to the one from
> FEniCS python.
> You can give a look at what they do for the eval() function and try to
> reproduce it, even if it makes
> my old syntax obsolete.

Looking at [1], it seems that they have the same syntax as you proposed.
 I. e., feval(func, [x, y]) or feval(func, [x, y, z]).

  [1]
http://fenicsproject.org/documentation/dolfin/1.3.0/python/programmers-reference/cpp/function/Function.html#dolfin.cpp.function.Function

My suggestion is still the following, which I find more natural:

* Allow feval(func, [coordinates]) as before for compatibility with the
Python version and the old version in fem-fenics.

* Implement feval(func, x, y) and feval(func, x, y, z), which is in my
opinion more natural.

* In the new version, allow x, y and z to be vectors or matrices so that
one can evaluate the function coordinate-wise for a bunch of points at once.

Please let me know what you think about this proposal -- if it is ok,
I'll work on a patch.

The main goal for fem-fenics in the next months is to be integrated in FEniCS,
 and thus in my opinion it is important to have a syntax as close as possible to it.
On the other side, feval() is also a function in Octave, where the syntax is
[y1, y2, ...] = feval(fname, x1, ..., xn)
 
as you proposed. I think that having the two different functions would be great, so that
both FEniCS and Octave users have something close to what they are used to.

Thanks,

Marco

Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri



_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Daniel Kraft-2
Hi!

On 2014-03-04 09:59, Marco Vassallo wrote:

> On Tue, Mar 4, 2014 at 8:30 AM, Daniel Kraft <[hidden email]
>     Looking at [1], it seems that they have the same syntax as you proposed.
>      I. e., feval(func, [x, y]) or feval(func, [x, y, z]).
>
>       [1]
>     http://fenicsproject.org/documentation/dolfin/1.3.0/python/programmers-reference/cpp/function/Function.html#dolfin.cpp.function.Function
>
>     My suggestion is still the following, which I find more natural:
>
>     * Allow feval(func, [coordinates]) as before for compatibility with the
>     Python version and the old version in fem-fenics.
>
>     * Implement feval(func, x, y) and feval(func, x, y, z), which is in my
>     opinion more natural.
>
>     * In the new version, allow x, y and z to be vectors or matrices so that
>     one can evaluate the function coordinate-wise for a bunch of points
>     at once.
>
>     Please let me know what you think about this proposal -- if it is ok,
>     I'll work on a patch.
>
> The main goal for fem-fenics in the next months is to be integrated in
> FEniCS,
>  and thus in my opinion it is important to have a syntax as close as
> possible to it.
> On the other side, feval() is also a function in Octave, where the syntax is
> [y1, y2, ...] = feval(fname, x1, ..., xn)
>  
> as you proposed. I think that having the two different functions would
> be great, so that
> both FEniCS and Octave users have something close to what they are used to.
We can support both versions with "feval", since we can decide depending
on the number of arguments (2 arguments -> 2nd one is array und use
"Python" convention, 3 or 4 arguments -> use "Octave" convention).  Is
that what you mean by "two different functions"?  Or do you really
suggest to use different names for them?

If the former, I agree and can implement that.

Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri


_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

c.-2
In reply to this post by Daniel Kraft

On 3 Mar 2014, at 12:50, Daniel Kraft <[hidden email]> wrote:

> I would probably go for this signature anyway -- it seems more intuitive
> to do "feval(func, x, y)" instead of "feval(func, [x, y])" since the
> former is closer to "func(x, y)".

the approach with multiple coordinates collected into a matrix is more convenient,
for example, for computing the value of the function at all the nodes of a mesh using
the p field of the mesh structure.

> If it isn't a problem to make the old convention obsolete,

yes it is a problem, consistency with FEnics syntax is crucial.

c.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Marco Vassallo
In reply to this post by Daniel Kraft-2



On Tue, Mar 4, 2014 at 9:29 AM, Daniel Kraft <[hidden email]> wrote:
Hi!

On 2014-03-04 09:59, Marco Vassallo wrote:
> On Tue, Mar 4, 2014 at 8:30 AM, Daniel Kraft <[hidden email]
>     Looking at [1], it seems that they have the same syntax as you proposed.
>      I. e., feval(func, [x, y]) or feval(func, [x, y, z]).
>
>       [1]
>     http://fenicsproject.org/documentation/dolfin/1.3.0/python/programmers-reference/cpp/function/Function.html#dolfin.cpp.function.Function
>
>     My suggestion is still the following, which I find more natural:
>
>     * Allow feval(func, [coordinates]) as before for compatibility with the
>     Python version and the old version in fem-fenics.
>
>     * Implement feval(func, x, y) and feval(func, x, y, z), which is in my
>     opinion more natural.
>
>     * In the new version, allow x, y and z to be vectors or matrices so that
>     one can evaluate the function coordinate-wise for a bunch of points
>     at once.
>
>     Please let me know what you think about this proposal -- if it is ok,
>     I'll work on a patch.
>
> The main goal for fem-fenics in the next months is to be integrated in
> FEniCS,
>  and thus in my opinion it is important to have a syntax as close as
> possible to it.
> On the other side, feval() is also a function in Octave, where the syntax is
> [y1, y2, ...] = feval(fname, x1, ..., xn)
>
> as you proposed. I think that having the two different functions would
> be great, so that
> both FEniCS and Octave users have something close to what they are used to.

We can support both versions with "feval", since we can decide depending
on the number of arguments (2 arguments -> 2nd one is array und use
"Python" convention, 3 or 4 arguments -> use "Octave" convention).  Is
that what you mean by "two different functions"?  Or do you really
suggest to use different names for them?

If the former, I agree and can implement that.

Hi,

yes the former, sorry if it wasn't clear.

Marco
Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri



_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: fem-fenics questions

Marco Vassallo



On Tue, Mar 4, 2014 at 10:02 AM, Marco Vassallo <[hidden email]> wrote:



On Tue, Mar 4, 2014 at 9:29 AM, Daniel Kraft <[hidden email]> wrote:
Hi!

On 2014-03-04 09:59, Marco Vassallo wrote:
> On Tue, Mar 4, 2014 at 8:30 AM, Daniel Kraft <[hidden email]
>     Looking at [1], it seems that they have the same syntax as you proposed.
>      I. e., feval(func, [x, y]) or feval(func, [x, y, z]).
>
>       [1]
>     http://fenicsproject.org/documentation/dolfin/1.3.0/python/programmers-reference/cpp/function/Function.html#dolfin.cpp.function.Function
>
>     My suggestion is still the following, which I find more natural:
>
>     * Allow feval(func, [coordinates]) as before for compatibility with the
>     Python version and the old version in fem-fenics.
>
>     * Implement feval(func, x, y) and feval(func, x, y, z), which is in my
>     opinion more natural.
>
>     * In the new version, allow x, y and z to be vectors or matrices so that
>     one can evaluate the function coordinate-wise for a bunch of points
>     at once.
>
>     Please let me know what you think about this proposal -- if it is ok,
>     I'll work on a patch.
>
> The main goal for fem-fenics in the next months is to be integrated in
> FEniCS,
>  and thus in my opinion it is important to have a syntax as close as
> possible to it.
> On the other side, feval() is also a function in Octave, where the syntax is
> [y1, y2, ...] = feval(fname, x1, ..., xn)
>
> as you proposed. I think that having the two different functions would
> be great, so that
> both FEniCS and Octave users have something close to what they are used to.

We can support both versions with "feval", since we can decide depending
on the number of arguments (2 arguments -> 2nd one is array und use
"Python" convention, 3 or 4 arguments -> use "Octave" convention).  Is
that what you mean by "two different functions"?  Or do you really
suggest to use different names for them?

If the former, I agree and can implement that.

Hi,

yes the former, sorry if it wasn't clear.

Sorry I didn't read Carlo suggestion.

"the approach with multiple coordinates collected into a matrix is more convenient,
for example, for computing the value of the function at all the nodes of a mesh using
the p field of the mesh structure."

I don't really know which one is more useful and intuitive. As far as I'm concerned, if the FEniCS
syntax is supported and extended to receive also an array for each coordinate I'm ok.
If you want to add something else and the syntax is still clear for the user i think that it is fine.

Marco
Marco
Yours,
Daniel

--
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri




_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave