dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Feb 13, 2011 at 12:13:43PM -0800, Johan Hake wrote:
> On Sunday February 13 2011 09:19:35 Anders Logg wrote:
> > On Fri, Feb 11, 2011 at 11:14:33AM -0800, Johan Hake wrote:
> > > On Friday February 11 2011 11:06:15 Anders Logg wrote:
> > > > On Fri, Feb 11, 2011 at 10:10:51AM -0800, Johan Hake wrote:
> > > > > On Friday February 11 2011 09:54:39 Anders Logg wrote:
> > > > > > On Fri, Feb 11, 2011 at 08:08:32AM -0800, Johan Hake wrote:
> > > > > > > On Friday February 11 2011 01:16:31 Anders Logg wrote:
> > > > > > > > How is DOLFIN_EPS treated in Expressions and boundary
> > > > > > > > conditions (using compile_subdomains)?
> > > > > > > >
> > > > > > > > I thought that DOLFIN_EPS was known to the JIT compiler.
> > > > > > > >
> > > > > > > > Here are somethings I noted while debugging a code:
> > > > > > > >
> > > > > > > > 1. f = Expression("sin(x[0] + DOLFIN_EPS)") does not compile.
> > > > > > > >
> > > > > > > > The log file pointed to by the JIT compiler says "syntax error"
> > > > > > > > and the generated code in .i file found in the same directory
> > > > > > > > contains this:
> > > > > > > >
> > > > > > > > class Expression_5d66d4e2b02f54f6088fc61767e40073: public
> > > > > > > > Expression {
> > > > > > > >
> > > > > > > > public:
> > > > > > > >   double DOLFIN_EPS;
> > > > > > > >   Expression_5d66d4e2b02f54f6088fc61767e40073():Expression()
> > > > > > > >   {
> > > > > > > >
> > > > > > > >     DOLFIN_EPS = 0.0;
> > > > > > > >
> > > > > > > >   }
> > > > > > > >
> > > > > > > >   void eval(dolfin::Array<double>& values, const
> > > > > > > >   dolfin::Array<double>& x) const
> > > > > > > >   {
> > > > > > > >
> > > > > > > >     values[0] = sin(x[0] + DOLFIN_EPS);
> > > > > > > >
> > > > > > > >   }
> > > > > > > >
> > > > > > > > };
> > > > > > > >
> > > > > > > > So there are two problems here:
> > > > > > > >
> > > > > > > > 1.a) The JIT compiler fails to compile the Expression f which
> > > > > > > > looks like a valid expression to me
> > > > > > > >
> > > > > > > > 1.b) DOLFIN_EPS is set to zero.
> > > > > > >
> > > > > > > Now it doesn't.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > > > 2. When trying something similar with compile_subdomains, it
> > > > > > > > seems that
> > > > > > > >
> > > > > > > >   compile_subdomains("x[0] < DOLFIN_EPS")
> > > > > > > >
> > > > > > > > compiles and produces correct code. In particular the .i file
> > > > > > > > does not contain DOLFIN_EPS = 0.0.
> > > > > > >
> > > > > > > subdomain treats DOLFIN_EPS and on_boundary seperately.
> > > > > > >
> > > > > > > > But the magic for creating variables is a bit too clever. I had
> > > > > > > > a typo which said "DOFLIN_EPS" instead of "DOLFIN_EPS" which
> > > > > > > > compiles without any warnings and DOFLIN_EPS is set to zero.
> > > > > > > > That's a litle dangerous.
> > > > > > >
> > > > > > > You cannot blame your typos on compile expressions ;)
> > > > > >
> > > > > > I just did! ;-)
> > > > > >
> > > > > > Would it be possible (and desirable) to require default values for
> > > > > > all variables in an Expression?
> > > > > >
> > > > > > f = Expression("a*x[0]", a=2.0)
> > > > > > f.a = 3.0
> > > > >
> > > > > A good point. It would probably require to hide the kwarg: element,
> > > > > cell, degree, into a **kwargs, making them less transparent. We
> > > > > could also add the default value **kwargs after the above mention
> > > > > kwargs. If we go for this we
> > > > >
> > > > > can end up with syntax like:
> > > > >   f = Expression("a*x[0]", element=some_element, a=2.0)
> > > > >
> > > > > instead of:
> > > > >   f = Expression("a*x[0]", a=2.0, element=some_element)
> > > > >
> > > > > I think the last syntax makes more sense, but it requires more hidden
> > > > > logics.
> > > >
> > > > If it's important to keep the default argumets visible, you could add
> > > > something like variabes = {"a": 2.0, "b": 3.0}.
> > >
> > > No, I think it is nice to have them as **kwargs.
> > >
> > > My point is that these arguments need to be last in a function signature.
> > > That again means that they need to come after default kwargs like
> > > element, cell, degree, forcing the syntax of the first example above.
> > >
> > > However it is more intutive to keep initialization of these argument
> > > closest to the string, the second syntax example. But then we need to
> > > conceal valid kwargs into an anonymous *kwargs.
> > >
> > > That said, I *really* think it is bad habit to conceal valid keyword
> > > arguments
> > >
> > > into **kwargs. I cannot tell how many times I have hit:
> > >   plot?
> > >
> > > in ipython just to get dissapointed of what I need to feed it.
> > >
> > > Johan
> >
> > ok. This would be a nice feature to have. Add it if/when you feel like
> > it, but it might be good to have it in place before the release of 1.0
> > since it means a change in the interface.
>
> Will fix for 1.0. We can also include a debug (info?) message where all auto
> declared variables are presented for the user with the assigned default
> values.
>
> Johan
>
> How do you feel of keeping the kwargs default, (or vars or something)

What do you mean? What would the syntax be?

--
Anders