dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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)