dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Sunday February 13 2011 12:28:30 Anders Logg wrote:
> 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?

I am a bit sloppy in my writings today... That line should have been removed 
before I sent the email :P 

Johan