subject:"Re\: \[DOLFIN\-dev\] \[HG DOLFIN\] merge"



Anders Logg wrote:
 On Tue, Sep 29, 2009 at 10:37:51PM +0100, Garth N. Wells wrote:

 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
 I'm looking forward to seeing the new code. Is all the old functionality
 still in place?
 Yes and no. Everything except the generated CoefficientSet stuff
 should still work in the C++ interface, but the Python interface won't
 work until the corresponding changes have been made on the Python side.

 Will CoefficientSet come back? I was using it, but I forgot the
 important reason why. If I do

 Form* a = new Poisson::BilinearForm(V, V);

 I can't do

a-g g;

 but I could do

 Form* a = new Poisson::BilinearForm(V, V, coefficient_set);

 I can of course use dynamic cast and then attach functions.
 
 We could easily add functionality for doing
 
   a-set_coefficient(g, g);
 
 Would that be enough? 

That's half the story. The other half is cases with a lot of 
coefficients (10) and where the bilinear and linear forms have these 
coefficients in common. CoefficientSet reduces by half the number of 
lines of code. There is probably a simply approach without much extra 
code generation but I haven't given it much thought yet.

Garth

This would be a simple function implemented in
 the C++ Form class. It's better if we can avoid generating code if
 something can be implemented directly in the C++ class.
 
 --
 Anders
 
 
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev

___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Johan Hake wrote:
 On Tuesday 29 September 2009 22:39:02 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
 On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
 I'm looking forward to seeing the new code. Is all the old
 functionality still in place?
 Yes and no. Everything except the generated CoefficientSet stuff
 should still work in the C++ interface, but the Python interface won't
 work until the corresponding changes have been made on the Python side.

 Here's some more information about the changes:

 1. Subclassing Function and overloading eval() has been replaced by
 the Expression subclass which works in the same way with eval().

 2. All the old functionality/logic of the Function class is still in
 place but it can now be cleaned up and simplified.

 3. A Function will now *always* have a FunctionSpace and *always* have
 a vector.
 Good!

 4. An Expression *never* has a FunctionSpace and *never* has a vector.
 Also good! Should we consider (re-)adding a value_rank and dimension
 method to the expression class?
 Yes, perhaps. But it's very convenient not having to specify it. We
 could make it optional.
 
 Ok. No big dealt for me. In Python we can solve this for Expressions anyway.
 
 Also what would the preferred solution be for a Python expression. It
 should not have a FunctionSpace but we need a FunctionSpace to initialize
 the ufl.Function. Or rather the ufl.FiniteElement that comes with the
 FunctionSpace.

 I see two alternatives:
 1) Instantiate an Expression with a FunctionSpace, then let the
 FunctionSpace reside in the Python layer. The ufl.FiniteElement is used
 to instantiate the ufl.Function.

 2) Instantiate an Expression with a ufl.FiniteElement. The problem with
 this is that we have not exposed the ufl.FiniteElement in the PyDOLFIN
 interface previously. But the confusion with an expression having a
 FunctionSpace is partly avoided.

 In both cases I could add checks for rank and dimensions in the Python
 layer if we decides to not require it for the C++ interface.
 I think we discussed the possibility of detecting the value dimension
 from the expression 
 
 Yes, but a user can initialize an Expression with the wrong 
 FunctionSpace/FiniteElement compared to what the expression looks like.
 
 and automatically using piecewise linears if not
 otherwise specified. 

 The function space could be an optional argument:

   f = Expression(sin(x[0]), V=V)
 
 We cannot automatically figure out the topological dimension, can we?


We can from the function space.

 Should we require that an Expression is instantiated using just a 
 ufl.FiniteElement? In this way it would be clear that the Expression is not 
 defined in a FunctionSpace? It would then look like:
 
   f = Expression(V.ufl_element(),sin(x[0]))
 
 or something.
 

Doesn't this defeat the purpose of having 'Expression' (i.e. no function 
space)? Could we just pass the cell type?

Garth

 Then it would be clear that f is not a function in V, but V is only
 some additional information about how f should be used in forms.

 5. FunctionSpaces are not attached to coefficients when doing a.f = f.

 6. The DOLFIN wrappers have been simplified and now rely on the
 new very simple CoefficientAssigner class.

 7. The assembler works through the common base class Coefficient, in
 particular the restrict() function for restricting to a local element.
 Nice!
 This also removes one of the too many interpolate() functions which is
 good.
 
 Ok.
 
 Johan
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-30 Thread Johan Hake

On Wednesday 30 September 2009 09:12:46 Garth N. Wells wrote:
 Johan Hake wrote:
  On Tuesday 29 September 2009 22:39:02 Anders Logg wrote:
  On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
  On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
  On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
  I'm looking forward to seeing the new code. Is all the old
  functionality still in place?
 
  Yes and no. Everything except the generated CoefficientSet stuff
  should still work in the C++ interface, but the Python interface won't
  work until the corresponding changes have been made on the Python
  side.
 
  Here's some more information about the changes:
 
  1. Subclassing Function and overloading eval() has been replaced by
  the Expression subclass which works in the same way with eval().
 
  2. All the old functionality/logic of the Function class is still in
  place but it can now be cleaned up and simplified.
 
  3. A Function will now *always* have a FunctionSpace and *always* have
  a vector.
 
  Good!
 
  4. An Expression *never* has a FunctionSpace and *never* has a vector.
 
  Also good! Should we consider (re-)adding a value_rank and dimension
  method to the expression class?
 
  Yes, perhaps. But it's very convenient not having to specify it. We
  could make it optional.
 
  Ok. No big dealt for me. In Python we can solve this for Expressions
  anyway.
 
  Also what would the preferred solution be for a Python expression. It
  should not have a FunctionSpace but we need a FunctionSpace to
  initialize the ufl.Function. Or rather the ufl.FiniteElement that comes
  with the FunctionSpace.
 
  I see two alternatives:
  1) Instantiate an Expression with a FunctionSpace, then let the
  FunctionSpace reside in the Python layer. The ufl.FiniteElement is used
  to instantiate the ufl.Function.
 
  2) Instantiate an Expression with a ufl.FiniteElement. The problem with
  this is that we have not exposed the ufl.FiniteElement in the PyDOLFIN
  interface previously. But the confusion with an expression having a
  FunctionSpace is partly avoided.
 
  In both cases I could add checks for rank and dimensions in the Python
  layer if we decides to not require it for the C++ interface.
 
  I think we discussed the possibility of detecting the value dimension
  from the expression
 
  Yes, but a user can initialize an Expression with the wrong
  FunctionSpace/FiniteElement compared to what the expression looks like.
 
  and automatically using piecewise linears if not
  otherwise specified.
 
  The function space could be an optional argument:
 
f = Expression(sin(x[0]), V=V)
 
  We cannot automatically figure out the topological dimension, can we?
 
 We can from the function space.

Yes, but when the user does not pass the space we cannot.

  Should we require that an Expression is instantiated using just a
  ufl.FiniteElement? In this way it would be clear that the Expression is
  not defined in a FunctionSpace? It would then look like:
 
f = Expression(V.ufl_element(),sin(x[0]))
 
  or something.
 
 Doesn't this defeat the purpose of having 'Expression' (i.e. no function
 space)? Could we just pass the cell type?

Not sure the cell type would fit all purposes. When we compile an Expression 
using the extended syntax where the user define the whole C++ code, we cannot 
automatically extract the value rank. 

We also need to pass the ufl.FiniteElement in some way so the ufl.Function can 
be initialized correctly. This so we can define forms using the newly created 
Expression (i.e. ufl.Function). This was previously done by using the 
ufl.element passed by the FunctionSpace. 


On a side note:
Should we consider changing the name of ufl.Function to ufl.Coefficient? I do 
not think the name is used in UFL now.

Johan

 Garth
 
  Then it would be clear that f is not a function in V, but V is only
  some additional information about how f should be used in forms.
 
  5. FunctionSpaces are not attached to coefficients when doing a.f = f.
 
  6. The DOLFIN wrappers have been simplified and now rely on the
  new very simple CoefficientAssigner class.
 
  7. The assembler works through the common base class Coefficient, in
  particular the restrict() function for restricting to a local element.
 
  Nice!
 
  This also removes one of the too many interpolate() functions which is
  good.
 
  Ok.
 
  Johan
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Anders Logg wrote:
 On Tue, Sep 29, 2009 at 10:00:59PM +0100, Garth N. Wells wrote:
 
 2. Use the Expression class in demos where appropriate (just need to
 change the class name, everything else is the same).

 Haven't you already done this everywhere?
 
 No, just in the Poisson demo. I'll fix the others later.
 

Any thoughts on how to deal with Dirichlet bcs? Constant works because 
it is a subclass of Function. Do we need a common base class for 
Function and Expression which has an eval function?

Garth

 --
 Anders
 
 
 Garth

 3. Fix Python interface.

 I won't be touching it until tomorrow afternoon so feel free to poke
 around.


 

 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Garth N. Wells wrote:
 
 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 10:00:59PM +0100, Garth N. Wells wrote:

 2. Use the Expression class in demos where appropriate (just need to
 change the class name, everything else is the same).

 Haven't you already done this everywhere?
 No, just in the Poisson demo. I'll fix the others later.

 
 Any thoughts on how to deal with Dirichlet bcs? Constant works because 
 it is a subclass of Function. Do we need a common base class for 
 Function and Expression which has an eval function?
 

I guess we could interpolate an Expression in an FE space inside 
DirichletBC, but this might get a bit expensive for nonlinear problems.

Garth

 Garth
 
 --
 Anders


 Garth

 3. Fix Python interface.

 I won't be touching it until tomorrow afternoon so feel free to poke
 around.

 

 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-30 Thread Johan Hake

On Wednesday 30 September 2009 09:58:01 Garth N. Wells wrote:
 Anders Logg wrote:
  On Tue, Sep 29, 2009 at 10:00:59PM +0100, Garth N. Wells wrote:
  2. Use the Expression class in demos where appropriate (just need to
  change the class name, everything else is the same).
 
  Haven't you already done this everywhere?
 
  No, just in the Poisson demo. I'll fix the others later.
 
 Any thoughts on how to deal with Dirichlet bcs? Constant works because
 it is a subclass of Function. Do we need a common base class for
 Function and Expression which has an eval function?

Yes, isn't this natural? It is at least nice to have the possibility to call 
eval on a Function using interpolating. 

I suppose it is enough to only provide the simple eval(value,x) function?

Johan

 Garth
 
  --
  Anders
 
  Garth
 
  3. Fix Python interface.
 
  I won't be touching it until tomorrow afternoon so feel free to poke
  around.
 
  
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Johan Hake wrote:
 On Wednesday 30 September 2009 09:58:01 Garth N. Wells wrote:
 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 10:00:59PM +0100, Garth N. Wells wrote:
 2. Use the Expression class in demos where appropriate (just need to
 change the class name, everything else is the same).
 Haven't you already done this everywhere?
 No, just in the Poisson demo. I'll fix the others later.
 Any thoughts on how to deal with Dirichlet bcs? Constant works because
 it is a subclass of Function. Do we need a common base class for
 Function and Expression which has an eval function?
 
 Yes, isn't this natural? It is at least nice to have the possibility to call 
 eval on a Function using interpolating. 
 
 I suppose it is enough to only provide the simple eval(value,x) function?


Anders is one step ahead of us - he added the class Coefficient which has:

virtual void eval(double* values, const double* x) const;

virtual void eval(double* values, const Data data) const;

virtual void restrict(double* w,
   const FiniteElement element,
   const Cell dolfin_cell,
   const ufc::cell ufc_cell,
   int local_facet) const;

virtual void evaluate(double* values,
   const double* coordinates,
   const ufc::cell cell) const;

Garth

 Johan
 
 Garth

 --
 Anders

 Garth

 3. Fix Python interface.

 I won't be touching it until tomorrow afternoon so feel free to poke
 around.
 

 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev



___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Wed, Sep 30, 2009 at 09:31:01AM +0200, Johan Hake wrote:
 On Wednesday 30 September 2009 09:12:46 Garth N. Wells wrote:
  Johan Hake wrote:
   On Tuesday 29 September 2009 22:39:02 Anders Logg wrote:
   On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
   On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
   On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
   I'm looking forward to seeing the new code. Is all the old
   functionality still in place?
  
   Yes and no. Everything except the generated CoefficientSet stuff
   should still work in the C++ interface, but the Python interface won't
   work until the corresponding changes have been made on the Python
   side.
  
   Here's some more information about the changes:
  
   1. Subclassing Function and overloading eval() has been replaced by
   the Expression subclass which works in the same way with eval().
  
   2. All the old functionality/logic of the Function class is still in
   place but it can now be cleaned up and simplified.
  
   3. A Function will now *always* have a FunctionSpace and *always* have
   a vector.
  
   Good!
  
   4. An Expression *never* has a FunctionSpace and *never* has a vector.
  
   Also good! Should we consider (re-)adding a value_rank and dimension
   method to the expression class?
  
   Yes, perhaps. But it's very convenient not having to specify it. We
   could make it optional.
  
   Ok. No big dealt for me. In Python we can solve this for Expressions
   anyway.
  
   Also what would the preferred solution be for a Python expression. It
   should not have a FunctionSpace but we need a FunctionSpace to
   initialize the ufl.Function. Or rather the ufl.FiniteElement that comes
   with the FunctionSpace.
  
   I see two alternatives:
   1) Instantiate an Expression with a FunctionSpace, then let the
   FunctionSpace reside in the Python layer. The ufl.FiniteElement is used
   to instantiate the ufl.Function.
  
   2) Instantiate an Expression with a ufl.FiniteElement. The problem with
   this is that we have not exposed the ufl.FiniteElement in the PyDOLFIN
   interface previously. But the confusion with an expression having a
   FunctionSpace is partly avoided.
  
   In both cases I could add checks for rank and dimensions in the Python
   layer if we decides to not require it for the C++ interface.
  
   I think we discussed the possibility of detecting the value dimension
   from the expression
  
   Yes, but a user can initialize an Expression with the wrong
   FunctionSpace/FiniteElement compared to what the expression looks like.
  
   and automatically using piecewise linears if not
   otherwise specified.
  
   The function space could be an optional argument:
  
 f = Expression(sin(x[0]), V=V)
  
   We cannot automatically figure out the topological dimension, can we?
  
  We can from the function space.
 
 Yes, but when the user does not pass the space we cannot.
 
   Should we require that an Expression is instantiated using just a
   ufl.FiniteElement? In this way it would be clear that the Expression is
   not defined in a FunctionSpace? It would then look like:
  
 f = Expression(V.ufl_element(),sin(x[0]))
  
   or something.
  
  Doesn't this defeat the purpose of having 'Expression' (i.e. no function
  space)? Could we just pass the cell type?
 
 Not sure the cell type would fit all purposes. When we compile an Expression 
 using the extended syntax where the user define the whole C++ code, we cannot 
 automatically extract the value rank. 

 We also need to pass the ufl.FiniteElement in some way so the ufl.Function 
 can 
 be initialized correctly. This so we can define forms using the newly created 
 Expression (i.e. ufl.Function). This was previously done by using the 
 ufl.element passed by the FunctionSpace. 

What we need is the UFL FiniteElement. This can be extracted from any
of the following:

  1. The shape and the expression (if we assume piecewise linears)
  2. A UFL FiniteElement
  3. A FunctionSpace

Perhaps we should allow all three? The basic usage would be

  f = Expression(sin(x[0]), triangle)

It might also be possible to leave the shape as undefined and then
automatically set the shape during assembly.

 On a side note:
 Should we consider changing the name of ufl.Function to ufl.Coefficient? I do 
 not think the name is used in UFL now.

Yes, that seems like a good idea. Any objections from Martin?

-- 
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Wed, Sep 30, 2009 at 08:58:01AM +0100, Garth N. Wells wrote:
 
 
 Anders Logg wrote:
  On Tue, Sep 29, 2009 at 10:00:59PM +0100, Garth N. Wells wrote:
  
  2. Use the Expression class in demos where appropriate (just need to
  change the class name, everything else is the same).
 
  Haven't you already done this everywhere?
  
  No, just in the Poisson demo. I'll fix the others later.
  
 
 Any thoughts on how to deal with Dirichlet bcs? Constant works because 
 it is a subclass of Function. Do we need a common base class for 
 Function and Expression which has an eval function?

We could add eval() to the Coefficient interface. Both Expression and
Function already have an eval() function.

-- 
Anders


 Garth
 
  Garth
 
  3. Fix Python interface.
 
  I won't be touching it until tomorrow afternoon so feel free to poke
  around.
 
 
  
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Wed, Sep 30, 2009 at 08:10:11AM +0100, Garth N. Wells wrote:
 
 
 Anders Logg wrote:
  On Tue, Sep 29, 2009 at 10:37:51PM +0100, Garth N. Wells wrote:
 
  Anders Logg wrote:
  On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
  I'm looking forward to seeing the new code. Is all the old functionality
  still in place?
  Yes and no. Everything except the generated CoefficientSet stuff
  should still work in the C++ interface, but the Python interface won't
  work until the corresponding changes have been made on the Python side.
 
  Will CoefficientSet come back? I was using it, but I forgot the
  important reason why. If I do
 
  Form* a = new Poisson::BilinearForm(V, V);
 
  I can't do
 
 a-g g;
 
  but I could do
 
  Form* a = new Poisson::BilinearForm(V, V, coefficient_set);
 
  I can of course use dynamic cast and then attach functions.
  
  We could easily add functionality for doing
  
a-set_coefficient(g, g);
  
  Would that be enough? 
 
 That's half the story. The other half is cases with a lot of 
 coefficients (10) and where the bilinear and linear forms have these 
 coefficients in common. CoefficientSet reduces by half the number of 
 lines of code. There is probably a simply approach without much extra 
 code generation but I haven't given it much thought yet.

It should not be much work to reimplement CoefficientSet directly in
DOLFIN (without any need for generating the code for it).

I'll put in on the stack.

-- 
Anders


 Garth
 
 This would be a simple function implemented in
  the C++ Form class. It's better if we can avoid generating code if
  something can be implemented directly in the C++ class.
  
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Wed, Sep 30, 2009 at 11:23:21AM +0200, Anders Logg wrote:
 On Wed, Sep 30, 2009 at 08:58:01AM +0100, Garth N. Wells wrote:
  
  
  Anders Logg wrote:
   On Tue, Sep 29, 2009 at 10:00:59PM +0100, Garth N. Wells wrote:
   
   2. Use the Expression class in demos where appropriate (just need to
   change the class name, everything else is the same).
  
   Haven't you already done this everywhere?
   
   No, just in the Poisson demo. I'll fix the others later.
   
  
  Any thoughts on how to deal with Dirichlet bcs? Constant works because 
  it is a subclass of Function. Do we need a common base class for 
  Function and Expression which has an eval function?
 
 We could add eval() to the Coefficient interface. Both Expression and
 Function already have an eval() function.

Stupid comment. This is already there.

-- 
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-30 Thread Johan Hake

On Wednesday 30 September 2009 11:22:14 Anders Logg wrote:
 On Wed, Sep 30, 2009 at 09:31:01AM +0200, Johan Hake wrote:
  On Wednesday 30 September 2009 09:12:46 Garth N. Wells wrote:
   Johan Hake wrote:
On Tuesday 29 September 2009 22:39:02 Anders Logg wrote:
On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
I'm looking forward to seeing the new code. Is all the old
functionality still in place?
   
Yes and no. Everything except the generated CoefficientSet stuff
should still work in the C++ interface, but the Python interface
won't work until the corresponding changes have been made on the
Python side.
   
Here's some more information about the changes:
   
1. Subclassing Function and overloading eval() has been replaced
by the Expression subclass which works in the same way with
eval().
   
2. All the old functionality/logic of the Function class is still
in place but it can now be cleaned up and simplified.
   
3. A Function will now *always* have a FunctionSpace and *always*
have a vector.
   
Good!
   
4. An Expression *never* has a FunctionSpace and *never* has a
vector.
   
Also good! Should we consider (re-)adding a value_rank and
dimension method to the expression class?
   
Yes, perhaps. But it's very convenient not having to specify it. We
could make it optional.
   
Ok. No big dealt for me. In Python we can solve this for Expressions
anyway.
   
Also what would the preferred solution be for a Python expression.
It should not have a FunctionSpace but we need a FunctionSpace to
initialize the ufl.Function. Or rather the ufl.FiniteElement that
comes with the FunctionSpace.
   
I see two alternatives:
1) Instantiate an Expression with a FunctionSpace, then let the
FunctionSpace reside in the Python layer. The ufl.FiniteElement is
used to instantiate the ufl.Function.
   
2) Instantiate an Expression with a ufl.FiniteElement. The problem
with this is that we have not exposed the ufl.FiniteElement in the
PyDOLFIN interface previously. But the confusion with an expression
having a FunctionSpace is partly avoided.
   
In both cases I could add checks for rank and dimensions in the
Python layer if we decides to not require it for the C++ interface.
   
I think we discussed the possibility of detecting the value
dimension from the expression
   
Yes, but a user can initialize an Expression with the wrong
FunctionSpace/FiniteElement compared to what the expression looks
like.
   
and automatically using piecewise linears if not
otherwise specified.
   
The function space could be an optional argument:
   
  f = Expression(sin(x[0]), V=V)
   
We cannot automatically figure out the topological dimension, can we?
  
   We can from the function space.
 
  Yes, but when the user does not pass the space we cannot.
 
Should we require that an Expression is instantiated using just a
ufl.FiniteElement? In this way it would be clear that the Expression
is not defined in a FunctionSpace? It would then look like:
   
  f = Expression(V.ufl_element(),sin(x[0]))
   
or something.
  
   Doesn't this defeat the purpose of having 'Expression' (i.e. no
   function space)? Could we just pass the cell type?
 
  Not sure the cell type would fit all purposes. When we compile an
  Expression using the extended syntax where the user define the whole C++
  code, we cannot automatically extract the value rank.
 
  We also need to pass the ufl.FiniteElement in some way so the
  ufl.Function can be initialized correctly. This so we can define forms
  using the newly created Expression (i.e. ufl.Function). This was
  previously done by using the ufl.element passed by the FunctionSpace.
 
 What we need is the UFL FiniteElement. This can be extracted from any
 of the following:
 
   1. The shape and the expression (if we assume piecewise linears)
   2. A UFL FiniteElement
   3. A FunctionSpace

I think the 2. and 3. is enough. The first might just confuse the user. 
Passing one an element or functionspace as a kwarg might ease any confusion 
about not being a finite element function.

I have started on the Python side but nothing is near to finish. I will keep 
on working on this, but not until after the weekend. Sorry for that, but real 
life interfere. 

In the meantime I see that the special functions (or should we call them 
special expressions now?) also need some care.

Johan

 Perhaps we should allow all three? The basic usage would be
 
   f = Expression(sin(x[0]), triangle)
 
 It might also be possible to leave the shape as undefined and then
 automatically set the shape during assembly.
 
  On a side note:
  Should we consider changing the name of ufl.Function to

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Wed, Sep 30, 2009 at 03:55:22PM +0200, Johan Hake wrote:
 On Wednesday 30 September 2009 11:22:14 Anders Logg wrote:
  On Wed, Sep 30, 2009 at 09:31:01AM +0200, Johan Hake wrote:
   On Wednesday 30 September 2009 09:12:46 Garth N. Wells wrote:
Johan Hake wrote:
 On Tuesday 29 September 2009 22:39:02 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
 On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
 I'm looking forward to seeing the new code. Is all the old
 functionality still in place?

 Yes and no. Everything except the generated CoefficientSet stuff
 should still work in the C++ interface, but the Python interface
 won't work until the corresponding changes have been made on the
 Python side.

 Here's some more information about the changes:

 1. Subclassing Function and overloading eval() has been replaced
 by the Expression subclass which works in the same way with
 eval().

 2. All the old functionality/logic of the Function class is still
 in place but it can now be cleaned up and simplified.

 3. A Function will now *always* have a FunctionSpace and *always*
 have a vector.

 Good!

 4. An Expression *never* has a FunctionSpace and *never* has a
 vector.

 Also good! Should we consider (re-)adding a value_rank and
 dimension method to the expression class?

 Yes, perhaps. But it's very convenient not having to specify it. We
 could make it optional.

 Ok. No big dealt for me. In Python we can solve this for Expressions
 anyway.

 Also what would the preferred solution be for a Python expression.
 It should not have a FunctionSpace but we need a FunctionSpace to
 initialize the ufl.Function. Or rather the ufl.FiniteElement that
 comes with the FunctionSpace.

 I see two alternatives:
 1) Instantiate an Expression with a FunctionSpace, then let the
 FunctionSpace reside in the Python layer. The ufl.FiniteElement is
 used to instantiate the ufl.Function.

 2) Instantiate an Expression with a ufl.FiniteElement. The problem
 with this is that we have not exposed the ufl.FiniteElement in the
 PyDOLFIN interface previously. But the confusion with an expression
 having a FunctionSpace is partly avoided.

 In both cases I could add checks for rank and dimensions in the
 Python layer if we decides to not require it for the C++ interface.

 I think we discussed the possibility of detecting the value
 dimension from the expression

 Yes, but a user can initialize an Expression with the wrong
 FunctionSpace/FiniteElement compared to what the expression looks
 like.

 and automatically using piecewise linears if not
 otherwise specified.

 The function space could be an optional argument:

   f = Expression(sin(x[0]), V=V)

 We cannot automatically figure out the topological dimension, can we?
   
We can from the function space.
  
   Yes, but when the user does not pass the space we cannot.
  
 Should we require that an Expression is instantiated using just a
 ufl.FiniteElement? In this way it would be clear that the Expression
 is not defined in a FunctionSpace? It would then look like:

   f = Expression(V.ufl_element(),sin(x[0]))

 or something.
   
Doesn't this defeat the purpose of having 'Expression' (i.e. no
function space)? Could we just pass the cell type?
  
   Not sure the cell type would fit all purposes. When we compile an
   Expression using the extended syntax where the user define the whole C++
   code, we cannot automatically extract the value rank.
  
   We also need to pass the ufl.FiniteElement in some way so the
   ufl.Function can be initialized correctly. This so we can define forms
   using the newly created Expression (i.e. ufl.Function). This was
   previously done by using the ufl.element passed by the FunctionSpace.
 
  What we need is the UFL FiniteElement. This can be extracted from any
  of the following:
 
1. The shape and the expression (if we assume piecewise linears)
2. A UFL FiniteElement
3. A FunctionSpace

 I think the 2. and 3. is enough. The first might just confuse the user.
 Passing one an element or functionspace as a kwarg might ease any confusion
 about not being a finite element function.

Agree.

 I have started on the Python side but nothing is near to finish. I will keep
 on working on this, but not until after the weekend. Sorry for that, but real
 life interfere.

ok.

 In the meantime I see that the special functions (or should we call them
 special expressions now?) also need some care.

Looks like Garth has fixed this.

--
Anders


 Johan

  Perhaps we should allow all three? The basic usage would be
 
f =

Re: [DOLFIN-dev] [HG DOLFIN] merge

I'm looking forward to seeing the new code. Is all the old functionality 
still in place?

Garth

DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.
 
 changeset:   7176:6572fe2cde36
 tag: tip
 parent:  7175:1cbf255997db
 parent:  7173:fd4071fe9460
 user:Anders Logg l...@simula.no
 date:Tue Sep 29 21:45:40 2009 +0200
 files:   demo/mesh/built-in/cpp/README dolfin/fem/SystemAssembler.cpp
 description:
 merge
 
 
 changeset:   7175:1cbf255997db
 user:Anders Logg l...@simula.no
 date:Tue Sep 29 21:42:24 2009 +0200
 files:   dolfin/function/Coefficient.cpp
 description:
 Remove Coefficient.cpp, no longer needed
 
 
 changeset:   7174:48ed697d94eb
 parent:  7170:2d5fadf5b282
 user:Anders Logg l...@simula.no
 date:Tue Sep 29 21:41:14 2009 +0200
 files:   bench/fem/assembly/cpp/forms/Elasticity3D.h 
 bench/fem/assembly/cpp/forms/NSEMomentum3D.h 
 bench/fem/assembly/cpp/forms/Poisson2DP1.h 
 bench/fem/assembly/cpp/forms/Poisson2DP2.h 
 bench/fem/assembly/cpp/forms/Poisson2DP3.h 
 bench/fem/assembly/cpp/forms/StabStokes2D.h 
 bench/fem/assembly/cpp/forms/THStokes2D.h bench/fem/convergence/Poisson2D_1.h 
 bench/fem/convergence/Poisson2D_2.h bench/fem/convergence/Poisson2D_3.h 
 bench/fem/convergence/Poisson2D_4.h bench/fem/convergence/Poisson2D_5.h 
 bench/fem/convergence/Poisson3D_1.h bench/fem/convergence/Poisson3D_2.h 
 bench/fem/convergence/Poisson3D_3.h bench/fem/convergence/Poisson3D_4.h 
 bench/fem/convergence/Poisson3D_5.h bench/fem/speedup/Poisson.h 
 bench/la/sparse-matrix/Poisson.h bench/la/sparse-matrix/VectorPoisson.h 
 demo/fem/assembly/cpp/ReactionDiffusion.h demo/function/eval/cpp/Projection.h 
 demo/function/nonmatching-interpolation/cpp/P1.h 
 demo/function/nonmatching-interpolation/cpp/P3.h 
 demo/pde/advection-diffusion/cpp/Ad
vectionDiffusion.h demo/pde/advection-diffusion/cpp/Velocity.h 
demo/pde/bcs/cpp/Poisson.h demo/pde/cahn-hilliard/cpp/CahnHilliard2D.h 
demo/pde/cahn-hilliard/cpp/CahnHilliard3D.h 
demo/pde/curl-curl/cpp/CurrentDensity.h demo/pde/curl-curl/cpp/EddyCurrents.h 
demo/pde/dg/advection-diffusion/cpp/AdvectionDiffusion.h 
demo/pde/dg/advection-diffusion/cpp/Projection.h 
demo/pde/dg/advection-diffusion/cpp/Velocity.h 
demo/pde/dg/biharmonic/cpp/Biharmonic.h demo/pde/dg/poisson/cpp/Poisson.h 
demo/pde/elasticity/cpp/Elasticity.h demo/pde/elastodynamics/cpp/DG0_eps_xx.h 
demo/pde/elastodynamics/cpp/ElastoDynamics.h demo/pde/equality/cpp/Poisson.h 
demo/pde/functional/cpp/EnergyNorm.h demo/pde/lift-drag/cpp/Drag.h 
demo/pde/lift-drag/cpp/Lift.h demo/pde/lift-drag/cpp/Pressure.h 
demo/pde/mixed-poisson/cpp/MixedPoisson.h 
demo/pde/mixed-poisson/cpp/P1Projection.h 
demo/pde/nonlinear-poisson/cpp/NonlinearPoisson.h 
demo/pde/periodic/cpp/Poisson.h demo/pde/poisson/cpp/Poisson.h 
demo/pde/poisson/cpp/mai
n.cpp demo/pde/poisson1D/cpp/Poisson.h demo/pde/simple/cpp/ReactionDiffusion.h 
demo/pde/stokes/stabilized/cpp/Stokes.h 
demo/pde/stokes/taylor-hood/cpp/Stokes.h 
demo/pde/sym-dirichlet-bc/cpp/Poisson.h demo/pde/waveguide/cpp/Forms.h 
dolfin/ale/Poisson1D.h dolfin/ale/Poisson2D.h dolfin/ale/Poisson3D.h 
dolfin/fem/Assembler.cpp dolfin/fem/Form.cpp dolfin/fem/Form.h 
dolfin/fem/SystemAssembler.cpp dolfin/fem/UFC.cpp dolfin/fem/UFC.h 
dolfin/function/Coefficient.h dolfin/function/Expression.h 
dolfin/function/Function.cpp dolfin/function/Function.h 
dolfin/function/NewCoefficient.h dolfin/function/dolfin_function.h 
dolfin/mf/ffc-forms/ConvectionMatrix2D.h 
dolfin/mf/ffc-forms/ConvectionMatrix3D.h dolfin/mf/ffc-forms/LoadVector2D.h 
dolfin/mf/ffc-forms/LoadVector3D.h dolfin/mf/ffc-forms/MassMatrix2D.h 
dolfin/mf/ffc-forms/MassMatrix3D.h dolfin/mf/ffc-forms/StiffnessMatrix2D.h 
dolfin/mf/ffc-forms/StiffnessMatrix3D.h sandbox/passembly-bench-vec/PoissonP1.h 
sandbox/passembly-bench-vec/PoissonP
2.h sandbox/passembly/Poisson2DP1.h sandbox/passembly/Poisson2DP2.h 
sandbox/passembly/Poisson2DP3.h sandbox/passembly/Poisson3DP1.h 
sandbox/passembly/Poisson3DP2.h sandbox/passembly/Poisson3DP3.h 
sandbox/pdof_map/Poisson.h site-packages/dolfin_utils/wrappers/coefficient.py 
site-packages/dolfin_utils/wrappers/coefficient_set.py 
site-packages/dolfin_utils/wrappers/form.py 
site-packages/dolfin_utils/wrappers/functionspace.py 
site-packages/dolfin_utils/wrappers/wrappers.py 
test/unit/function/cpp/Projection.h
 description:
 BIG changes to Function interface.
 
 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev

___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

Did you forget to add CoefficientAssigner.h?

Garth

DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.
 
 changeset:   7176:6572fe2cde36
 tag: tip
 parent:  7175:1cbf255997db
 parent:  7173:fd4071fe9460
 user:Anders Logg l...@simula.no
 date:Tue Sep 29 21:45:40 2009 +0200
 files:   demo/mesh/built-in/cpp/README dolfin/fem/SystemAssembler.cpp
 description:
 merge
 
 
 changeset:   7175:1cbf255997db
 user:Anders Logg l...@simula.no
 date:Tue Sep 29 21:42:24 2009 +0200
 files:   dolfin/function/Coefficient.cpp
 description:
 Remove Coefficient.cpp, no longer needed
 
 
 changeset:   7174:48ed697d94eb
 parent:  7170:2d5fadf5b282
 user:Anders Logg l...@simula.no
 date:Tue Sep 29 21:41:14 2009 +0200
 files:   bench/fem/assembly/cpp/forms/Elasticity3D.h 
 bench/fem/assembly/cpp/forms/NSEMomentum3D.h 
 bench/fem/assembly/cpp/forms/Poisson2DP1.h 
 bench/fem/assembly/cpp/forms/Poisson2DP2.h 
 bench/fem/assembly/cpp/forms/Poisson2DP3.h 
 bench/fem/assembly/cpp/forms/StabStokes2D.h 
 bench/fem/assembly/cpp/forms/THStokes2D.h bench/fem/convergence/Poisson2D_1.h 
 bench/fem/convergence/Poisson2D_2.h bench/fem/convergence/Poisson2D_3.h 
 bench/fem/convergence/Poisson2D_4.h bench/fem/convergence/Poisson2D_5.h 
 bench/fem/convergence/Poisson3D_1.h bench/fem/convergence/Poisson3D_2.h 
 bench/fem/convergence/Poisson3D_3.h bench/fem/convergence/Poisson3D_4.h 
 bench/fem/convergence/Poisson3D_5.h bench/fem/speedup/Poisson.h 
 bench/la/sparse-matrix/Poisson.h bench/la/sparse-matrix/VectorPoisson.h 
 demo/fem/assembly/cpp/ReactionDiffusion.h demo/function/eval/cpp/Projection.h 
 demo/function/nonmatching-interpolation/cpp/P1.h 
 demo/function/nonmatching-interpolation/cpp/P3.h 
 demo/pde/advection-diffusion/cpp/Ad
vectionDiffusion.h demo/pde/advection-diffusion/cpp/Velocity.h 
demo/pde/bcs/cpp/Poisson.h demo/pde/cahn-hilliard/cpp/CahnHilliard2D.h 
demo/pde/cahn-hilliard/cpp/CahnHilliard3D.h 
demo/pde/curl-curl/cpp/CurrentDensity.h demo/pde/curl-curl/cpp/EddyCurrents.h 
demo/pde/dg/advection-diffusion/cpp/AdvectionDiffusion.h 
demo/pde/dg/advection-diffusion/cpp/Projection.h 
demo/pde/dg/advection-diffusion/cpp/Velocity.h 
demo/pde/dg/biharmonic/cpp/Biharmonic.h demo/pde/dg/poisson/cpp/Poisson.h 
demo/pde/elasticity/cpp/Elasticity.h demo/pde/elastodynamics/cpp/DG0_eps_xx.h 
demo/pde/elastodynamics/cpp/ElastoDynamics.h demo/pde/equality/cpp/Poisson.h 
demo/pde/functional/cpp/EnergyNorm.h demo/pde/lift-drag/cpp/Drag.h 
demo/pde/lift-drag/cpp/Lift.h demo/pde/lift-drag/cpp/Pressure.h 
demo/pde/mixed-poisson/cpp/MixedPoisson.h 
demo/pde/mixed-poisson/cpp/P1Projection.h 
demo/pde/nonlinear-poisson/cpp/NonlinearPoisson.h 
demo/pde/periodic/cpp/Poisson.h demo/pde/poisson/cpp/Poisson.h 
demo/pde/poisson/cpp/mai
n.cpp demo/pde/poisson1D/cpp/Poisson.h demo/pde/simple/cpp/ReactionDiffusion.h 
demo/pde/stokes/stabilized/cpp/Stokes.h 
demo/pde/stokes/taylor-hood/cpp/Stokes.h 
demo/pde/sym-dirichlet-bc/cpp/Poisson.h demo/pde/waveguide/cpp/Forms.h 
dolfin/ale/Poisson1D.h dolfin/ale/Poisson2D.h dolfin/ale/Poisson3D.h 
dolfin/fem/Assembler.cpp dolfin/fem/Form.cpp dolfin/fem/Form.h 
dolfin/fem/SystemAssembler.cpp dolfin/fem/UFC.cpp dolfin/fem/UFC.h 
dolfin/function/Coefficient.h dolfin/function/Expression.h 
dolfin/function/Function.cpp dolfin/function/Function.h 
dolfin/function/NewCoefficient.h dolfin/function/dolfin_function.h 
dolfin/mf/ffc-forms/ConvectionMatrix2D.h 
dolfin/mf/ffc-forms/ConvectionMatrix3D.h dolfin/mf/ffc-forms/LoadVector2D.h 
dolfin/mf/ffc-forms/LoadVector3D.h dolfin/mf/ffc-forms/MassMatrix2D.h 
dolfin/mf/ffc-forms/MassMatrix3D.h dolfin/mf/ffc-forms/StiffnessMatrix2D.h 
dolfin/mf/ffc-forms/StiffnessMatrix3D.h sandbox/passembly-bench-vec/PoissonP1.h 
sandbox/passembly-bench-vec/PoissonP
2.h sandbox/passembly/Poisson2DP1.h sandbox/passembly/Poisson2DP2.h 
sandbox/passembly/Poisson2DP3.h sandbox/passembly/Poisson3DP1.h 
sandbox/passembly/Poisson3DP2.h sandbox/passembly/Poisson3DP3.h 
sandbox/pdof_map/Poisson.h site-packages/dolfin_utils/wrappers/coefficient.py 
site-packages/dolfin_utils/wrappers/coefficient_set.py 
site-packages/dolfin_utils/wrappers/form.py 
site-packages/dolfin_utils/wrappers/functionspace.py 
site-packages/dolfin_utils/wrappers/wrappers.py 
test/unit/function/cpp/Projection.h
 description:
 BIG changes to Function interface.
 
 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
 I'm looking forward to seeing the new code. Is all the old functionality
 still in place?

Yes and no. Everything except the generated CoefficientSet stuff
should still work in the C++ interface, but the Python interface won't
work until the corresponding changes have been made on the Python side.

Here's some more information about the changes:

1. Subclassing Function and overloading eval() has been replaced by
the Expression subclass which works in the same way with eval().

2. All the old functionality/logic of the Function class is still in
place but it can now be cleaned up and simplified.

3. A Function will now *always* have a FunctionSpace and *always* have
a vector.

4. An Expression *never* has a FunctionSpace and *never* has a vector.

5. FunctionSpaces are not attached to coefficients when doing a.f = f.

6. The DOLFIN wrappers have been simplified and now rely on the
new very simple CoefficientAssigner class.

7. The assembler works through the common base class Coefficient, in
particular the restrict() function for restricting to a local element.

8. Some checks have been removed in Assembler since a Coefficient does
not (if it is an Expression) have a FunctionSpace so we can't check
value_rank etc.

Things that need to be done now:

1. Clean up Function.

2. Use the Expression class in demos where appropriate (just need to
change the class name, everything else is the same).

3. Fix Python interface.

I won't be touching it until tomorrow afternoon so feel free to poke
around.

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

Yes, fixed now.

--
Anders

On Tue, Sep 29, 2009 at 09:01:57PM +0100, Garth N. Wells wrote:
 Did you forget to add CoefficientAssigner.h?

 Garth

 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   7176:6572fe2cde36
  tag: tip
  parent:  7175:1cbf255997db
  parent:  7173:fd4071fe9460
  user:Anders Logg l...@simula.no
  date:Tue Sep 29 21:45:40 2009 +0200
  files:   demo/mesh/built-in/cpp/README dolfin/fem/SystemAssembler.cpp
  description:
  merge
 
 
  changeset:   7175:1cbf255997db
  user:Anders Logg l...@simula.no
  date:Tue Sep 29 21:42:24 2009 +0200
  files:   dolfin/function/Coefficient.cpp
  description:
  Remove Coefficient.cpp, no longer needed
 
 
  changeset:   7174:48ed697d94eb
  parent:  7170:2d5fadf5b282
  user:Anders Logg l...@simula.no
  date:Tue Sep 29 21:41:14 2009 +0200
  files:   bench/fem/assembly/cpp/forms/Elasticity3D.h 
  bench/fem/assembly/cpp/forms/NSEMomentum3D.h 
  bench/fem/assembly/cpp/forms/Poisson2DP1.h 
  bench/fem/assembly/cpp/forms/Poisson2DP2.h 
  bench/fem/assembly/cpp/forms/Poisson2DP3.h 
  bench/fem/assembly/cpp/forms/StabStokes2D.h 
  bench/fem/assembly/cpp/forms/THStokes2D.h 
  bench/fem/convergence/Poisson2D_1.h bench/fem/convergence/Poisson2D_2.h 
  bench/fem/convergence/Poisson2D_3.h bench/fem/convergence/Poisson2D_4.h 
  bench/fem/convergence/Poisson2D_5.h bench/fem/convergence/Poisson3D_1.h 
  bench/fem/convergence/Poisson3D_2.h bench/fem/convergence/Poisson3D_3.h 
  bench/fem/convergence/Poisson3D_4.h bench/fem/convergence/Poisson3D_5.h 
  bench/fem/speedup/Poisson.h bench/la/sparse-matrix/Poisson.h 
  bench/la/sparse-matrix/VectorPoisson.h 
  demo/fem/assembly/cpp/ReactionDiffusion.h 
  demo/function/eval/cpp/Projection.h 
  demo/function/nonmatching-interpolation/cpp/P1.h 
  demo/function/nonmatching-interpolation/cpp/P3.h 
  demo/pde/advection-diffusion/cpp/Ad
 vectionDiffusion.h demo/pde/advection-diffusion/cpp/Velocity.h 
 demo/pde/bcs/cpp/Poisson.h demo/pde/cahn-hilliard/cpp/CahnHilliard2D.h 
 demo/pde/cahn-hilliard/cpp/CahnHilliard3D.h 
 demo/pde/curl-curl/cpp/CurrentDensity.h demo/pde/curl-curl/cpp/EddyCurrents.h 
 demo/pde/dg/advection-diffusion/cpp/AdvectionDiffusion.h 
 demo/pde/dg/advection-diffusion/cpp/Projection.h 
 demo/pde/dg/advection-diffusion/cpp/Velocity.h 
 demo/pde/dg/biharmonic/cpp/Biharmonic.h demo/pde/dg/poisson/cpp/Poisson.h 
 demo/pde/elasticity/cpp/Elasticity.h demo/pde/elastodynamics/cpp/DG0_eps_xx.h 
 demo/pde/elastodynamics/cpp/ElastoDynamics.h demo/pde/equality/cpp/Poisson.h 
 demo/pde/functional/cpp/EnergyNorm.h demo/pde/lift-drag/cpp/Drag.h 
 demo/pde/lift-drag/cpp/Lift.h demo/pde/lift-drag/cpp/Pressure.h 
 demo/pde/mixed-poisson/cpp/MixedPoisson.h 
 demo/pde/mixed-poisson/cpp/P1Projection.h 
 demo/pde/nonlinear-poisson/cpp/NonlinearPoisson.h 
 demo/pde/periodic/cpp/Poisson.h demo/pde/poisson/cpp/Poisson.h 
 demo/pde/poisson/cpp/mai
 n.cpp demo/pde/poisson1D/cpp/Poisson.h 
 demo/pde/simple/cpp/ReactionDiffusion.h 
 demo/pde/stokes/stabilized/cpp/Stokes.h 
 demo/pde/stokes/taylor-hood/cpp/Stokes.h 
 demo/pde/sym-dirichlet-bc/cpp/Poisson.h demo/pde/waveguide/cpp/Forms.h 
 dolfin/ale/Poisson1D.h dolfin/ale/Poisson2D.h dolfin/ale/Poisson3D.h 
 dolfin/fem/Assembler.cpp dolfin/fem/Form.cpp dolfin/fem/Form.h 
 dolfin/fem/SystemAssembler.cpp dolfin/fem/UFC.cpp dolfin/fem/UFC.h 
 dolfin/function/Coefficient.h dolfin/function/Expression.h 
 dolfin/function/Function.cpp dolfin/function/Function.h 
 dolfin/function/NewCoefficient.h dolfin/function/dolfin_function.h 
 dolfin/mf/ffc-forms/ConvectionMatrix2D.h 
 dolfin/mf/ffc-forms/ConvectionMatrix3D.h dolfin/mf/ffc-forms/LoadVector2D.h 
 dolfin/mf/ffc-forms/LoadVector3D.h dolfin/mf/ffc-forms/MassMatrix2D.h 
 dolfin/mf/ffc-forms/MassMatrix3D.h dolfin/mf/ffc-forms/StiffnessMatrix2D.h 
 dolfin/mf/ffc-forms/StiffnessMatrix3D.h 
 sandbox/passembly-bench-vec/PoissonP1.h sandbox/passembly-bench-vec/PoissonP
 2.h sandbox/passembly/Poisson2DP1.h sandbox/passembly/Poisson2DP2.h 
 sandbox/passembly/Poisson2DP3.h sandbox/passembly/Poisson3DP1.h 
 sandbox/passembly/Poisson3DP2.h sandbox/passembly/Poisson3DP3.h 
 sandbox/pdof_map/Poisson.h site-packages/dolfin_utils/wrappers/coefficient.py 
 site-packages/dolfin_utils/wrappers/coefficient_set.py 
 site-packages/dolfin_utils/wrappers/form.py 
 site-packages/dolfin_utils/wrappers/functionspace.py 
 site-packages/dolfin_utils/wrappers/wrappers.py 
 test/unit/function/cpp/Projection.h
  description:
  BIG changes to Function interface.
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 ___

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 29, 2009 at 10:10:54PM +0200, Anders Logg wrote:
 On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
  I'm looking forward to seeing the new code. Is all the old functionality
  still in place?

 Yes and no. Everything except the generated CoefficientSet stuff
 should still work in the C++ interface, but the Python interface won't
 work until the corresponding changes have been made on the Python side.

 Here's some more information about the changes:

 1. Subclassing Function and overloading eval() has been replaced by
 the Expression subclass which works in the same way with eval().

 2. All the old functionality/logic of the Function class is still in
 place but it can now be cleaned up and simplified.

 3. A Function will now *always* have a FunctionSpace and *always* have
 a vector.

 4. An Expression *never* has a FunctionSpace and *never* has a vector.

 5. FunctionSpaces are not attached to coefficients when doing a.f = f.

 6. The DOLFIN wrappers have been simplified and now rely on the
 new very simple CoefficientAssigner class.

 7. The assembler works through the common base class Coefficient, in
 particular the restrict() function for restricting to a local element.

 8. Some checks have been removed in Assembler since a Coefficient does
 not (if it is an Expression) have a FunctionSpace so we can't check
 value_rank etc.

 Things that need to be done now:

 1. Clean up Function.

 2. Use the Expression class in demos where appropriate (just need to
 change the class name, everything else is the same).

 3. Fix Python interface.

 I won't be touching it until tomorrow afternoon so feel free to poke
 around.

UFCFunction can also be removed when the Function class has been
cleaned up.

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-29 Thread Johan Hake

On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
  I'm looking forward to seeing the new code. Is all the old functionality
  still in place?
 
 Yes and no. Everything except the generated CoefficientSet stuff
 should still work in the C++ interface, but the Python interface won't
 work until the corresponding changes have been made on the Python side.
 
 Here's some more information about the changes:
 
 1. Subclassing Function and overloading eval() has been replaced by
 the Expression subclass which works in the same way with eval().
 
 2. All the old functionality/logic of the Function class is still in
 place but it can now be cleaned up and simplified.
 
 3. A Function will now *always* have a FunctionSpace and *always* have
 a vector.

Good!

 4. An Expression *never* has a FunctionSpace and *never* has a vector.

Also good! Should we consider (re-)adding a value_rank and dimension method to 
the expression class? 

Also what would the preferred solution be for a Python expression. It should 
not have a FunctionSpace but we need a FunctionSpace to initialize the 
ufl.Function. Or rather the ufl.FiniteElement that comes with the 
FunctionSpace.

I see two alternatives:
1) Instantiate an Expression with a FunctionSpace, then let the FunctionSpace 
reside in the Python layer. The ufl.FiniteElement is used to instantiate the 
ufl.Function. 

2) Instantiate an Expression with a ufl.FiniteElement. The problem with this 
is that we have not exposed the ufl.FiniteElement in the PyDOLFIN interface 
previously. But the confusion with an expression having a FunctionSpace is 
partly avoided.

In both cases I could add checks for rank and dimensions in the Python layer 
if we decides to not require it for the C++ interface.

 5. FunctionSpaces are not attached to coefficients when doing a.f = f.
 
 6. The DOLFIN wrappers have been simplified and now rely on the
 new very simple CoefficientAssigner class.
 
 7. The assembler works through the common base class Coefficient, in
 particular the restrict() function for restricting to a local element.

Nice!

 8. Some checks have been removed in Assembler since a Coefficient does
 not (if it is an Expression) have a FunctionSpace so we can't check
 value_rank etc.
 
 Things that need to be done now:
 
 1. Clean up Function.
 
 2. Use the Expression class in demos where appropriate (just need to
 change the class name, everything else is the same).
 
 3. Fix Python interface.

I hope I can fix this tomorrow. Should actually make things easier (but 
cleanup also takes time...). We should for example be able to skip the 
DiscreteFunction class now.

Johan
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
 On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
  On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
   I'm looking forward to seeing the new code. Is all the old functionality
   still in place?
 
  Yes and no. Everything except the generated CoefficientSet stuff
  should still work in the C++ interface, but the Python interface won't
  work until the corresponding changes have been made on the Python side.
 
  Here's some more information about the changes:
 
  1. Subclassing Function and overloading eval() has been replaced by
  the Expression subclass which works in the same way with eval().
 
  2. All the old functionality/logic of the Function class is still in
  place but it can now be cleaned up and simplified.
 
  3. A Function will now *always* have a FunctionSpace and *always* have
  a vector.

 Good!

  4. An Expression *never* has a FunctionSpace and *never* has a vector.

 Also good! Should we consider (re-)adding a value_rank and dimension method to
 the expression class?

Yes, perhaps. But it's very convenient not having to specify it. We
could make it optional.

 Also what would the preferred solution be for a Python expression. It should
 not have a FunctionSpace but we need a FunctionSpace to initialize the
 ufl.Function. Or rather the ufl.FiniteElement that comes with the
 FunctionSpace.

 I see two alternatives:
 1) Instantiate an Expression with a FunctionSpace, then let the FunctionSpace
 reside in the Python layer. The ufl.FiniteElement is used to instantiate the
 ufl.Function.

 2) Instantiate an Expression with a ufl.FiniteElement. The problem with this
 is that we have not exposed the ufl.FiniteElement in the PyDOLFIN interface
 previously. But the confusion with an expression having a FunctionSpace is
 partly avoided.

 In both cases I could add checks for rank and dimensions in the Python layer
 if we decides to not require it for the C++ interface.

I think we discussed the possibility of detecting the value dimension
from the expression and automatically using piecewise linears if not
otherwise specified. The function space could be an optional argument:

  f = Expression(sin(x[0]), V=V)

Then it would be clear that f is not a function in V, but V is only
some additional information about how f should be used in forms.

  5. FunctionSpaces are not attached to coefficients when doing a.f = f.
 
  6. The DOLFIN wrappers have been simplified and now rely on the
  new very simple CoefficientAssigner class.
 
  7. The assembler works through the common base class Coefficient, in
  particular the restrict() function for restricting to a local element.

 Nice!

This also removes one of the too many interpolate() functions which is
good.

  8. Some checks have been removed in Assembler since a Coefficient does
  not (if it is an Expression) have a FunctionSpace so we can't check
  value_rank etc.
 
  Things that need to be done now:
 
  1. Clean up Function.
 
  2. Use the Expression class in demos where appropriate (just need to
  change the class name, everything else is the same).
 
  3. Fix Python interface.

 I hope I can fix this tomorrow. Should actually make things easier (but
 cleanup also takes time...). We should for example be able to skip the
 DiscreteFunction class now.

Sounds very good!

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Anders Logg wrote:
 On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
 I'm looking forward to seeing the new code. Is all the old functionality
 still in place?
 
 Yes and no. Everything except the generated CoefficientSet stuff
 should still work in the C++ interface, but the Python interface won't
 work until the corresponding changes have been made on the Python side.
 
 Here's some more information about the changes:
 
 1. Subclassing Function and overloading eval() has been replaced by
 the Expression subclass which works in the same way with eval().
 
 2. All the old functionality/logic of the Function class is still in
 place but it can now be cleaned up and simplified.
 
 3. A Function will now *always* have a FunctionSpace and *always* have
 a vector.
 
 4. An Expression *never* has a FunctionSpace and *never* has a vector.
 
 5. FunctionSpaces are not attached to coefficients when doing a.f = f.
 
 6. The DOLFIN wrappers have been simplified and now rely on the
 new very simple CoefficientAssigner class.
 
 7. The assembler works through the common base class Coefficient, in
 particular the restrict() function for restricting to a local element.
 
 8. Some checks have been removed in Assembler since a Coefficient does
 not (if it is an Expression) have a FunctionSpace so we can't check
 value_rank etc.
 
 Things that need to be done now:
 
 1. Clean up Function.
 
 2. Use the Expression class in demos where appropriate (just need to
 change the class name, everything else is the same).
 

Haven't you already done this everywhere?

Garth

 3. Fix Python interface.
 
 I won't be touching it until tomorrow afternoon so feel free to poke
 around.
 
 --
 Anders
 
 
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev

-- 
Dr Garth N Wells
Department of Engineering
University of Cambridge
Trumpington Street
Cambridge CB2 1PZ
United Kingdom

tel.   +44 1223 3 32743
e-mail gn...@cam.ac.uk
http://www.eng.cam.ac.uk/~gnw20/
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Anders Logg wrote:
 On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
 I'm looking forward to seeing the new code. Is all the old functionality
 still in place?
 
 Yes and no. Everything except the generated CoefficientSet stuff
 should still work in the C++ interface, but the Python interface won't
 work until the corresponding changes have been made on the Python side.
 

Will CoefficientSet come back? I was using it, but I forgot the 
important reason why. If I do

Form* a = new Poisson::BilinearForm(V, V);

I can't do

   a-g g;

but I could do

Form* a = new Poisson::BilinearForm(V, V, coefficient_set);

I can of course use dynamic cast and then attach functions.

Garth

 Here's some more information about the changes:
 
 1. Subclassing Function and overloading eval() has been replaced by
 the Expression subclass which works in the same way with eval().
 
 2. All the old functionality/logic of the Function class is still in
 place but it can now be cleaned up and simplified.
 
 3. A Function will now *always* have a FunctionSpace and *always* have
 a vector.
 
 4. An Expression *never* has a FunctionSpace and *never* has a vector.
 
 5. FunctionSpaces are not attached to coefficients when doing a.f = f.
 
 6. The DOLFIN wrappers have been simplified and now rely on the
 new very simple CoefficientAssigner class.
 
 7. The assembler works through the common base class Coefficient, in
 particular the restrict() function for restricting to a local element.
 
 8. Some checks have been removed in Assembler since a Coefficient does
 not (if it is an Expression) have a FunctionSpace so we can't check
 value_rank etc.
 
 Things that need to be done now:
 
 1. Clean up Function.
 
 2. Use the Expression class in demos where appropriate (just need to
 change the class name, everything else is the same).
 
 3. Fix Python interface.
 
 I won't be touching it until tomorrow afternoon so feel free to poke
 around.
 
 --
 Anders
 
 
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Anders Logg wrote:
 On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
 I'm looking forward to seeing the new code. Is all the old functionality
 still in place?
 
 Yes and no. Everything except the generated CoefficientSet stuff
 should still work in the C++ interface, but the Python interface won't
 work until the corresponding changes have been made on the Python side.
 
 Here's some more information about the changes:
 
 1. Subclassing Function and overloading eval() has been replaced by
 the Expression subclass which works in the same way with eval().
 
 2. All the old functionality/logic of the Function class is still in
 place but it can now be cleaned up and simplified.
 
 3. A Function will now *always* have a FunctionSpace and *always* have
 a vector.
 
 4. An Expression *never* has a FunctionSpace and *never* has a vector.
 
 5. FunctionSpaces are not attached to coefficients when doing a.f = f.
 
 6. The DOLFIN wrappers have been simplified and now rely on the
 new very simple CoefficientAssigner class.
 
 7. The assembler works through the common base class Coefficient, in
 particular the restrict() function for restricting to a local element.
 
 8. Some checks have been removed in Assembler since a Coefficient does
 not (if it is an Expression) have a FunctionSpace so we can't check
 value_rank etc.
 
 Things that need to be done now:
 
 1. Clean up Function.
 

Should we have the functions

   void Function::interpolate(const Expression expression)
   const Function Function::operator= (const Expression expression)

to interpolate an expression in a FE space?

Garth


 2. Use the Expression class in demos where appropriate (just need to
 change the class name, everything else is the same).
 
 3. Fix Python interface.
 
 I won't be touching it until tomorrow afternoon so feel free to poke
 around.
 
 --
 Anders
 
 
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 29, 2009 at 10:00:59PM +0100, Garth N. Wells wrote:

  2. Use the Expression class in demos where appropriate (just need to
  change the class name, everything else is the same).
 

 Haven't you already done this everywhere?

No, just in the Poisson demo. I'll fix the others later.

--
Anders


 Garth

  3. Fix Python interface.
 
  I won't be touching it until tomorrow afternoon so feel free to poke
  around.
 



signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 29, 2009 at 10:37:51PM +0100, Garth N. Wells wrote:


 Anders Logg wrote:
  On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
  I'm looking forward to seeing the new code. Is all the old functionality
  still in place?
 
  Yes and no. Everything except the generated CoefficientSet stuff
  should still work in the C++ interface, but the Python interface won't
  work until the corresponding changes have been made on the Python side.
 

 Will CoefficientSet come back? I was using it, but I forgot the
 important reason why. If I do

 Form* a = new Poisson::BilinearForm(V, V);

 I can't do

a-g g;

 but I could do

 Form* a = new Poisson::BilinearForm(V, V, coefficient_set);

 I can of course use dynamic cast and then attach functions.

We could easily add functionality for doing

  a-set_coefficient(g, g);

Would that be enough? This would be a simple function implemented in
the C++ Form class. It's better if we can avoid generating code if
something can be implemented directly in the C++ class.

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 29, 2009 at 11:05:55PM +0100, Garth N. Wells wrote:


 Anders Logg wrote:
  On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
  I'm looking forward to seeing the new code. Is all the old functionality
  still in place?
 
  Yes and no. Everything except the generated CoefficientSet stuff
  should still work in the C++ interface, but the Python interface won't
  work until the corresponding changes have been made on the Python side.
 
  Here's some more information about the changes:
 
  1. Subclassing Function and overloading eval() has been replaced by
  the Expression subclass which works in the same way with eval().
 
  2. All the old functionality/logic of the Function class is still in
  place but it can now be cleaned up and simplified.
 
  3. A Function will now *always* have a FunctionSpace and *always* have
  a vector.
 
  4. An Expression *never* has a FunctionSpace and *never* has a vector.
 
  5. FunctionSpaces are not attached to coefficients when doing a.f = f.
 
  6. The DOLFIN wrappers have been simplified and now rely on the
  new very simple CoefficientAssigner class.
 
  7. The assembler works through the common base class Coefficient, in
  particular the restrict() function for restricting to a local element.
 
  8. Some checks have been removed in Assembler since a Coefficient does
  not (if it is an Expression) have a FunctionSpace so we can't check
  value_rank etc.
 
  Things that need to be done now:
 
  1. Clean up Function.
 

 Should we have the functions

void Function::interpolate(const Expression expression)
const Function Function::operator= (const Expression expression)

 to interpolate an expression in a FE space?

Yes, and these should replace the old u.interpolate() function.

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-29 Thread Johan Hake

On Tuesday 29 September 2009 22:39:02 Anders Logg wrote:
 On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
  On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
   On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
I'm looking forward to seeing the new code. Is all the old
functionality still in place?
  
   Yes and no. Everything except the generated CoefficientSet stuff
   should still work in the C++ interface, but the Python interface won't
   work until the corresponding changes have been made on the Python side.
  
   Here's some more information about the changes:
  
   1. Subclassing Function and overloading eval() has been replaced by
   the Expression subclass which works in the same way with eval().
  
   2. All the old functionality/logic of the Function class is still in
   place but it can now be cleaned up and simplified.
  
   3. A Function will now *always* have a FunctionSpace and *always* have
   a vector.
 
  Good!
 
   4. An Expression *never* has a FunctionSpace and *never* has a vector.
 
  Also good! Should we consider (re-)adding a value_rank and dimension
  method to the expression class?
 
 Yes, perhaps. But it's very convenient not having to specify it. We
 could make it optional.

Ok. No big dealt for me. In Python we can solve this for Expressions anyway.

  Also what would the preferred solution be for a Python expression. It
  should not have a FunctionSpace but we need a FunctionSpace to initialize
  the ufl.Function. Or rather the ufl.FiniteElement that comes with the
  FunctionSpace.
 
  I see two alternatives:
  1) Instantiate an Expression with a FunctionSpace, then let the
  FunctionSpace reside in the Python layer. The ufl.FiniteElement is used
  to instantiate the ufl.Function.
 
  2) Instantiate an Expression with a ufl.FiniteElement. The problem with
  this is that we have not exposed the ufl.FiniteElement in the PyDOLFIN
  interface previously. But the confusion with an expression having a
  FunctionSpace is partly avoided.
 
  In both cases I could add checks for rank and dimensions in the Python
  layer if we decides to not require it for the C++ interface.
 
 I think we discussed the possibility of detecting the value dimension
 from the expression 

Yes, but a user can initialize an Expression with the wrong 
FunctionSpace/FiniteElement compared to what the expression looks like.

 and automatically using piecewise linears if not
 otherwise specified. 

 The function space could be an optional argument:
 
   f = Expression(sin(x[0]), V=V)

We cannot automatically figure out the topological dimension, can we?

Should we require that an Expression is instantiated using just a 
ufl.FiniteElement? In this way it would be clear that the Expression is not 
defined in a FunctionSpace? It would then look like:

  f = Expression(V.ufl_element(),sin(x[0]))

or something.

 Then it would be clear that f is not a function in V, but V is only
 some additional information about how f should be used in forms.
 
   5. FunctionSpaces are not attached to coefficients when doing a.f = f.
  
   6. The DOLFIN wrappers have been simplified and now rely on the
   new very simple CoefficientAssigner class.
  
   7. The assembler works through the common base class Coefficient, in
   particular the restrict() function for restricting to a local element.
 
  Nice!
 
 This also removes one of the too many interpolate() functions which is
 good.

Ok.

Johan
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-27 Thread Johan Hake

On Saturday 26 September 2009 23:19:23 Anders Logg wrote:
 On Sat, Sep 26, 2009 at 04:16:49PM +0200, Johan Hake wrote:
  On Saturday 26 September 2009 00:07:46 Anders Logg wrote:
   On Fri, Sep 25, 2009 at 11:56:03PM +0200, DOLFIN wrote:
One or more new changesets pushed to the primary dolfin repository.
A short summary of the last three changesets is included below.
   
changeset:   7147:2f99c8fb3a96
tag: tip
parent:  7146:1d18d2b95462
parent:  7145:3f905e727c11
user:Anders Logg l...@simula.no
date:Fri Sep 25 23:56:04 2009 +0200
description:
merge
   
   
changeset:   7146:1d18d2b95462
parent:  7143:98d357740635
user:Anders Logg l...@simula.no
date:Fri Sep 25 23:55:55 2009 +0200
files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
dolfin/function/FunctionSpace.cpp dolfin/function/FunctionSpace.h
description:
Add update() function to FunctionSpace and DofMap for use in adaptive
mesh refinement.
  
   I've added a first iteration of a functionality we need to do
   adaptivity. When a mesh is refined, we can't reassemble the forms
   since the FunctionSpace does not know the mesh has changed.
  
   It is now possible to update the FunctionSpace (actually the DofMap)
   by calling FunctionSpace::update.
  
   Example:
from dolfin import *
mesh = UnitSquare(3, 3)
V = FunctionSpace(mesh, CG, 3)
print V.dim()
  
   100
  
mesh.refine()
  
   No cells marked for refinement, assuming uniform mesh refinement.
  
print V.dim()
  
   100
  
V.update()
print V.dim()
  
   361
  
   I'm not sure what the right way to handle this is. Perhaps we should
   have FunctionSpace::refine which calls refine on the mesh and then
   calls update.
 
  This will then only work for one FunctionSpace. Other FunctionSpaces
  defined on the same Mesh would not be updated.
 
  Would it be possible to store all FunctionSpaces associated with a Mesh
  in a
 
vectorFunctionSpace*
 
  in the Mesh? Then let Mesh::refine iterate over the FunctionSpaces and
  call the FunctionSpace::update.
 
  This could be handle by adding something like:
 
mesh-register(*this);
 
  in the constructor of FunctionSpace and
 
mesh-deregister(*this);
 
  in the destructor of FunctionSpace.
 
 That could be an option. There might be some issues with constness etc
 and we've made mistakes before when trying to be clever, but we could
 try... :-)

What is the policy of constness for the Mesh class. I see that there exists a 
const and a non-const constructor in for example the FunctionSpace and DofMap. 
It is not explicit for me when I construct a FunctionSpace using a const Mesh 
and when I am not.

 We would then need to have
 
   mesh::refine
 -- FunctionSpace::update
   -- DofMap::update
   -- Function::interpolate etc for all functions
 
 So a FunctionSpace would also need to have some functionality for
 registering Functions.

Yes.

We also have the problem of updating MeshFunctions. I understand that there is 
a mechanism for updating MeshFunctions that resides in the MeshData? 

I guess it would just create a lot of spaghetti code to add some automatic 
update for any arbitrary MeshFunction over a particular Mesh. 

   Then there's also the question about what to do with all the Functions
   on the space that we update/refine. They no longer make any sense on
   the new mesh. An option would be for a FunctionSpace to store a list
   of all Functions in the space and automatically project/interpolate
   them to the refined space when we call FunctionSpace::refine.
 
  This would be nice. But is it possible? Do we not need both meshes to
  interpolate between them?
 
 Yes, we would so the above would need to be more complicated. We could
 have the mesh store a copy of itself before refining. Or we could
 store the whole hierarchy of meshes when refining. We have had this
 before. If I remember correctly, a Mesh used to store a pointer to a
 MeshHierarchy so that one could do mesh.parent(), mesh.child() etc.
 We could also have MeshFunctions in the data section of a Mesh that
 stored parents of vertices etc to speed up interpolation between
 meshes.

Ok. 

Johan
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-26 Thread Anders Logg

On Sat, Sep 26, 2009 at 04:16:49PM +0200, Johan Hake wrote:
 On Saturday 26 September 2009 00:07:46 Anders Logg wrote:
  On Fri, Sep 25, 2009 at 11:56:03PM +0200, DOLFIN wrote:
   One or more new changesets pushed to the primary dolfin repository.
   A short summary of the last three changesets is included below.
  
   changeset:   7147:2f99c8fb3a96
   tag: tip
   parent:  7146:1d18d2b95462
   parent:  7145:3f905e727c11
   user:Anders Logg l...@simula.no
   date:Fri Sep 25 23:56:04 2009 +0200
   description:
   merge
  
  
   changeset:   7146:1d18d2b95462
   parent:  7143:98d357740635
   user:Anders Logg l...@simula.no
   date:Fri Sep 25 23:55:55 2009 +0200
   files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
   dolfin/function/FunctionSpace.cpp dolfin/function/FunctionSpace.h
   description:
   Add update() function to FunctionSpace and DofMap for use in adaptive
   mesh refinement.
 
  I've added a first iteration of a functionality we need to do
  adaptivity. When a mesh is refined, we can't reassemble the forms
  since the FunctionSpace does not know the mesh has changed.
 
  It is now possible to update the FunctionSpace (actually the DofMap)
  by calling FunctionSpace::update.
 
  Example:
   from dolfin import *
   mesh = UnitSquare(3, 3)
   V = FunctionSpace(mesh, CG, 3)
   print V.dim()
 
  100
 
   mesh.refine()
 
  No cells marked for refinement, assuming uniform mesh refinement.
 
   print V.dim()
 
  100
 
   V.update()
   print V.dim()
 
  361
 
  I'm not sure what the right way to handle this is. Perhaps we should
  have FunctionSpace::refine which calls refine on the mesh and then
  calls update.

 This will then only work for one FunctionSpace. Other FunctionSpaces defined
 on the same Mesh would not be updated.

 Would it be possible to store all FunctionSpaces associated with a Mesh in a

   vectorFunctionSpace*

 in the Mesh? Then let Mesh::refine iterate over the FunctionSpaces and call
 the FunctionSpace::update.

 This could be handle by adding something like:

   mesh-register(*this);

 in the constructor of FunctionSpace and

   mesh-deregister(*this);

 in the destructor of FunctionSpace.

That could be an option. There might be some issues with constness etc
and we've made mistakes before when trying to be clever, but we could
try... :-)

We would then need to have

  mesh::refine
-- FunctionSpace::update
  -- DofMap::update
  -- Function::interpolate etc for all functions

So a FunctionSpace would also need to have some functionality for
registering Functions.

  Then there's also the question about what to do with all the Functions
  on the space that we update/refine. They no longer make any sense on
  the new mesh. An option would be for a FunctionSpace to store a list
  of all Functions in the space and automatically project/interpolate
  them to the refined space when we call FunctionSpace::refine.

 This would be nice. But is it possible? Do we not need both meshes to
 interpolate between them?

Yes, we would so the above would need to be more complicated. We could
have the mesh store a copy of itself before refining. Or we could
store the whole hierarchy of meshes when refining. We have had this
before. If I remember correctly, a Mesh used to store a pointer to a
MeshHierarchy so that one could do mesh.parent(), mesh.child() etc.
We could also have MeshFunctions in the data section of a Mesh that
stored parents of vertices etc to speed up interpolation between
meshes.

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-25 Thread Anders Logg

On Fri, Sep 25, 2009 at 11:56:03PM +0200, DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   7147:2f99c8fb3a96
 tag: tip
 parent:  7146:1d18d2b95462
 parent:  7145:3f905e727c11
 user:Anders Logg l...@simula.no
 date:Fri Sep 25 23:56:04 2009 +0200
 description:
 merge


 changeset:   7146:1d18d2b95462
 parent:  7143:98d357740635
 user:Anders Logg l...@simula.no
 date:Fri Sep 25 23:55:55 2009 +0200
 files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h 
 dolfin/function/FunctionSpace.cpp dolfin/function/FunctionSpace.h
 description:
 Add update() function to FunctionSpace and DofMap for use in adaptive mesh 
 refinement.

I've added a first iteration of a functionality we need to do
adaptivity. When a mesh is refined, we can't reassemble the forms
since the FunctionSpace does not know the mesh has changed.

It is now possible to update the FunctionSpace (actually the DofMap)
by calling FunctionSpace::update.

Example:

 from dolfin import *
 mesh = UnitSquare(3, 3)
 V = FunctionSpace(mesh, CG, 3)
 print V.dim()
100
 mesh.refine()
No cells marked for refinement, assuming uniform mesh refinement.
 print V.dim()
100
 V.update()
 print V.dim()
361

I'm not sure what the right way to handle this is. Perhaps we should
have FunctionSpace::refine which calls refine on the mesh and then
calls update.

Then there's also the question about what to do with all the Functions
on the space that we update/refine. They no longer make any sense on
the new mesh. An option would be for a FunctionSpace to store a list
of all Functions in the space and automatically project/interpolate
them to the refined space when we call FunctionSpace::refine.

Any thoughts?

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-21 Thread Johannes Ring

On Mon, Sep 21, 2009 at 9:04 AM, DOLFIN dol...@fenics.org wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   7097:a31591593d64
 tag:         tip
 parent:      7096:fb5b9fee5891
 parent:      7094:b2840ed51061
 user:        Ola Skavhaug skavh...@simula.no
 date:        Mon Sep 21 09:03:58 2009 +0200
 description:
 merge


 changeset:   7096:fb5b9fee5891
 user:        Ola Skavhaug skavh...@simula.no
 date:        Mon Sep 21 09:03:48 2009 +0200
 files:       dolfin/io/XMLVectorMapping.cpp dolfin/io/XMLVectorMapping.h
 description:
 Initial work on the storage of vector mappings, needed to persitently store 
 meshfunctions of arbitrary topological dimension to file.


 changeset:   7095:22a058393a75
 parent:      7093:609865e1a22b
 user:        Ola Skavhaug skavh...@simula.no
 date:        Mon Sep 21 09:02:34 2009 +0200
 files:       site-packages/dolfin/plot.py
 description:
 Add more verbose information about what goes wrong when failing to import 
 Viper

This syntax is not supported by Python 2.5. See
http://fenics.org:8080/builders/dolfin-linux64-exp/builds/778/steps/dolfin%20check/logs/demo.log
for details.

Johannes
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-21 Thread Johan Hake

On Monday 21 September 2009 11:40:58 Johannes Ring wrote:
 On Mon, Sep 21, 2009 at 9:04 AM, DOLFIN dol...@fenics.org wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   7097:a31591593d64
  tag: tip
  parent:  7096:fb5b9fee5891
  parent:  7094:b2840ed51061
  user:Ola Skavhaug skavh...@simula.no
  date:Mon Sep 21 09:03:58 2009 +0200
  description:
  merge
 
 
  changeset:   7096:fb5b9fee5891
  user:Ola Skavhaug skavh...@simula.no
  date:Mon Sep 21 09:03:48 2009 +0200
  files:   dolfin/io/XMLVectorMapping.cpp dolfin/io/XMLVectorMapping.h
  description:
  Initial work on the storage of vector mappings, needed to persitently
  store meshfunctions of arbitrary topological dimension to file.
 
 
  changeset:   7095:22a058393a75
  parent:  7093:609865e1a22b
  user:Ola Skavhaug skavh...@simula.no
  date:Mon Sep 21 09:02:34 2009 +0200
  files:   site-packages/dolfin/plot.py
  description:
  Add more verbose information about what goes wrong when failing to import
  Viper
 
 This syntax is not supported by Python 2.5. See
 http://fenics.org:8080/builders/dolfin-linux64-exp/builds/778/steps/dolfin%
 20check/logs/demo.log for details.

Should be fixed now

Johan

 Johannes
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-21 Thread Ola Skavhaug

I'm shocked ;)

Ola

On Mon, Sep 21, 2009 at 11:40 AM, Johannes Ring joha...@simula.no wrote:
 On Mon, Sep 21, 2009 at 9:04 AM, DOLFIN dol...@fenics.org wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   7097:a31591593d64
 tag:         tip
 parent:      7096:fb5b9fee5891
 parent:      7094:b2840ed51061
 user:        Ola Skavhaug skavh...@simula.no
 date:        Mon Sep 21 09:03:58 2009 +0200
 description:
 merge


 changeset:   7096:fb5b9fee5891
 user:        Ola Skavhaug skavh...@simula.no
 date:        Mon Sep 21 09:03:48 2009 +0200
 files:       dolfin/io/XMLVectorMapping.cpp dolfin/io/XMLVectorMapping.h
 description:
 Initial work on the storage of vector mappings, needed to persitently store 
 meshfunctions of arbitrary topological dimension to file.


 changeset:   7095:22a058393a75
 parent:      7093:609865e1a22b
 user:        Ola Skavhaug skavh...@simula.no
 date:        Mon Sep 21 09:02:34 2009 +0200
 files:       site-packages/dolfin/plot.py
 description:
 Add more verbose information about what goes wrong when failing to import 
 Viper

 This syntax is not supported by Python 2.5. See
 http://fenics.org:8080/builders/dolfin-linux64-exp/builds/778/steps/dolfin%20check/logs/demo.log
 for details.

 Johannes
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev




-- 
Ola Skavhaug
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.
 
 changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
 tag: tip
 parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
 parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
 user:Anders Logg l...@simula.no
 date:Tue Sep 08 12:51:01 2009 +0200
 files:   
 description:
 merge
 
 
 changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
 parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
 user:Anders Logg l...@simula.no
 date:Tue Sep 08 12:01:43 2009 +0200
 files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
 description:
 Make tabulate_facet_dofs accessible without having a ufc::cell, which makes it
 easy to access using iterators in Python.
 

Can we remove the version that takes a ufc::cell?

Garth

 
 changeset:   6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
 user:Johannes Ring joha...@simula.no
 date:Tue Sep 08 09:00:51 2009 +0200
 files:   test/unit/function/cpp/test.cpp
 description:
 Use CPPUNIT_ASSERT_DOUBLES_EQUAL.
 
 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:


 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
  tag: tip
  parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
  parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
  user:Anders Logg l...@simula.no
  date:Tue Sep 08 12:51:01 2009 +0200
  files:
  description:
  merge
 
 
  changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
  parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
  user:Anders Logg l...@simula.no
  date:Tue Sep 08 12:01:43 2009 +0200
  files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
  description:
  Make tabulate_facet_dofs accessible without having a ufc::cell, which makes 
  it
  easy to access using iterators in Python.
 

 Can we remove the version that takes a ufc::cell?

Yes. Perhaps we should remove all the direct wrappers for UFC stuff
and add a member function to return the underlying UFC object?

  const ufc::dof_map ufc_dof_map() const;

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-08 Thread Johan Hake

On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
 On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
  DOLFIN wrote:
   One or more new changesets pushed to the primary dolfin repository.
   A short summary of the last three changesets is included below.
  
   changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
   tag: tip
   parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
   parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
   user:Anders Logg l...@simula.no
   date:Tue Sep 08 12:51:01 2009 +0200
   files:
   description:
   merge
  
  
   changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
   parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
   user:Anders Logg l...@simula.no
   date:Tue Sep 08 12:01:43 2009 +0200
   files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
   description:
   Make tabulate_facet_dofs accessible without having a ufc::cell, which
   makes it easy to access using iterators in Python.
 
  Can we remove the version that takes a ufc::cell?
 
 Yes. Perhaps we should remove all the direct wrappers for UFC stuff
 and add a member function to return the underlying UFC object?
 
   const ufc::dof_map ufc_dof_map() const;

Should this be a member function of dolfin::DofMap? If so, it might be 
sufficient with

  const ufc::dof_map ufc() const;

If we are consistent this should not cause any confusion.

I have thought of doing the same in the python interface where there exist a 
number of different versions of these basic types. It would be nice to be able 
to extract the ufl or ufc form from a dolfin.Form, using ufl() or ufc().

Johan

 --
 Anders
 
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 08, 2009 at 01:09:32PM +0200, Johan Hake wrote:
 On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
  On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
   DOLFIN wrote:
One or more new changesets pushed to the primary dolfin repository.
A short summary of the last three changesets is included below.
   
changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
tag: tip
parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
user:Anders Logg l...@simula.no
date:Tue Sep 08 12:51:01 2009 +0200
files:
description:
merge
   
   
changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
user:Anders Logg l...@simula.no
date:Tue Sep 08 12:01:43 2009 +0200
files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
description:
Make tabulate_facet_dofs accessible without having a ufc::cell, which
makes it easy to access using iterators in Python.
  
   Can we remove the version that takes a ufc::cell?
 
  Yes. Perhaps we should remove all the direct wrappers for UFC stuff
  and add a member function to return the underlying UFC object?
 
const ufc::dof_map ufc_dof_map() const;

 Should this be a member function of dolfin::DofMap? If so, it might be
 sufficient with

   const ufc::dof_map ufc() const;

 If we are consistent this should not cause any confusion.

Sounds good to me.

 I have thought of doing the same in the python interface where there exist a
 number of different versions of these basic types. It would be nice to be able
 to extract the ufl or ufc form from a dolfin.Form, using ufl() or ufc().

Yes.

Can you add a blueprint? :-)

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Johan Hake wrote:
 On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
 On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
 tag: tip
 parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
 parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
 user:Anders Logg l...@simula.no
 date:Tue Sep 08 12:51:01 2009 +0200
 files:
 description:
 merge


 changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
 parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
 user:Anders Logg l...@simula.no
 date:Tue Sep 08 12:01:43 2009 +0200
 files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
 description:
 Make tabulate_facet_dofs accessible without having a ufc::cell, which
 makes it easy to access using iterators in Python.
 Can we remove the version that takes a ufc::cell?
 Yes. Perhaps we should remove all the direct wrappers for UFC stuff
 and add a member function to return the underlying UFC object?

   const ufc::dof_map ufc_dof_map() const;
 
 Should this be a member function of dolfin::DofMap? If so, it might be 
 sufficient with
 
   const ufc::dof_map ufc() const;
 

Definitely not! The whole point of DofMap is to not expose ufc::dof_map 
in DOLFIN. It took a lot of work some time ago to fix this. Using 
ufc:dof_map screws up any dof renumbering.

Garth

 If we are consistent this should not cause any confusion.
 
 I have thought of doing the same in the python interface where there exist a 
 number of different versions of these basic types. It would be nice to be 
 able 
 to extract the ufl or ufc form from a dolfin.Form, using ufl() or ufc().
 
 Johan
 
 --
 Anders

 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-09-08 Thread Johan Hake

On Tuesday 08 September 2009 15:19:42 Garth N. Wells wrote:
 Johan Hake wrote:
  On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
  On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
  DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
  tag: tip
  parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
  parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
  user:Anders Logg l...@simula.no
  date:Tue Sep 08 12:51:01 2009 +0200
  files:
  description:
  merge
 
 
  changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
  parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
  user:Anders Logg l...@simula.no
  date:Tue Sep 08 12:01:43 2009 +0200
  files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
  description:
  Make tabulate_facet_dofs accessible without having a ufc::cell, which
  makes it easy to access using iterators in Python.
 
  Can we remove the version that takes a ufc::cell?
 
  Yes. Perhaps we should remove all the direct wrappers for UFC stuff
  and add a member function to return the underlying UFC object?
 
const ufc::dof_map ufc_dof_map() const;
 
  Should this be a member function of dolfin::DofMap? If so, it might be
  sufficient with
 
const ufc::dof_map ufc() const;
 
 Definitely not! The whole point of DofMap is to not expose ufc::dof_map
 in DOLFIN. It took a lot of work some time ago to fix this. Using
 ufc:dof_map screws up any dof renumbering.

He, he...

Fine with me :) 

After some thinking I think (sic) that it is only for the dolfin.Form we need 
to get the ufl version of it. So I will at least probably add this.

Johan
 
 Garth
 
  If we are consistent this should not cause any confusion.
 
  I have thought of doing the same in the python interface where there
  exist a number of different versions of these basic types. It would be
  nice to be able to extract the ufl or ufc form from a dolfin.Form, using
  ufl() or ufc().

  Johan
 
  --
  Anders
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 08, 2009 at 03:21:29PM +0200, Johan Hake wrote:

 I think your find and replace function should be refined:

My script is fine. It was the human factor. :-)

I don't have Trilinos but it should be ok now.

--
Anders


 In file included from ./dolfin/la/LUSolver.h:25,
  from dolfin/fem/VariationalProblem.cpp:9:
 ./dolfin/la/EpetraMatrix.h:114: error: ‘virtual void
 dolfin::EpetraMatrix::mult(const dolfin::GenericVector,
 dolfin::GenericVector) const’ cannot be overloaded
 ./dolfin/la/EpetraMatrix.h:111: error: with ‘virtual void
 dolfin::EpetraMatrix::mult(const dolfin::GenericVector,
 dolfin::GenericVector) const’

 Johan

  changeset:   6977:3d54df3ed64ee441001571f125cd7eae95b235f3
  user:Ola Skavhaug skavh...@simula.no
  date:Tue Sep 08 14:38:11 2009 +0200
  files:   dolfin/mesh/MeshFunction.h
  description:
  Re-enable verbose output of MeshFunctions even though they are templated.
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Anders Logg wrote:
 On Tue, Sep 08, 2009 at 04:12:45PM +0200, Garth N. Wells wrote:

 Anders Logg wrote:
 On Tue, Sep 08, 2009 at 03:25:39PM +0200, Johan Hake wrote:
 On Tuesday 08 September 2009 15:19:42 Garth N. Wells wrote:
 Johan Hake wrote:
 On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
 On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
 tag: tip
 parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
 parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
 user:Anders Logg l...@simula.no
 date:Tue Sep 08 12:51:01 2009 +0200
 files:
 description:
 merge


 changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
 parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
 user:Anders Logg l...@simula.no
 date:Tue Sep 08 12:01:43 2009 +0200
 files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
 description:
 Make tabulate_facet_dofs accessible without having a ufc::cell, which
 makes it easy to access using iterators in Python.
 Can we remove the version that takes a ufc::cell?
 Yes. Perhaps we should remove all the direct wrappers for UFC stuff
 and add a member function to return the underlying UFC object?

   const ufc::dof_map ufc_dof_map() const;
 Should this be a member function of dolfin::DofMap? If so, it might be
 sufficient with

   const ufc::dof_map ufc() const;
 Definitely not! The whole point of DofMap is to not expose ufc::dof_map
 in DOLFIN. It took a lot of work some time ago to fix this. Using
 ufc:dof_map screws up any dof renumbering.
 There shouldn't be any problem allowing access to the underlying UFC
 objects. We do the same thing for PETSc with mat() and vec() and a
 user has just as big a chance to screw things up there.

 The problem with ufc objects is that developers screw things up too.
 I've spent a lot of time fixing this. Permitting access to the
 ufc::dof_map through DofMap defeats the purpose of having DofMap. I
 can't see any reason for allowing access to the ufc::dof_map from DofMap.

 Garth
 
 I don't use it, but I don't see the difference between this and our
 PETSc and Trilions wrappers.
 

There is a big difference. PETScFoo and EpetraFoo objects are always 
based on an underlying PETsc or an Epetra object. A DofMap can be 
initialised with a ufc::dof_map, after which the DofMap and the 
ufc::dof_map are more or less unrelated, for example after renumbering. 
Providing access to the ufc::dof_map encourages its use, which is fine 
as long as nothing is renumbered, but causes problems when the dof map 
is renumbered, like when running in parallel. This is why ufc::dof_map 
should not be be exposed anywhere in DOLFIN. This includes ufc::dof_map 
related functions, like DofMap::offset, which has been removed.

Garth

 Anyway, it's not a big deal and it's easier to not add it so let's
 keep it the way it is but modify the interface where appropriate so it
 assumes dolfin::Cell instead of ufc::cell etc.
 
 --
 Anders
 
 
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 08, 2009 at 04:12:45PM +0200, Garth N. Wells wrote:


 Anders Logg wrote:
  On Tue, Sep 08, 2009 at 03:25:39PM +0200, Johan Hake wrote:
  On Tuesday 08 September 2009 15:19:42 Garth N. Wells wrote:
  Johan Hake wrote:
  On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
  On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
  DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
  tag: tip
  parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
  parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
  user:Anders Logg l...@simula.no
  date:Tue Sep 08 12:51:01 2009 +0200
  files:
  description:
  merge
 
 
  changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
  parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
  user:Anders Logg l...@simula.no
  date:Tue Sep 08 12:01:43 2009 +0200
  files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
  description:
  Make tabulate_facet_dofs accessible without having a ufc::cell, which
  makes it easy to access using iterators in Python.
  Can we remove the version that takes a ufc::cell?
  Yes. Perhaps we should remove all the direct wrappers for UFC stuff
  and add a member function to return the underlying UFC object?
 
const ufc::dof_map ufc_dof_map() const;
  Should this be a member function of dolfin::DofMap? If so, it might be
  sufficient with
 
const ufc::dof_map ufc() const;
  Definitely not! The whole point of DofMap is to not expose ufc::dof_map
  in DOLFIN. It took a lot of work some time ago to fix this. Using
  ufc:dof_map screws up any dof renumbering.
 
  There shouldn't be any problem allowing access to the underlying UFC
  objects. We do the same thing for PETSc with mat() and vec() and a
  user has just as big a chance to screw things up there.
 

 The problem with ufc objects is that developers screw things up too.
 I've spent a lot of time fixing this. Permitting access to the
 ufc::dof_map through DofMap defeats the purpose of having DofMap. I
 can't see any reason for allowing access to the ufc::dof_map from DofMap.

 Garth

I don't use it, but I don't see the difference between this and our
PETSc and Trilions wrappers.

Anyway, it's not a big deal and it's easier to not add it so let's
keep it the way it is but modify the interface where appropriate so it
assumes dolfin::Cell instead of ufc::cell etc.

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 08, 2009 at 03:25:39PM +0200, Johan Hake wrote:
 On Tuesday 08 September 2009 15:19:42 Garth N. Wells wrote:
  Johan Hake wrote:
   On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
   On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
   DOLFIN wrote:
   One or more new changesets pushed to the primary dolfin repository.
   A short summary of the last three changesets is included below.
  
   changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
   tag: tip
   parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
   parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
   user:Anders Logg l...@simula.no
   date:Tue Sep 08 12:51:01 2009 +0200
   files:
   description:
   merge
  
  
   changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
   parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
   user:Anders Logg l...@simula.no
   date:Tue Sep 08 12:01:43 2009 +0200
   files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
   description:
   Make tabulate_facet_dofs accessible without having a ufc::cell, which
   makes it easy to access using iterators in Python.
  
   Can we remove the version that takes a ufc::cell?
  
   Yes. Perhaps we should remove all the direct wrappers for UFC stuff
   and add a member function to return the underlying UFC object?
  
 const ufc::dof_map ufc_dof_map() const;
  
   Should this be a member function of dolfin::DofMap? If so, it might be
   sufficient with
  
 const ufc::dof_map ufc() const;
 
  Definitely not! The whole point of DofMap is to not expose ufc::dof_map
  in DOLFIN. It took a lot of work some time ago to fix this. Using
  ufc:dof_map screws up any dof renumbering.

There shouldn't be any problem allowing access to the underlying UFC
objects. We do the same thing for PETSc with mat() and vec() and a
user has just as big a chance to screw things up there.

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Tue, Sep 08, 2009 at 05:00:37PM +0200, Garth N. Wells wrote:


 Anders Logg wrote:
  On Tue, Sep 08, 2009 at 04:12:45PM +0200, Garth N. Wells wrote:
 
  Anders Logg wrote:
  On Tue, Sep 08, 2009 at 03:25:39PM +0200, Johan Hake wrote:
  On Tuesday 08 September 2009 15:19:42 Garth N. Wells wrote:
  Johan Hake wrote:
  On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
  On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
  DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
  tag: tip
  parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
  parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
  user:Anders Logg l...@simula.no
  date:Tue Sep 08 12:51:01 2009 +0200
  files:
  description:
  merge
 
 
  changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
  parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
  user:Anders Logg l...@simula.no
  date:Tue Sep 08 12:01:43 2009 +0200
  files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
  description:
  Make tabulate_facet_dofs accessible without having a ufc::cell, 
  which
  makes it easy to access using iterators in Python.
  Can we remove the version that takes a ufc::cell?
  Yes. Perhaps we should remove all the direct wrappers for UFC stuff
  and add a member function to return the underlying UFC object?
 
const ufc::dof_map ufc_dof_map() const;
  Should this be a member function of dolfin::DofMap? If so, it might be
  sufficient with
 
const ufc::dof_map ufc() const;
  Definitely not! The whole point of DofMap is to not expose ufc::dof_map
  in DOLFIN. It took a lot of work some time ago to fix this. Using
  ufc:dof_map screws up any dof renumbering.
  There shouldn't be any problem allowing access to the underlying UFC
  objects. We do the same thing for PETSc with mat() and vec() and a
  user has just as big a chance to screw things up there.
 
  The problem with ufc objects is that developers screw things up too.
  I've spent a lot of time fixing this. Permitting access to the
  ufc::dof_map through DofMap defeats the purpose of having DofMap. I
  can't see any reason for allowing access to the ufc::dof_map from DofMap.
 
  Garth
 
  I don't use it, but I don't see the difference between this and our
  PETSc and Trilions wrappers.
 

 There is a big difference. PETScFoo and EpetraFoo objects are always
 based on an underlying PETsc or an Epetra object. A DofMap can be
 initialised with a ufc::dof_map, after which the DofMap and the
 ufc::dof_map are more or less unrelated, for example after renumbering.
 Providing access to the ufc::dof_map encourages its use, which is fine
 as long as nothing is renumbered, but causes problems when the dof map
 is renumbered, like when running in parallel. This is why ufc::dof_map
 should not be be exposed anywhere in DOLFIN. This includes ufc::dof_map
 related functions, like DofMap::offset, which has been removed.

 Garth

Good point. I see the difference now.

--
Anders


  Anyway, it's not a big deal and it's easier to not add it so let's
  keep it the way it is but modify the interface where appropriate so it
  assumes dolfin::Cell instead of ufc::cell etc.
 


 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge



Anders Logg wrote:
 On Tue, Sep 08, 2009 at 03:25:39PM +0200, Johan Hake wrote:
 On Tuesday 08 September 2009 15:19:42 Garth N. Wells wrote:
 Johan Hake wrote:
 On Tuesday 08 September 2009 12:58:41 Anders Logg wrote:
 On Tue, Sep 08, 2009 at 12:54:01PM +0200, Garth N. Wells wrote:
 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6975:37efb9fe9fe684b23521574a89048705a9a0bc6e
 tag: tip
 parent:  6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
 parent:  6973:abda55b5dfa2b2d0fbe2614b15483911ef661fdc
 user:Anders Logg l...@simula.no
 date:Tue Sep 08 12:51:01 2009 +0200
 files:
 description:
 merge


 changeset:   6974:6c4c77900222f82b7b32888b29a08fef9ddc5789
 parent:  6970:5d7fc35d3e597db508a005826efacb8dea6a00d9
 user:Anders Logg l...@simula.no
 date:Tue Sep 08 12:01:43 2009 +0200
 files:   dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
 description:
 Make tabulate_facet_dofs accessible without having a ufc::cell, which
 makes it easy to access using iterators in Python.
 Can we remove the version that takes a ufc::cell?
 Yes. Perhaps we should remove all the direct wrappers for UFC stuff
 and add a member function to return the underlying UFC object?

   const ufc::dof_map ufc_dof_map() const;
 Should this be a member function of dolfin::DofMap? If so, it might be
 sufficient with

   const ufc::dof_map ufc() const;
 Definitely not! The whole point of DofMap is to not expose ufc::dof_map
 in DOLFIN. It took a lot of work some time ago to fix this. Using
 ufc:dof_map screws up any dof renumbering.
 
 There shouldn't be any problem allowing access to the underlying UFC
 objects. We do the same thing for PETSc with mat() and vec() and a
 user has just as big a chance to screw things up there.
 

The problem with ufc objects is that developers screw things up too. 
I've spent a lot of time fixing this. Permitting access to the 
ufc::dof_map through DofMap defeats the purpose of having DofMap. I 
can't see any reason for allowing access to the ufc::dof_map from DofMap.

Garth

 --
 Anders
 
 
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-19 Thread Johan Hake

On Tuesday 18 August 2009 22:23:50 Anders Logg wrote:
 On Tue, Aug 18, 2009 at 10:01:49PM +0200, DOLFIN wrote:
  changeset:   6793:4ec31c652fb02c15906df9b243ac8a95ab17993d
  parent:  6779:ef3291872c9d92c7937b1808b392cfb6a0e2
  user:Anders Logg l...@simula.no
  date:Tue Aug 18 21:58:16 2009 +0200
  files:   site-packages/dolfin/jit.py
  description:
  Wrap JIT compilation and use barrier to compile first on process 0,
  then use results from cache on other processes. Only implemented for
  forms, not other objects.

 This changes the way JIT compilation is handled in parallel (after a
 discussion with Hake earlier today).

 We now let the first process compile first while the others wait. Then
 the other processes call the JIT compiler and may then reuse the
 compiled form from cache since it's already been compiled by the first
 process. Much better than what we had before.

 I've only implemented it for JIT compilation of forms, not other
 objects (like Functions). Johan, could you take a look at this?

 I imagine we could put the code from jit.jit into some utility
 function, something like which could be reused in both places:

   def jit_wrap(jit, *args):

   # Just call foo when running in serial
   if MPI.num_processes() == 1:
   return jit(*args):

   # Compile first on process 0
   if MPI.process_number() == 0:
 info(Calling JIT compiler on first process.)
 output = jit(*args)
   MPI.barrier()

   # Then compile on all other processes (which may then just read the
 cache) if not MPI.process_number() == 0:
 info(JIT compilation done on first process, reusing from cache.)
 output = jit(*args)

   return output

I can look into this. 

It should be straightforward, now when I have gathered all jit compilation in 
PyDOLFIN in one module. I think I need to add a **kwargs to the function 
though. Could you add a dummy **kwargs in ffc.jit, to make it possible? Maybe 
together with a check with some appropriate error message if some one is by 
accident using it?

Johan
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-19 Thread Johan Hake

On Tuesday 18 August 2009 14:54:24 Garth N. Wells wrote:
 Johan Hake wrote:
  On Monday 17 August 2009 19:19:40 Anders Logg wrote:
  On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
  changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
  parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
  user:Anders Logg l...@simula.no
  date:Mon Aug 17 19:08:56 2009 +0200
  files:   site-packages/dolfin/compile_function.py
  site-packages/dolfin/jit.py description:
  Make JIT compiler work in parallel. The process number is added to the
  signature to create a unique signature for each process. This means
  that each process will compile its own form. This may not be optimal
  and could possibly be handled by Instant. On the other hand, it seems
  to work nicely and might also be advantageous when processes don't
  share a common cache.
 
  The Poisson Python demo now runs as is without the need for first
  running it in serial (to handle JIT compilation):
 
  Did it not work before this change? I know Martin added some file locks
  to prevent simultaneous compilations of the same module.
 
mpirun -n 4 python demo.py
 
  Do I have to set some environmental variables to make this work. I can't
  get it to work (probably some stupid error) :P
 
  Johan
 
  When running the above command I get:
 
  ssh: connect to host hake-laptop port 22: Connection refused

 This looks like a known bug in the Ubuntu MPI package

http://www.open-mpi.org/community/lists/users/2009/03/8571.php
https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/365122

I downloaded the source packages applied the patch and compiled. Unfortunately 
it did solve the problem. 

I think I stay with the local ssh workaround for now. It is mainly for 
testing.

Johan

 Garth

  -
 - A daemon (pid 32065) died unexpectedly with status 255 while attempting
  to launch so we are aborting.
 
  There may be more information reported by the environment (see above).
 
  This may be because the daemon was unable to find all the needed shared
  libraries on the remote node. You may set your LD_LIBRARY_PATH to have
  the location of the shared libraries on the remote nodes and this will
  automatically be forwarded to the remote nodes.
  -
 -
  -
 - mpirun noticed that the job aborted, but has no info as to the process
  that caused that situation.
  -
 - mpirun: clean termination accomplished
 
 
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-19 Thread Garth N. Wells



Johan Hake wrote:
 On Tuesday 18 August 2009 14:54:24 Garth N. Wells wrote:
 Johan Hake wrote:
 On Monday 17 August 2009 19:19:40 Anders Logg wrote:
 On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
 changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
 parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 19:08:56 2009 +0200
 files:   site-packages/dolfin/compile_function.py
 site-packages/dolfin/jit.py description:
 Make JIT compiler work in parallel. The process number is added to the
 signature to create a unique signature for each process. This means
 that each process will compile its own form. This may not be optimal
 and could possibly be handled by Instant. On the other hand, it seems
 to work nicely and might also be advantageous when processes don't
 share a common cache.
 The Poisson Python demo now runs as is without the need for first
 running it in serial (to handle JIT compilation):
 Did it not work before this change? I know Martin added some file locks
 to prevent simultaneous compilations of the same module.

   mpirun -n 4 python demo.py
 Do I have to set some environmental variables to make this work. I can't
 get it to work (probably some stupid error) :P

 Johan

 When running the above command I get:

 ssh: connect to host hake-laptop port 22: Connection refused
 This looks like a known bug in the Ubuntu MPI package

http://www.open-mpi.org/community/lists/users/2009/03/8571.php
https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/365122
 
 I downloaded the source packages applied the patch and compiled. 
 Unfortunately 
 it did solve the problem. 



Did you download the latest version of OpenMPI? There is no need to 
patch the latest version.

Do you have other Ubuntu packages that depend on MPI installed, like 
PETSc? Because I don't use the Ubuntu MPI package, I have built PETSc, 
ParMETIS, etc myself.

Garth

 I think I stay with the local ssh workaround for now. It is mainly for 
 testing.
 
 Johan
 
 Garth

 -
 - A daemon (pid 32065) died unexpectedly with status 255 while attempting
 to launch so we are aborting.

 There may be more information reported by the environment (see above).

 This may be because the daemon was unable to find all the needed shared
 libraries on the remote node. You may set your LD_LIBRARY_PATH to have
 the location of the shared libraries on the remote nodes and this will
 automatically be forwarded to the remote nodes.
 -
 -
 -
 - mpirun noticed that the job aborted, but has no info as to the process
 that caused that situation.
 -
 - mpirun: clean termination accomplished



 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-19 Thread Johan Hake

On Wednesday 19 August 2009 12:18:49 Garth N. Wells wrote:
 Johan Hake wrote:
  On Tuesday 18 August 2009 14:54:24 Garth N. Wells wrote:
  Johan Hake wrote:
  On Monday 17 August 2009 19:19:40 Anders Logg wrote:
  On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
  changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
  parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
  user:Anders Logg l...@simula.no
  date:Mon Aug 17 19:08:56 2009 +0200
  files:   site-packages/dolfin/compile_function.py
  site-packages/dolfin/jit.py description:
  Make JIT compiler work in parallel. The process number is added to
  the signature to create a unique signature for each process. This
  means that each process will compile its own form. This may not be
  optimal and could possibly be handled by Instant. On the other hand,
  it seems to work nicely and might also be advantageous when processes
  don't share a common cache.
 
  The Poisson Python demo now runs as is without the need for first
  running it in serial (to handle JIT compilation):
 
  Did it not work before this change? I know Martin added some file locks
  to prevent simultaneous compilations of the same module.
 
mpirun -n 4 python demo.py
 
  Do I have to set some environmental variables to make this work. I
  can't get it to work (probably some stupid error) :P
 
  Johan
 
  When running the above command I get:
 
  ssh: connect to host hake-laptop port 22: Connection refused
 
  This looks like a known bug in the Ubuntu MPI package
 
 http://www.open-mpi.org/community/lists/users/2009/03/8571.php
 https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/365122
 
  I downloaded the source packages applied the patch and compiled.
  Unfortunately it did solve the problem.

 Did you download the latest version of OpenMPI? There is no need to
 patch the latest version.

No, just the jaunty source packages.

 Do you have other Ubuntu packages that depend on MPI installed, like
 PETSc? Because I don't use the Ubuntu MPI package, I have built PETSc,
 ParMETIS, etc myself.

Precisely, and I wanted to avoid this. Therefore I try to stick to the ubuntu 
packages. We'll see how long I stay with this solution.

Johan

 Garth

  I think I stay with the local ssh workaround for now. It is mainly for
  testing.
 
  Johan
 
  Garth
 
  ---
 -- - A daemon (pid 32065) died unexpectedly with status 255 while
  attempting to launch so we are aborting.
 
  There may be more information reported by the environment (see above).
 
  This may be because the daemon was unable to find all the needed shared
  libraries on the remote node. You may set your LD_LIBRARY_PATH to have
  the location of the shared libraries on the remote nodes and this will
  automatically be forwarded to the remote nodes.
  ---
 -- -
  ---
 -- - mpirun noticed that the job aborted, but has no info as to the
  process that caused that situation.
  ---
 -- - mpirun: clean termination accomplished
 
 
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-18 Thread kent-and

On Mon, Aug 17, 2009 at 11:20:08PM +0200, Johan Hake wrote:
On Monday 17 August 2009 19:19:40 Anders Logg wrote:
On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
changeset: 6762:ca407204632a1b0430099c243c915a151b2bd941
parent: 6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
user:Anders Logg l...@simula.no
date:Mon Aug 17 19:08:56 2009 +0200
files: site-packages/dolfin/compile_function.py
site-packages/dolfin/jit.py description:
Make JIT compiler work in parallel. The process number is added to
the
signature to create a unique signature for each process. This means
that
each process will compile its own form. This may not be optimal and
could
possibly be handled by Instant. On the other hand, it seems to work
nicely and might also be advantageous when processes don't share a
common
cache.

The Poisson Python demo now runs as is without the need for first
running it in serial (to handle JIT compilation):

Did it not work before this change? I know Martin added some file locks
to
prevent simultaneous compilations of the same module.

No, it didn't work before. I get things like

In instant.build_module: Path
'/home/logg/.instant/cache/form_f38430af401fbeddb9be4091a6fcde37cef9fa35'
already exists, but module wasn't found in cache previously. Not
overwriting, assuming this module is valid.
Traceback (most recent call last):
File demo.py, line 23, in module
V = FunctionSpace(mesh, CG, 1)
File

/home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-packages/dolfin/functionspace.py,
line 181, in __init__
FunctionSpaceBase.__init__(self, mesh, element)
File

/home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-packages/dolfin/functionspace.py,
line 43, in __init__
ufc_element, ufc_dofmap = jit(self._element)
File

/home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-packages/dolfin/jit.py,
line 67, in jit
return jit_compile(form, options)
File

/home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.py,
line 56, in jit
return jit_element(object, options)
File

/home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.py,
line 125, in jit_element
(compiled_form, module, form_data) = jit_form(form, options)
File

/home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.py,
line 102, in jit_form
os.unlink(signature + .h)
OSError: [Errno 2] No such file or directory:
'form_f38430af401fbeddb9be4091a6fcde37cef9fa35.h'

I guess the second process tries to read the generated file but
it's not ready yet (still being generated by the first process).

It would be good to handle the parallel JIT compilation as part of
Instant, but I don't know what the best solution is.

OK, I think the parallel caching mechanism works e.g. on bigblue when several
similar processes start on different machines that has its own local
tmp files and only the first on to finish compiling will copy it to the
actual cache.
The problem here might be that the different processes mess with the same
tmp files. I'll ask Martin.

Kent

mpirun -n 4 python demo.py

Do I have to set some environmental variables to make this work. I can't
get
it to work (probably some stupid error) :P

No, nothing. It should work out of the box.

Johan

When running the above command I get:

ssh: connect to host hake-laptop port 22: Connection refused

Can you run other processes in parallel?

mpirun -n 4 ls

Maybe you need to install sshd? I didn't know it was required.

--
Anders

--
A daemon (pid 32065) died unexpectedly with status 255 while attempting
to launch so we are aborting.

There may be more information reported by the environment (see above).

This may be because the daemon was unable to find all the needed shared
libraries on the remote node. You may set your LD_LIBRARY_PATH to have
the
location of the shared libraries on the remote nodes and this will
automatically be forwarded to the remote nodes.
--
--
mpirun noticed that the job aborted, but has no info as to the process
that caused that situation.
--
mpirun: clean termination accomplished

___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-18 Thread Johan Hake

On Monday 17 August 2009 23:51:39 Anders Logg wrote:
 On Mon, Aug 17, 2009 at 11:20:08PM +0200, Johan Hake wrote:
  On Monday 17 August 2009 19:19:40 Anders Logg wrote:
   On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
user:Anders Logg l...@simula.no
date:Mon Aug 17 19:08:56 2009 +0200
files:   site-packages/dolfin/compile_function.py
site-packages/dolfin/jit.py description:
Make JIT compiler work in parallel. The process number is added to
the signature to create a unique signature for each process. This
means that each process will compile its own form. This may not be
optimal and could possibly be handled by Instant. On the other hand,
it seems to work nicely and might also be advantageous when processes
don't share a common cache.
  
   The Poisson Python demo now runs as is without the need for first
   running it in serial (to handle JIT compilation):
 
  Did it not work before this change? I know Martin added some file locks
  to prevent simultaneous compilations of the same module.

 No, it didn't work before. I get things like

 In instant.build_module: Path
 '/home/logg/.instant/cache/form_f38430af401fbeddb9be4091a6fcde37cef9fa35'
 already exists, but module wasn't found in cache previously. Not
 overwriting, assuming this module is valid.
 Traceback (most recent call last):
   File demo.py, line 23, in module
 V = FunctionSpace(mesh, CG, 1)
   File
  
 /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pack
ages/dolfin/functionspace.py, line 181, in __init__
 FunctionSpaceBase.__init__(self, mesh, element)
   File
  
 /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pack
ages/dolfin/functionspace.py, line 43, in __init__
 ufc_element, ufc_dofmap = jit(self._element)
   File
  
 /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pack
ages/dolfin/jit.py, line 67, in jit
 return jit_compile(form, options)
   File
  
 /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.
py, line 56, in jit
 return jit_element(object, options)
   File
  
 /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.
py, line 125, in jit_element
 (compiled_form, module, form_data) = jit_form(form, options)
   File
  
 /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.
py, line 102, in jit_form
 os.unlink(signature + .h)
   OSError: [Errno 2] No such file or directory:
   'form_f38430af401fbeddb9be4091a6fcde37cef9fa35.h'

It looks like the error comes from unlinking a file more than one time (done 
in ffc/jit.py), and not in instant. I will look at it.

 I guess the second process tries to read the generated file but
 it's not ready yet (still being generated by the first process).

 It would be good to handle the parallel JIT compilation as part of
 Instant, but I don't know what the best solution is.

 mpirun -n 4 python demo.py
 
  Do I have to set some environmental variables to make this work. I can't
  get it to work (probably some stupid error) :P

 No, nothing. It should work out of the box.

  Johan
 
  When running the above command I get:
 
  ssh: connect to host hake-laptop port 22: Connection refused

 Can you run other processes in parallel?

   mpirun -n 4 ls

 Maybe you need to install sshd? I didn't know it was required.

Yes, that did the trick! openssh-server in ubuntu, btw, and I also had to put 
my public ssh keys in my own authorized keys. 

Johan

 --
 Anders

  -
 - A daemon (pid 32065) died unexpectedly with status 255 while attempting
  to launch so we are aborting.
 
  There may be more information reported by the environment (see above).
 
  This may be because the daemon was unable to find all the needed shared
  libraries on the remote node. You may set your LD_LIBRARY_PATH to have
  the location of the shared libraries on the remote nodes and this will
  automatically be forwarded to the remote nodes.
  -
 -
  -
 - mpirun noticed that the job aborted, but has no info as to the process
  that caused that situation.
  -
 - mpirun: clean termination accomplished
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-18 Thread Anders Logg

On Tue, Aug 18, 2009 at 08:56:06AM +0200, Johan Hake wrote:
 On Monday 17 August 2009 23:51:39 Anders Logg wrote:
  On Mon, Aug 17, 2009 at 11:20:08PM +0200, Johan Hake wrote:
   On Monday 17 August 2009 19:19:40 Anders Logg wrote:
On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
 changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
 parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 19:08:56 2009 +0200
 files:   site-packages/dolfin/compile_function.py
 site-packages/dolfin/jit.py description:
 Make JIT compiler work in parallel. The process number is added to
 the signature to create a unique signature for each process. This
 means that each process will compile its own form. This may not be
 optimal and could possibly be handled by Instant. On the other hand,
 it seems to work nicely and might also be advantageous when processes
 don't share a common cache.
   
The Poisson Python demo now runs as is without the need for first
running it in serial (to handle JIT compilation):
  
   Did it not work before this change? I know Martin added some file locks
   to prevent simultaneous compilations of the same module.
 
  No, it didn't work before. I get things like
 
  In instant.build_module: Path
  '/home/logg/.instant/cache/form_f38430af401fbeddb9be4091a6fcde37cef9fa35'
  already exists, but module wasn't found in cache previously. Not
  overwriting, assuming this module is valid.
  Traceback (most recent call last):
File demo.py, line 23, in module
  V = FunctionSpace(mesh, CG, 1)
File
 
  /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pack
 ages/dolfin/functionspace.py, line 181, in __init__
  FunctionSpaceBase.__init__(self, mesh, element)
File
 
  /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pack
 ages/dolfin/functionspace.py, line 43, in __init__
  ufc_element, ufc_dofmap = jit(self._element)
File
 
  /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pack
 ages/dolfin/jit.py, line 67, in jit
  return jit_compile(form, options)
File
 
  /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.
 py, line 56, in jit
  return jit_element(object, options)
File
 
  /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.
 py, line 125, in jit_element
  (compiled_form, module, form_data) = jit_form(form, options)
File
 
  /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.
 py, line 102, in jit_form
  os.unlink(signature + .h)
OSError: [Errno 2] No such file or directory:
'form_f38430af401fbeddb9be4091a6fcde37cef9fa35.h'

 It looks like the error comes from unlinking a file more than one time (done
 in ffc/jit.py), and not in instant. I will look at it.

  I guess the second process tries to read the generated file but
  it's not ready yet (still being generated by the first process).
 
  It would be good to handle the parallel JIT compilation as part of
  Instant, but I don't know what the best solution is.
 
  mpirun -n 4 python demo.py
  
   Do I have to set some environmental variables to make this work. I can't
   get it to work (probably some stupid error) :P
 
  No, nothing. It should work out of the box.
 
   Johan
  
   When running the above command I get:
  
   ssh: connect to host hake-laptop port 22: Connection refused
 
  Can you run other processes in parallel?
 
mpirun -n 4 ls
 
  Maybe you need to install sshd? I didn't know it was required.

 Yes, that did the trick! openssh-server in ubuntu, btw, and I also had to put
 my public ssh keys in my own authorized keys.

 Johan

Something for the FAQ if anyone has some spare cycles:

http://www.fenics.org/wiki/Frequently_asked_questions

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-18 Thread Johan Hake

On Tuesday 18 August 2009 08:56:06 Johan Hake wrote:
 On Monday 17 August 2009 23:51:39 Anders Logg wrote:
  On Mon, Aug 17, 2009 at 11:20:08PM +0200, Johan Hake wrote:
   On Monday 17 August 2009 19:19:40 Anders Logg wrote:
On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
 changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
 parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 19:08:56 2009 +0200
 files:   site-packages/dolfin/compile_function.py
 site-packages/dolfin/jit.py description:
 Make JIT compiler work in parallel. The process number is added to
 the signature to create a unique signature for each process. This
 means that each process will compile its own form. This may not be
 optimal and could possibly be handled by Instant. On the other
 hand, it seems to work nicely and might also be advantageous when
 processes don't share a common cache.
   
The Poisson Python demo now runs as is without the need for first
running it in serial (to handle JIT compilation):
  
   Did it not work before this change? I know Martin added some file locks
   to prevent simultaneous compilations of the same module.
 
  No, it didn't work before. I get things like
 
  In instant.build_module: Path
  '/home/logg/.instant/cache/form_f38430af401fbeddb9be4091a6fcde37cef9fa35'
  already exists, but module wasn't found in cache previously. Not
  overwriting, assuming this module is valid.
  Traceback (most recent call last):
File demo.py, line 23, in module
  V = FunctionSpace(mesh, CG, 1)
File
 
  /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pa
 ck ages/dolfin/functionspace.py, line 181, in __init__
  FunctionSpaceBase.__init__(self, mesh, element)
File
 
  /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pa
 ck ages/dolfin/functionspace.py, line 43, in __init__
  ufc_element, ufc_dofmap = jit(self._element)
File
 
  /home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-pa
 ck ages/dolfin/jit.py, line 67, in jit
  return jit_compile(form, options)
File
 
  /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/ji
 t. py, line 56, in jit
  return jit_element(object, options)
File
 
  /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/ji
 t. py, line 125, in jit_element
  (compiled_form, module, form_data) = jit_form(form, options)
File
 
  /home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/ji
 t. py, line 102, in jit_form
  os.unlink(signature + .h)
OSError: [Errno 2] No such file or directory:
'form_f38430af401fbeddb9be4091a6fcde37cef9fa35.h'

 It looks like the error comes from unlinking a file more than one time
 (done in ffc/jit.py), and not in instant. I will look at it.

  I guess the second process tries to read the generated file but
  it's not ready yet (still being generated by the first process).
 
  It would be good to handle the parallel JIT compilation as part of
  Instant, but I don't know what the best solution is.
 
  mpirun -n 4 python demo.py
  
   Do I have to set some environmental variables to make this work. I
   can't get it to work (probably some stupid error) :P
 
  No, nothing. It should work out of the box.
 
   Johan
  
   When running the above command I get:
  
   ssh: connect to host hake-laptop port 22: Connection refused
 
  Can you run other processes in parallel?
 
mpirun -n 4 ls
 
  Maybe you need to install sshd? I didn't know it was required.

 Yes, that did the trick! openssh-server in ubuntu, btw, and I also had to
 put my public ssh keys in my own authorized keys.

Also I had to add an alias for mpirun:

  alias mpirun='mpirun -x PYTHONPATH -x LD_LIBRARY_PATH -x PKG_CONFIG_PATH -x 
PATH -x DISPLAY'

which forwards the mentioned environments variables, and I had to set the 

  DISPLAY=:0.0

in my .basrh file. 

I know that others do not have to forward these variables but, I couldn't find 
a way to not do it.

Johan

 Johan

  --
  Anders
 
   ---
  -- - A daemon (pid 32065) died unexpectedly with status 255 while
   attempting to launch so we are aborting.
  
   There may be more information reported by the environment (see above).
  
   This may be because the daemon was unable to find all the needed shared
   libraries on the remote node. You may set your LD_LIBRARY_PATH to have
   the location of the shared libraries on the remote nodes and this will
   automatically be forwarded to the remote nodes.
   ---
  -- -
   ---
  -- - mpirun noticed that the job aborted, but has no info as to the
   process that caused that situation.

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-18 Thread Garth N. Wells



Johan Hake wrote:
 On Monday 17 August 2009 19:19:40 Anders Logg wrote:
 On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
 changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
 parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 19:08:56 2009 +0200
 files:   site-packages/dolfin/compile_function.py
 site-packages/dolfin/jit.py description:
 Make JIT compiler work in parallel. The process number is added to the
 signature to create a unique signature for each process. This means that
 each process will compile its own form. This may not be optimal and could
 possibly be handled by Instant. On the other hand, it seems to work
 nicely and might also be advantageous when processes don't share a common
 cache.
 The Poisson Python demo now runs as is without the need for first
 running it in serial (to handle JIT compilation):
 
 Did it not work before this change? I know Martin added some file locks to 
 prevent simultaneous compilations of the same module.
 
   mpirun -n 4 python demo.py
 
 Do I have to set some environmental variables to make this work. I can't get 
 it to work (probably some stupid error) :P
 
 Johan
 
 When running the above command I get:
 
 ssh: connect to host hake-laptop port 22: Connection refused

This looks like a known bug in the Ubuntu MPI package

   http://www.open-mpi.org/community/lists/users/2009/03/8571.php
   https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/365122

Garth

 --
 A daemon (pid 32065) died unexpectedly with status 255 while attempting
 to launch so we are aborting.
 
 There may be more information reported by the environment (see above).
 
 This may be because the daemon was unable to find all the needed shared
 libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
 location of the shared libraries on the remote nodes and this will
 automatically be forwarded to the remote nodes.
 --
 --
 mpirun noticed that the job aborted, but has no info as to the process
 that caused that situation.
 --
 mpirun: clean termination accomplished
 
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev

___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-18 Thread Anders Logg

On Tue, Aug 18, 2009 at 01:54:24PM +0100, Garth N. Wells wrote:


 Johan Hake wrote:
  On Monday 17 August 2009 19:19:40 Anders Logg wrote:
  On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
  changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
  parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
  user:Anders Logg l...@simula.no
  date:Mon Aug 17 19:08:56 2009 +0200
  files:   site-packages/dolfin/compile_function.py
  site-packages/dolfin/jit.py description:
  Make JIT compiler work in parallel. The process number is added to the
  signature to create a unique signature for each process. This means that
  each process will compile its own form. This may not be optimal and could
  possibly be handled by Instant. On the other hand, it seems to work
  nicely and might also be advantageous when processes don't share a common
  cache.
  The Poisson Python demo now runs as is without the need for first
  running it in serial (to handle JIT compilation):
 
  Did it not work before this change? I know Martin added some file locks to
  prevent simultaneous compilations of the same module.
 
mpirun -n 4 python demo.py
 
  Do I have to set some environmental variables to make this work. I can't get
  it to work (probably some stupid error) :P
 
  Johan
 
  When running the above command I get:
 
  ssh: connect to host hake-laptop port 22: Connection refused

 This looks like a known bug in the Ubuntu MPI package

http://www.open-mpi.org/community/lists/users/2009/03/8571.php
https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/365122

 Garth

I use the standard Ubuntu (Karmic) OpenMPI package and I can just run
without setting any variables.

--
Anders


  --
  A daemon (pid 32065) died unexpectedly with status 255 while attempting
  to launch so we are aborting.
 
  There may be more information reported by the environment (see above).
 
  This may be because the daemon was unable to find all the needed shared
  libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
  location of the shared libraries on the remote nodes and this will
  automatically be forwarded to the remote nodes.
  --
  --
  mpirun noticed that the job aborted, but has no info as to the process
  that caused that situation.
  --
  mpirun: clean termination accomplished
 
 
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev

 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-18 Thread Garth N. Wells



Anders Logg wrote:
 On Tue, Aug 18, 2009 at 01:54:24PM +0100, Garth N. Wells wrote:

 Johan Hake wrote:
 On Monday 17 August 2009 19:19:40 Anders Logg wrote:
 On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
 changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
 parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 19:08:56 2009 +0200
 files:   site-packages/dolfin/compile_function.py
 site-packages/dolfin/jit.py description:
 Make JIT compiler work in parallel. The process number is added to the
 signature to create a unique signature for each process. This means that
 each process will compile its own form. This may not be optimal and could
 possibly be handled by Instant. On the other hand, it seems to work
 nicely and might also be advantageous when processes don't share a common
 cache.
 The Poisson Python demo now runs as is without the need for first
 running it in serial (to handle JIT compilation):
 Did it not work before this change? I know Martin added some file locks to
 prevent simultaneous compilations of the same module.

   mpirun -n 4 python demo.py
 Do I have to set some environmental variables to make this work. I can't get
 it to work (probably some stupid error) :P

 Johan

 When running the above command I get:

 ssh: connect to host hake-laptop port 22: Connection refused
 This looks like a known bug in the Ubuntu MPI package

http://www.open-mpi.org/community/lists/users/2009/03/8571.php
https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/365122

 Garth
 
 I use the standard Ubuntu (Karmic) OpenMPI package 

This is a newer version of OpenMPI which has been fixed.

Garth

and I can just run
 without setting any variables.
 
 --
 Anders
 
 
 --
 A daemon (pid 32065) died unexpectedly with status 255 while attempting
 to launch so we are aborting.

 There may be more information reported by the environment (see above).

 This may be because the daemon was unable to find all the needed shared
 libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
 location of the shared libraries on the remote nodes and this will
 automatically be forwarded to the remote nodes.
 --
 --
 mpirun noticed that the job aborted, but has no info as to the process
 that caused that situation.
 --
 mpirun: clean termination accomplished



 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev

 

 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-18 Thread Anders Logg

On Tue, Aug 18, 2009 at 10:01:49PM +0200, DOLFIN wrote:

 changeset:   6793:4ec31c652fb02c15906df9b243ac8a95ab17993d
 parent:  6779:ef3291872c9d92c7937b1808b392cfb6a0e2
 user:Anders Logg l...@simula.no
 date:Tue Aug 18 21:58:16 2009 +0200
 files:   site-packages/dolfin/jit.py
 description:
 Wrap JIT compilation and use barrier to compile first on process 0,
 then use results from cache on other processes. Only implemented for
 forms, not other objects.

This changes the way JIT compilation is handled in parallel (after a
discussion with Hake earlier today).

We now let the first process compile first while the others wait. Then
the other processes call the JIT compiler and may then reuse the
compiled form from cache since it's already been compiled by the first
process. Much better than what we had before.

I've only implemented it for JIT compilation of forms, not other
objects (like Functions). Johan, could you take a look at this?

I imagine we could put the code from jit.jit into some utility
function, something like which could be reused in both places:

  def jit_wrap(jit, *args):

  # Just call foo when running in serial
  if MPI.num_processes() == 1:
  return jit(*args):

  # Compile first on process 0
  if MPI.process_number() == 0:
info(Calling JIT compiler on first process.)
output = jit(*args)
  MPI.barrier()

  # Then compile on all other processes (which may then just read the cache)
  if not MPI.process_number() == 0:
info(JIT compilation done on first process, reusing from cache.)
output = jit(*args)

  return output

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

On Mon, Aug 17, 2009 at 06:38:27PM +0200, DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
 tag: tip
 parent:  6758:6600777e60b2e5ffd47753d60ab9253c212fb63d
 parent:  6757:48f8293aec2f5130d61a1040203f84a7ae44e65d
 user:Garth N. Wells gn...@cam.ac.uk
 date:Mon Aug 17 17:38:14 2009 +0100
 files:
 description:
 merge.


 changeset:   6758:6600777e60b2e5ffd47753d60ab9253c212fb63d
 parent:  6755:4d42e831264dbe74bbff2044f364bbb8b69e8b56
 user:Garth N. Wells gn...@cam.ac.uk
 date:Mon Aug 17 17:37:55 2009 +0100
 files:   dolfin/function/SubFunction.h dolfin/function/SubFunctionData.h 
 dolfin/io/VTKFile.cpp
 description:
 Ass missing file.

Sorry, I didn't notice that you assed it before posting.

--
Anders



 changeset:   6757:48f8293aec2f5130d61a1040203f84a7ae44e65d
 parent:  6756:916be33ef31b3def3fd355d6a0604449bda26cc0
 parent:  6755:4d42e831264dbe74bbff2044f364bbb8b69e8b56
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 18:33:19 2009 +0200
 files:
 description:
 merge

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

On Monday 17 August 2009 18:39:54 Anders Logg wrote:
 On Mon, Aug 17, 2009 at 06:38:27PM +0200, DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
  tag: tip
  parent:  6758:6600777e60b2e5ffd47753d60ab9253c212fb63d
  parent:  6757:48f8293aec2f5130d61a1040203f84a7ae44e65d
  user:Garth N. Wells gn...@cam.ac.uk
  date:Mon Aug 17 17:38:14 2009 +0100
  files:
  description:
  merge.
 
 
  changeset:   6758:6600777e60b2e5ffd47753d60ab9253c212fb63d
  parent:  6755:4d42e831264dbe74bbff2044f364bbb8b69e8b56
  user:Garth N. Wells gn...@cam.ac.uk
  date:Mon Aug 17 17:37:55 2009 +0100
  files:   dolfin/function/SubFunction.h
  dolfin/function/SubFunctionData.h dolfin/io/VTKFile.cpp description:
  Ass missing file.

 Sorry, I didn't notice that you assed it before posting.

*laugh*

Johan

 --
 Anders

  changeset:   6757:48f8293aec2f5130d61a1040203f84a7ae44e65d
  parent:  6756:916be33ef31b3def3fd355d6a0604449bda26cc0
  parent:  6755:4d42e831264dbe74bbff2044f364bbb8b69e8b56
  user:Anders Logg l...@simula.no
  date:Mon Aug 17 18:33:19 2009 +0200
  files:
  description:
  merge
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:

 changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
 parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 19:08:56 2009 +0200
 files:   site-packages/dolfin/compile_function.py 
 site-packages/dolfin/jit.py
 description:
 Make JIT compiler work in parallel. The process number is added to the 
 signature
 to create a unique signature for each process. This means that each process 
 will
 compile its own form. This may not be optimal and could possibly be handled by
 Instant. On the other hand, it seems to work nicely and might also be 
 advantageous
 when processes don't share a common cache.

The Poisson Python demo now runs as is without the need for first
running it in serial (to handle JIT compilation):

  mpirun -n 4 python demo.py

Even plotting works nicely.

Check if the above handling of JIT compilation looks correct.

--
Anders


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

On Monday 17 August 2009 19:18:14 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6765:84e71645284a0ba9cbb851533f61294ca2e2668e
 tag: tip
 parent:  6764:e600ba505bd85cea7809271066bcda330b2fc53e
 parent:  6763:d8a5d0cb18a467039fd1da48363d5ac68ece917c
 user:Garth N. Wells gn...@cam.ac.uk
 date:Mon Aug 17 18:16:29 2009 +0100
 files:
 description:
 merge.


 changeset:   6764:e600ba505bd85cea7809271066bcda330b2fc53e
 parent:  6761:f936b2842d23b5d0910081001ea16e23eed375a2
 user:Garth N. Wells gn...@cam.ac.uk
 date:Mon Aug 17 18:15:31 2009 +0100
 files:   dolfin/function/Function.cpp dolfin/function/Function.h
 dolfin/function/SpecialFunctions.cpp description:
 Remove Function::geometric_dimension().

 This breaks the code in dolfin/swig/typemaps.i. Can someone explain it to
 me?

When Function is subclassed in python, we overload eval, for example:

def eval(values,x):
values[0] = sin(x[0])*cos(x[2])

To be able to hand 'eval' a numpy.array with the right dimension we have used 
Function::geometric_dimension(). 

This is all done in the 

  %typemap(directorin) double* x {

typemap. Any equivalent function will do.

Johan 

 changeset:   6763:d8a5d0cb18a467039fd1da48363d5ac68ece917c
 parent:  6762:ca407204632a1b0430099c243c915a151b2bd941
 parent:  6761:f936b2842d23b5d0910081001ea16e23eed375a2
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 19:09:05 2009 +0200
 files:
 description:
 merge

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Monday 17 August 2009 22:46:52 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6772:51528af1906a38b3827848f70488381ce425767f
 tag: tip
 parent:  6771:85ed50477f156d01ef91f9e2a5b25d6db31cefef
 parent:  6770:6e6853794f50445131ed68bf42fa7512eb6dfc12
 user:Johan Hake h...@simula.no
 date:Mon Aug 17 22:46:44 2009 +0200
 files:
 description:
 merge


 changeset:   6771:85ed50477f156d01ef91f9e2a5b25d6db31cefef
 parent:  6769:ddab144e5a88ce577f083c29969a5bccfc6b83f3
 user:Johan Hake h...@simula.no
 date:Mon Aug 17 22:46:01 2009 +0200
 files:   site-packages/dolfin/__init__.py
 site-packages/dolfin/compile_extension_module.py
 site-packages/dolfin/compile_function.py
 site-packages/dolfin/compile_functions.py
 site-packages/dolfin/compile_subdomains.py site-packages/dolfin/function.py
 description:
 Added a compile_extension_module function to PyDOLFIN.

   - It provides somewhat generic JIT compilation of C++ DOLFIN code
 for PyDOLFIN

The syntax for this function is simplistic. It takes a C++ code block that is 
defined within a dolfin namespace {...}, puts it into a proper SWIG interface 
file, add appropriate declarations, like shared_ptr declarations, and compiles 
the module. It needs documentation. However a simple example could be 
something like:

  compiled_module = compile_extension_module(code,
 
dolfin_import_files=[mesh/SubDomain.h,function/Function.h])

where code is a C++ code block, and dolfin_import_files are optionals. 
Including them will reduce the compilation time.

I know Garth asked for something like this. It would be nice if you could 
provide some code that I can throw at it.

If nothing comes out of this, I have at least reused alot of code in the 
compile_{functions,subdomains} functions :)

Johan


   - The function returns the compiled extension module
   - Both compile_functions and compile_subdomains use it
   - Needs some more work on numpy typemaps.
   - removed old compile_function file
   - compile_subdomains need some more love, but it is featurewise
 compatible with the old compile_subdomains


 changeset:   6770:6e6853794f50445131ed68bf42fa7512eb6dfc12
 user:Anders Logg l...@simula.no
 date:Mon Aug 17 22:42:45 2009 +0200
 files:   site-packages/dolfin/utils.py
 description:
 Move getoutput and getstatusoutput to dolfin.utils. To be reused in
 testing framework.

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Mon, Aug 17, 2009 at 10:54:36PM +0200, Johan Hake wrote:
 On Monday 17 August 2009 22:46:52 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6772:51528af1906a38b3827848f70488381ce425767f
  tag: tip
  parent:  6771:85ed50477f156d01ef91f9e2a5b25d6db31cefef
  parent:  6770:6e6853794f50445131ed68bf42fa7512eb6dfc12
  user:Johan Hake h...@simula.no
  date:Mon Aug 17 22:46:44 2009 +0200
  files:
  description:
  merge
 
 
  changeset:   6771:85ed50477f156d01ef91f9e2a5b25d6db31cefef
  parent:  6769:ddab144e5a88ce577f083c29969a5bccfc6b83f3
  user:Johan Hake h...@simula.no
  date:Mon Aug 17 22:46:01 2009 +0200
  files:   site-packages/dolfin/__init__.py
  site-packages/dolfin/compile_extension_module.py
  site-packages/dolfin/compile_function.py
  site-packages/dolfin/compile_functions.py
  site-packages/dolfin/compile_subdomains.py site-packages/dolfin/function.py
  description:
  Added a compile_extension_module function to PyDOLFIN.
 
- It provides somewhat generic JIT compilation of C++ DOLFIN code
  for PyDOLFIN

 The syntax for this function is simplistic. It takes a C++ code block that is
 defined within a dolfin namespace {...}, puts it into a proper SWIG interface
 file, add appropriate declarations, like shared_ptr declarations, and compiles
 the module. It needs documentation. However a simple example could be
 something like:

   compiled_module = compile_extension_module(code,
  
 dolfin_import_files=[mesh/SubDomain.h,function/Function.h])

 where code is a C++ code block, and dolfin_import_files are optionals.
 Including them will reduce the compilation time.

 I know Garth asked for something like this. It would be nice if you could
 provide some code that I can throw at it.

 If nothing comes out of this, I have at least reused alot of code in the
 compile_{functions,subdomains} functions :)

Very nice!

--
Anders


 Johan


- The function returns the compiled extension module
- Both compile_functions and compile_subdomains use it
- Needs some more work on numpy typemaps.
- removed old compile_function file
- compile_subdomains need some more love, but it is featurewise
  compatible with the old compile_subdomains
 
 
  changeset:   6770:6e6853794f50445131ed68bf42fa7512eb6dfc12
  user:Anders Logg l...@simula.no
  date:Mon Aug 17 22:42:45 2009 +0200
  files:   site-packages/dolfin/utils.py
  description:
  Move getoutput and getstatusoutput to dolfin.utils. To be reused in
  testing framework.
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Monday 17 August 2009 19:19:40 Anders Logg wrote:
 On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
  changeset:   6762:ca407204632a1b0430099c243c915a151b2bd941
  parent:  6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
  user:Anders Logg l...@simula.no
  date:Mon Aug 17 19:08:56 2009 +0200
  files:   site-packages/dolfin/compile_function.py
  site-packages/dolfin/jit.py description:
  Make JIT compiler work in parallel. The process number is added to the
  signature to create a unique signature for each process. This means that
  each process will compile its own form. This may not be optimal and could
  possibly be handled by Instant. On the other hand, it seems to work
  nicely and might also be advantageous when processes don't share a common
  cache.

 The Poisson Python demo now runs as is without the need for first
 running it in serial (to handle JIT compilation):

Did it not work before this change? I know Martin added some file locks to 
prevent simultaneous compilations of the same module.

   mpirun -n 4 python demo.py

Do I have to set some environmental variables to make this work. I can't get 
it to work (probably some stupid error) :P

Johan

When running the above command I get:

ssh: connect to host hake-laptop port 22: Connection refused
--
A daemon (pid 32065) died unexpectedly with status 255 while attempting
to launch so we are aborting.

There may be more information reported by the environment (see above).

This may be because the daemon was unable to find all the needed shared
libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
location of the shared libraries on the remote nodes and this will
automatically be forwarded to the remote nodes.
--
--
mpirun noticed that the job aborted, but has no info as to the process
that caused that situation.
--
mpirun: clean termination accomplished



___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Mon, Aug 17, 2009 at 11:20:08PM +0200, Johan Hake wrote:
On Monday 17 August 2009 19:19:40 Anders Logg wrote:
On Mon, Aug 17, 2009 at 07:09:11PM +0200, DOLFIN wrote:
changeset: 6762:ca407204632a1b0430099c243c915a151b2bd941
parent: 6759:efc24a341e41e9e0c83616be4613d819fe95ccb6
user:Anders Logg l...@simula.no
date:Mon Aug 17 19:08:56 2009 +0200
files: site-packages/dolfin/compile_function.py
site-packages/dolfin/jit.py description:
Make JIT compiler work in parallel. The process number is added to the
signature to create a unique signature for each process. This means that
each process will compile its own form. This may not be optimal and could
possibly be handled by Instant. On the other hand, it seems to work
nicely and might also be advantageous when processes don't share a common
cache.

The Poisson Python demo now runs as is without the need for first
running it in serial (to handle JIT compilation):

Did it not work before this change? I know Martin added some file locks to
prevent simultaneous compilations of the same module.

No, it didn't work before. I get things like

/home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-packages/dolfin/functionspace.py,
line 181, in __init__
FunctionSpaceBase.__init__(self, mesh, element)
File

/home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-packages/dolfin/functionspace.py,
line 43, in __init__
ufc_element, ufc_dofmap = jit(self._element)
File

/home/logg/scratch/src/fenics-dev/dolfin-dev/local/lib/python2.6/site-packages/dolfin/jit.py,
line 67, in jit
return jit_compile(form, options)
File

/home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.py,
line 56, in jit
return jit_element(object, options)
File

/home/logg/scratch/lib/fenics-dev/lib/python2.6/site-packages/ffc/jit/jit.py,
line 125, in jit_element
(compiled_form, module, form_data) = jit_form(form, options)
File

I guess the second process tries to read the generated file but
it's not ready yet (still being generated by the first process).

It would be good to handle the parallel JIT compilation as part of
Instant, but I don't know what the best solution is.

mpirun -n 4 python demo.py

Do I have to set some environmental variables to make this work. I can't get
it to work (probably some stupid error) :P

No, nothing. It should work out of the box.

Johan

When running the above command I get:

ssh: connect to host hake-laptop port 22: Connection refused

Can you run other processes in parallel?

mpirun -n 4 ls

Maybe you need to install sshd? I didn't know it was required.

--
Anders

--
A daemon (pid 32065) died unexpectedly with status 255 while attempting
to launch so we are aborting.

There may be more information reported by the environment (see above).

This may be because the daemon was unable to find all the needed shared
libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
location of the shared libraries on the remote nodes and this will
automatically be forwarded to the remote nodes.
--
--
mpirun noticed that the job aborted, but has no info as to the process
that caused that situation.
--
mpirun: clean termination accomplished

signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-08-16 Thread Johan Hake

On Monday 17 August 2009 00:15:28 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6745:da5a4b553da51ac48886f2eecc9b1b0c297cb2ed
 tag: tip
 parent:  6741:309099b6f2b71a79b7a3e83bc0dab6b23ba1dfc7
 parent:  6744:58993bc573026e876c6f27fc9d6c90fae725fbfa
 user:Garth N. Wells gn...@cam.ac.uk
 date:Sun Aug 16 23:15:13 2009 +0100
 files:   dolfin/fem/DirichletBC.cpp dolfin/fem/EqualityBC.cpp
 dolfin/fem/PeriodicBC.cpp description:
 merge.
 changeset:   6744:58993bc573026e876c6f27fc9d6c90fae725fbfa
 user:Garth N. Wells gn...@cam.ac.uk
 date:Sun Aug 16 23:12:32 2009 +0100
 files:   dolfin/fem/DofMap.cpp
 description:
 Try to fix merge. Things got really screwed up.

Urk...

I was a bit worried about this, but I thought we had been working on unrelated 
stuff.

Johan


 changeset:   6743:79a47b328440ae1afe1c5dd167bf42298086cb40
 parent:  6738:e381c289970f30355bdf76c4a76f509047599edb
 parent:  6742:aea5800a083cd7a38abc13e50c79e63dc4312087
 user:Garth N. Wells gn...@cam.ac.uk
 date:Sun Aug 16 23:02:32 2009 +0100
 files:   dolfin/fem/DofMap.cpp dolfin/function/Function.cpp
 description:
 merge.

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-08-16 Thread Garth N. Wells



Johan Hake wrote:
 On Monday 17 August 2009 00:15:28 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6745:da5a4b553da51ac48886f2eecc9b1b0c297cb2ed
 tag: tip
 parent:  6741:309099b6f2b71a79b7a3e83bc0dab6b23ba1dfc7
 parent:  6744:58993bc573026e876c6f27fc9d6c90fae725fbfa
 user:Garth N. Wells gn...@cam.ac.uk
 date:Sun Aug 16 23:15:13 2009 +0100
 files:   dolfin/fem/DirichletBC.cpp dolfin/fem/EqualityBC.cpp
 dolfin/fem/PeriodicBC.cpp description:
 merge.
 changeset:   6744:58993bc573026e876c6f27fc9d6c90fae725fbfa
 user:Garth N. Wells gn...@cam.ac.uk
 date:Sun Aug 16 23:12:32 2009 +0100
 files:   dolfin/fem/DofMap.cpp
 description:
 Try to fix merge. Things got really screwed up.
 
 Urk...
 
 I was a bit worried about this, but I thought we had been working on 
 unrelated 
 stuff.
 

Not your fault - Anders couldn't resist his cleaning impulses ;).

Garth

 Johan
 
 changeset:   6743:79a47b328440ae1afe1c5dd167bf42298086cb40
 parent:  6738:e381c289970f30355bdf76c4a76f509047599edb
 parent:  6742:aea5800a083cd7a38abc13e50c79e63dc4312087
 user:Garth N. Wells gn...@cam.ac.uk
 date:Sun Aug 16 23:02:32 2009 +0100
 files:   dolfin/fem/DofMap.cpp dolfin/function/Function.cpp
 description:
 merge.

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-08-16 Thread Johan Hake

On Monday 17 August 2009 00:31:22 Garth N. Wells wrote:
 Johan Hake wrote:
  On Monday 17 August 2009 00:15:28 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6745:da5a4b553da51ac48886f2eecc9b1b0c297cb2ed
  tag: tip
  parent:  6741:309099b6f2b71a79b7a3e83bc0dab6b23ba1dfc7
  parent:  6744:58993bc573026e876c6f27fc9d6c90fae725fbfa
  user:Garth N. Wells gn...@cam.ac.uk
  date:Sun Aug 16 23:15:13 2009 +0100
  files:   dolfin/fem/DirichletBC.cpp dolfin/fem/EqualityBC.cpp
  dolfin/fem/PeriodicBC.cpp description:
  merge.
  changeset:   6744:58993bc573026e876c6f27fc9d6c90fae725fbfa
  user:Garth N. Wells gn...@cam.ac.uk
  date:Sun Aug 16 23:12:32 2009 +0100
  files:   dolfin/fem/DofMap.cpp
  description:
  Try to fix merge. Things got really screwed up.
 
  Urk...
 
  I was a bit worried about this, but I thought we had been working on
  unrelated stuff.

 Not your fault - Anders couldn't resist his cleaning impulses ;).

Ok!

Johan

 Garth

  Johan
 
  changeset:   6743:79a47b328440ae1afe1c5dd167bf42298086cb40
  parent:  6738:e381c289970f30355bdf76c4a76f509047599edb
  parent:  6742:aea5800a083cd7a38abc13e50c79e63dc4312087
  user:Garth N. Wells gn...@cam.ac.uk
  date:Sun Aug 16 23:02:32 2009 +0100
  files:   dolfin/fem/DofMap.cpp dolfin/function/Function.cpp
  description:
  merge.
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-08-16 Thread Anders Logg

On Sun, Aug 16, 2009 at 11:31:22PM +0100, Garth N. Wells wrote:


 Johan Hake wrote:
  On Monday 17 August 2009 00:15:28 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6745:da5a4b553da51ac48886f2eecc9b1b0c297cb2ed
  tag: tip
  parent:  6741:309099b6f2b71a79b7a3e83bc0dab6b23ba1dfc7
  parent:  6744:58993bc573026e876c6f27fc9d6c90fae725fbfa
  user:Garth N. Wells gn...@cam.ac.uk
  date:Sun Aug 16 23:15:13 2009 +0100
  files:   dolfin/fem/DirichletBC.cpp dolfin/fem/EqualityBC.cpp
  dolfin/fem/PeriodicBC.cpp description:
  merge.
  changeset:   6744:58993bc573026e876c6f27fc9d6c90fae725fbfa
  user:Garth N. Wells gn...@cam.ac.uk
  date:Sun Aug 16 23:12:32 2009 +0100
  files:   dolfin/fem/DofMap.cpp
  description:
  Try to fix merge. Things got really screwed up.
 
  Urk...
 
  I was a bit worried about this, but I thought we had been working on 
  unrelated
  stuff.
 

 Not your fault - Anders couldn't resist his cleaning impulses ;).

Sorry, I pushed before I read about you going to push more.

--
Anders


 Garth

  Johan
 
  changeset:   6743:79a47b328440ae1afe1c5dd167bf42298086cb40
  parent:  6738:e381c289970f30355bdf76c4a76f509047599edb
  parent:  6742:aea5800a083cd7a38abc13e50c79e63dc4312087
  user:Garth N. Wells gn...@cam.ac.uk
  date:Sun Aug 16 23:02:32 2009 +0100
  files:   dolfin/fem/DofMap.cpp dolfin/function/Function.cpp
  description:
  merge.
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev


 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-12 Thread Johan Hake

On Tuesday 11 August 2009 10:38:46 pm Garth N. Wells wrote:
 Johan Hake wrote:
  changeset:   6696:67e3c3b2a01acecc8409fd9814e36611b1a69459
  user:Johan Hake h...@simula.no
  date:Tue Aug 11 13:11:09 2009 +0200
  files:   dolfin/la/PETScKrylovSolver.cpp
  description:
  merge
 
  This deserves a better message than merge
 
A small code cleanup for assignment of a new shared_ptrKSP

 This is much nicer. There are probably a number of other places where it
 should be used.

Probably, I fixed it a while ago when looking at some memory leaks in that 
file, 
and then forgot to push it :P

Johan

 Garth

  Johan
 
  changeset:   6695:08ef7f0fcf81fcceddde8c5543c4a7f2d1468c0f
  user:Johan Hake h...@simula.no
  date:Tue Aug 11 13:10:30 2009 +0200
  files:   dolfin/swig/dolfin_function_post.i
  site-packages/dolfin/compile_function.py description:
  Reduced the amount of SWIG generated wrapper code while JIT compiling a
  function - We now only %import the relevant types for wrapping a
  dolfin::Function
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-11 Thread Johan Hake

On Tuesday 11 August 2009 13:11:55 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6697:2bced4da2b4d695dd87c9e46b07efd1a84433cbb
 tag: tip
 parent:  6696:67e3c3b2a01acecc8409fd9814e36611b1a69459
 parent:  6693:82d0f09e74f8f7996faeaa09042ba2dc52e25e71
 user:Johan Hake h...@simula.no
 date:Tue Aug 11 13:11:46 2009 +0200
 files:
 description:
 merge


 changeset:   6696:67e3c3b2a01acecc8409fd9814e36611b1a69459
 user:Johan Hake h...@simula.no
 date:Tue Aug 11 13:11:09 2009 +0200
 files:   dolfin/la/PETScKrylovSolver.cpp
 description:
 merge

This deserves a better message than merge

  A small code cleanup for assignment of a new shared_ptrKSP

Johan


 changeset:   6695:08ef7f0fcf81fcceddde8c5543c4a7f2d1468c0f
 user:Johan Hake h...@simula.no
 date:Tue Aug 11 13:10:30 2009 +0200
 files:   dolfin/swig/dolfin_function_post.i
 site-packages/dolfin/compile_function.py description:
 Reduced the amount of SWIG generated wrapper code while JIT compiling a
 function - We now only %import the relevant types for wrapping a
 dolfin::Function

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

2009-08-11 Thread Garth N. Wells



Johan Hake wrote:

 changeset:   6696:67e3c3b2a01acecc8409fd9814e36611b1a69459
 user:Johan Hake h...@simula.no
 date:Tue Aug 11 13:11:09 2009 +0200
 files:   dolfin/la/PETScKrylovSolver.cpp
 description:
 merge
 
 This deserves a better message than merge
 
   A small code cleanup for assignment of a new shared_ptrKSP


This is much nicer. There are probably a number of other places where it 
should be used.

Garth


 Johan
 
 changeset:   6695:08ef7f0fcf81fcceddde8c5543c4a7f2d1468c0f
 user:Johan Hake h...@simula.no
 date:Tue Aug 11 13:10:30 2009 +0200
 files:   dolfin/swig/dolfin_function_post.i
 site-packages/dolfin/compile_function.py description:
 Reduced the amount of SWIG generated wrapper code while JIT compiling a
 function - We now only %import the relevant types for wrapping a
 dolfin::Function

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-07-08 Thread Johan Hake

On Wednesday 08 July 2009 12:53:18 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6449:c1849c5f9e724cb4c44f8ed5524fd197fdc50c82
 tag: tip
 parent:  6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
 parent:  6448:8d67617c807120e17d580cad78ab6658891c13b4
 user:Garth N. Wells gn...@cam.ac.uk
 date:Wed Jul 08 11:53:12 2009 +0100
 files:
 description:
 merge.


 changeset:   6448:8d67617c807120e17d580cad78ab6658891c13b4
 parent:  6446:7de811329be29b60aeb9b0f8ca2d5c6a07245668
 user:Garth N. Wells gn...@cam.ac.uk
 date:Wed Jul 08 11:52:18 2009 +0100
 files:   dolfin/la/PETScKrylovSolver.cpp
 dolfin/la/uBLASKrylovSolver.cpp dolfin/parameter/Parameters.cpp
 dolfin/parameter/Parameters.h description:
 Add Parameters::set_key(std::string) to change name of a parameter set.

 e.g.

   Parameters uBLASKrylovSolver::default_parameters()
   {
 Parameters p(KrylovSolver::default_parameters());
 p.set_key(ublas_krylov_solver);
 return p;
   }

Would set_name be a better name? set_key makes me think of the key to a 
parameter, instead of the name of the parameter set.

Johan


 changeset:   6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
 user:Johan Hake h...@simula.no
 date:Wed Jul 08 11:44:07 2009 +0200
 files:   SConstruct
 description:
 Changed PathVariable.PathIsDirCreate to PathVariable.PathAccept

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-07-08 Thread Garth N. Wells



Johan Hake wrote:
 On Wednesday 08 July 2009 12:53:18 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6449:c1849c5f9e724cb4c44f8ed5524fd197fdc50c82
 tag: tip
 parent:  6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
 parent:  6448:8d67617c807120e17d580cad78ab6658891c13b4
 user:Garth N. Wells gn...@cam.ac.uk
 date:Wed Jul 08 11:53:12 2009 +0100
 files:
 description:
 merge.


 changeset:   6448:8d67617c807120e17d580cad78ab6658891c13b4
 parent:  6446:7de811329be29b60aeb9b0f8ca2d5c6a07245668
 user:Garth N. Wells gn...@cam.ac.uk
 date:Wed Jul 08 11:52:18 2009 +0100
 files:   dolfin/la/PETScKrylovSolver.cpp
 dolfin/la/uBLASKrylovSolver.cpp dolfin/parameter/Parameters.cpp
 dolfin/parameter/Parameters.h description:
 Add Parameters::set_key(std::string) to change name of a parameter set.

 e.g.

   Parameters uBLASKrylovSolver::default_parameters()
   {
 Parameters p(KrylovSolver::default_parameters());
 p.set_key(ublas_krylov_solver);
 return p;
   }
 
 Would set_name be a better name? set_key makes me think of the key to a 
 parameter, instead of the name of the parameter set.
 

I used 'set_key' in the end since 'key' is  used elsewhere. The thing is 
that in the context of nested parameters sets, the name is a key (key 
for a set).

Garth

 Johan
 
 changeset:   6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
 user:Johan Hake h...@simula.no
 date:Wed Jul 08 11:44:07 2009 +0200
 files:   SConstruct
 description:
 Changed PathVariable.PathIsDirCreate to PathVariable.PathAccept

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-07-08 Thread Johan Hake

On Wednesday 08 July 2009 13:11:41 Garth N. Wells wrote:
 Johan Hake wrote:
  On Wednesday 08 July 2009 12:53:18 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6449:c1849c5f9e724cb4c44f8ed5524fd197fdc50c82
  tag: tip
  parent:  6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
  parent:  6448:8d67617c807120e17d580cad78ab6658891c13b4
  user:Garth N. Wells gn...@cam.ac.uk
  date:Wed Jul 08 11:53:12 2009 +0100
  files:
  description:
  merge.
 
 
  changeset:   6448:8d67617c807120e17d580cad78ab6658891c13b4
  parent:  6446:7de811329be29b60aeb9b0f8ca2d5c6a07245668
  user:Garth N. Wells gn...@cam.ac.uk
  date:Wed Jul 08 11:52:18 2009 +0100
  files:   dolfin/la/PETScKrylovSolver.cpp
  dolfin/la/uBLASKrylovSolver.cpp dolfin/parameter/Parameters.cpp
  dolfin/parameter/Parameters.h description:
  Add Parameters::set_key(std::string) to change name of a parameter set.
 
  e.g.
 
Parameters uBLASKrylovSolver::default_parameters()
{
  Parameters p(KrylovSolver::default_parameters());
  p.set_key(ublas_krylov_solver);
  return p;
}
 
  Would set_name be a better name? set_key makes me think of the key to a
  parameter, instead of the name of the parameter set.

 I used 'set_key' in the end since 'key' is  used elsewhere. The thing is
 that in the context of nested parameters sets, the name is a key (key
 for a set).

See your point. But when you change the key it really is a name of the 
parameters set you change. It is not a key until you put it into another 
parameters set.

Johan

 Garth

  Johan
 
  changeset:   6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
  user:Johan Hake h...@simula.no
  date:Wed Jul 08 11:44:07 2009 +0200
  files:   SConstruct
  description:
  Changed PathVariable.PathIsDirCreate to PathVariable.PathAccept
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-07-08 Thread Garth N. Wells



Johan Hake wrote:
 On Wednesday 08 July 2009 13:11:41 Garth N. Wells wrote:
 Johan Hake wrote:
 On Wednesday 08 July 2009 12:53:18 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6449:c1849c5f9e724cb4c44f8ed5524fd197fdc50c82
 tag: tip
 parent:  6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
 parent:  6448:8d67617c807120e17d580cad78ab6658891c13b4
 user:Garth N. Wells gn...@cam.ac.uk
 date:Wed Jul 08 11:53:12 2009 +0100
 files:
 description:
 merge.


 changeset:   6448:8d67617c807120e17d580cad78ab6658891c13b4
 parent:  6446:7de811329be29b60aeb9b0f8ca2d5c6a07245668
 user:Garth N. Wells gn...@cam.ac.uk
 date:Wed Jul 08 11:52:18 2009 +0100
 files:   dolfin/la/PETScKrylovSolver.cpp
 dolfin/la/uBLASKrylovSolver.cpp dolfin/parameter/Parameters.cpp
 dolfin/parameter/Parameters.h description:
 Add Parameters::set_key(std::string) to change name of a parameter set.

 e.g.

   Parameters uBLASKrylovSolver::default_parameters()
   {
 Parameters p(KrylovSolver::default_parameters());
 p.set_key(ublas_krylov_solver);
 return p;
   }
 Would set_name be a better name? set_key makes me think of the key to a
 parameter, instead of the name of the parameter set.
 I used 'set_key' in the end since 'key' is  used elsewhere. The thing is
 that in the context of nested parameters sets, the name is a key (key
 for a set).
 
 See your point. But when you change the key it really is a name of the 
 parameters set you change. It is not a key until you put it into another 
 parameters set.


I'm not fixed on a name, but for consistency we should have either

   std::string key() const;
   void set_key(std::string);

(which we have now) or

   std::string name() const;
   void set_name(std::string);

Garth

 Johan
 
 Garth

 Johan

 changeset:   6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
 user:Johan Hake h...@simula.no
 date:Wed Jul 08 11:44:07 2009 +0200
 files:   SConstruct
 description:
 Changed PathVariable.PathIsDirCreate to PathVariable.PathAccept

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-07-08 Thread Johan Hake

On Wednesday 08 July 2009 13:20:38 Garth N. Wells wrote:
 Johan Hake wrote:
  On Wednesday 08 July 2009 13:11:41 Garth N. Wells wrote:
  Johan Hake wrote:
  On Wednesday 08 July 2009 12:53:18 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6449:c1849c5f9e724cb4c44f8ed5524fd197fdc50c82
  tag: tip
  parent:  6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
  parent:  6448:8d67617c807120e17d580cad78ab6658891c13b4
  user:Garth N. Wells gn...@cam.ac.uk
  date:Wed Jul 08 11:53:12 2009 +0100
  files:
  description:
  merge.
 
 
  changeset:   6448:8d67617c807120e17d580cad78ab6658891c13b4
  parent:  6446:7de811329be29b60aeb9b0f8ca2d5c6a07245668
  user:Garth N. Wells gn...@cam.ac.uk
  date:Wed Jul 08 11:52:18 2009 +0100
  files:   dolfin/la/PETScKrylovSolver.cpp
  dolfin/la/uBLASKrylovSolver.cpp dolfin/parameter/Parameters.cpp
  dolfin/parameter/Parameters.h description:
  Add Parameters::set_key(std::string) to change name of a parameter
  set.
 
  e.g.
 
Parameters uBLASKrylovSolver::default_parameters()
{
  Parameters p(KrylovSolver::default_parameters());
  p.set_key(ublas_krylov_solver);
  return p;
}
 
  Would set_name be a better name? set_key makes me think of the key to a
  parameter, instead of the name of the parameter set.
 
  I used 'set_key' in the end since 'key' is  used elsewhere. The thing is
  that in the context of nested parameters sets, the name is a key (key
  for a set).
 
  See your point. But when you change the key it really is a name of the
  parameters set you change. It is not a key until you put it into another
  parameters set.

 I'm not fixed on a name, but for consistency we should have either

std::string key() const;
void set_key(std::string);

 (which we have now) or

std::string name() const;
void set_name(std::string);

Make sense. I think I go for the latter.

Anders?

Johan

 Garth

  Johan
 
  Garth
 
  Johan
 
  changeset:   6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
  user:Johan Hake h...@simula.no
  date:Wed Jul 08 11:44:07 2009 +0200
  files:   SConstruct
  description:
  Changed PathVariable.PathIsDirCreate to PathVariable.PathAccept
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge.

2009-07-08 Thread Anders Logg

On Wed, Jul 08, 2009 at 01:29:39PM +0200, Johan Hake wrote:
 On Wednesday 08 July 2009 13:20:38 Garth N. Wells wrote:
  Johan Hake wrote:
   On Wednesday 08 July 2009 13:11:41 Garth N. Wells wrote:
   Johan Hake wrote:
   On Wednesday 08 July 2009 12:53:18 DOLFIN wrote:
   One or more new changesets pushed to the primary dolfin repository.
   A short summary of the last three changesets is included below.
  
   changeset:   6449:c1849c5f9e724cb4c44f8ed5524fd197fdc50c82
   tag: tip
   parent:  6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
   parent:  6448:8d67617c807120e17d580cad78ab6658891c13b4
   user:Garth N. Wells gn...@cam.ac.uk
   date:Wed Jul 08 11:53:12 2009 +0100
   files:
   description:
   merge.
  
  
   changeset:   6448:8d67617c807120e17d580cad78ab6658891c13b4
   parent:  6446:7de811329be29b60aeb9b0f8ca2d5c6a07245668
   user:Garth N. Wells gn...@cam.ac.uk
   date:Wed Jul 08 11:52:18 2009 +0100
   files:   dolfin/la/PETScKrylovSolver.cpp
   dolfin/la/uBLASKrylovSolver.cpp dolfin/parameter/Parameters.cpp
   dolfin/parameter/Parameters.h description:
   Add Parameters::set_key(std::string) to change name of a parameter
   set.
  
   e.g.
  
 Parameters uBLASKrylovSolver::default_parameters()
 {
   Parameters p(KrylovSolver::default_parameters());
   p.set_key(ublas_krylov_solver);
   return p;
 }
  
   Would set_name be a better name? set_key makes me think of the key to a
   parameter, instead of the name of the parameter set.
  
   I used 'set_key' in the end since 'key' is  used elsewhere. The thing is
   that in the context of nested parameters sets, the name is a key (key
   for a set).
  
   See your point. But when you change the key it really is a name of the
   parameters set you change. It is not a key until you put it into another
   parameters set.
 
  I'm not fixed on a name, but for consistency we should have either
 
 std::string key() const;
 void set_key(std::string);
 
  (which we have now) or
 
 std::string name() const;
 void set_name(std::string);
 
 Make sense. I think I go for the latter.
 
 Anders?

ok.

-- 
Anders


 Johan
 
  Garth
 
   Johan
  
   Garth
  
   Johan
  
   changeset:   6447:ddb4cb628653d60fb0899b17a987bdc3e67d21ee
   user:Johan Hake h...@simula.no
   date:Wed Jul 08 11:44:07 2009 +0200
   files:   SConstruct
   description:
   Changed PathVariable.PathIsDirCreate to PathVariable.PathAccept
  
   --
   For more details, visit http://www.fenics.org/hg/dolfin
   ___
   DOLFIN-dev mailing list
   DOLFIN-dev@fenics.org
   http://www.fenics.org/mailman/listinfo/dolfin-dev
  
   ___
   DOLFIN-dev mailing list
   DOLFIN-dev@fenics.org
   http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Sunday 05 July 2009 22:41:40 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6420:920786635f4ec37a05fe3752d0701d9cf472f125
 tag: tip
 parent:  6419:8d098ee6533779a969591119a1073fc1c59d12fd
 parent:  6418:af869a96c99f563c7fe8a49322033a168aea5d89
 user:Anders Logg l...@simula.no
 date:Sun Jul 05 22:41:35 2009 +0200
 files:
 description:
 merge


 changeset:   6419:8d098ee6533779a969591119a1073fc1c59d12fd
 parent:  6416:e645d3295afb8732b2186e4fc62d026a48c6fb55
 user:Anders Logg l...@simula.no
 date:Sun Jul 05 22:40:47 2009 +0200
 files:   demo/la/eigensolver/cpp/main.cpp
 demo/ode/harmonic/cpp/main_solvedual.cpp demo/ode/stiff/cpp/main.cpp
 demo/pde/cahn-hilliard/cpp/main.cpp demo/pde/dg/biharmonic/cpp/main.cpp
 demo/pde/dg/poisson/cpp/main.cpp dolfin/common/Timer.h
 dolfin/io/GenericFile.cpp dolfin/io/GenericFile.h dolfin/io/XMLFile.h
 dolfin/io/XMLParameterList.cpp dolfin/io/XMLParameterList.h
 dolfin/io/XMLParameters.cpp dolfin/io/XMLParameters.h
 dolfin/la/DefaultFactory.cpp dolfin/la/EpetraPreconditioner.h
 dolfin/la/SLEPcEigenSolver.h dolfin/la/uBLASPreconditioner.h
 dolfin/mesh/Mesh.h dolfin/ode/Adaptivity.cpp dolfin/ode/Dependencies.cpp
 dolfin/ode/GMPObject.h dolfin/ode/MonoAdaptiveFixedPointSolver.cpp
 dolfin/ode/MonoAdaptiveNewtonSolver.cpp dolfin/ode/MonoAdaptiveTimeSlab.cpp
 dolfin/ode/MonoAdaptivity.cpp dolfin/ode/MultiAdaptiveFixedPointSolver.cpp
 dolfin/ode/MultiAdaptiveNewtonSolver.cpp
 dolfin/ode/MultiAdaptiveTimeSlab.cpp dolfin/ode/MultiAdaptivity.cpp
 dolfin/ode/ODE.cpp dolfin/ode/ODESolution.cpp dolfin/ode/ODESolver.cpp
 dolfin/ode/Partition.cpp dolfin/ode/TimeSlab.cpp dolfin/ode/TimeSlab.h
 dolfin/ode/TimeSlabSolver.cpp dolfin/ode/TimeStepper.cpp
 dolfin/parameter/DefaultParameters.h dolfin/parameter/NewParameters.cpp
 dolfin/parameter/NewParameters.h dolfin/parameter/Parameter.cpp
 dolfin/parameter/Parameter.h dolfin/parameter/ParameterList.cpp
 dolfin/parameter/ParameterList.h dolfin/parameter/ParameterSystem.cpp
 dolfin/parameter/ParameterSystem.h dolfin/parameter/ParameterValue.cpp
 dolfin/parameter/ParameterValue.h dolfin/parameter/Parametrized.cpp
 dolfin/parameter/Parametrized.h dolfin/parameter/dolfin_parameter.h
 dolfin/parameter/parameters.cpp dolfin/parameter/parameters.h
 dolfin/plot/plot.cpp dolfin/swig/dolfin_docstrings.i
 dolfin/swig/dolfin_function_post.i dolfin/swig/dolfin_headers.i
 dolfin/swig/dolfin_io_post.i description:
 Remove old parameter system, including dolfin_get, dolfin_set
 and use new global parameters everywhere. Python untested and
 probably needs work.

Did you forget to commit SLEPcEigenSolver.cpp?

Johan


 changeset:   6418:af869a96c99f563c7fe8a49322033a168aea5d89
 user:Johan Hake h...@simula.no
 date:Sun Jul 05 21:57:08 2009 +0200
 files:   SConstruct scons/simula-scons/simula_scons/__init__.py
 description:
 Removed the deprication warnings in SCons.
 Also moved scons.PathOption to the new PathVariable.

 --
 For more details, visit http://www.fenics.org/hg/dolfin
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Sun, Jul 05, 2009 at 10:59:21PM +0200, Johan Hake wrote:
 On Sunday 05 July 2009 22:41:40 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6420:920786635f4ec37a05fe3752d0701d9cf472f125
  tag: tip
  parent:  6419:8d098ee6533779a969591119a1073fc1c59d12fd
  parent:  6418:af869a96c99f563c7fe8a49322033a168aea5d89
  user:Anders Logg l...@simula.no
  date:Sun Jul 05 22:41:35 2009 +0200
  files:
  description:
  merge
 
 
  changeset:   6419:8d098ee6533779a969591119a1073fc1c59d12fd
  parent:  6416:e645d3295afb8732b2186e4fc62d026a48c6fb55
  user:Anders Logg l...@simula.no
  date:Sun Jul 05 22:40:47 2009 +0200
  files:   demo/la/eigensolver/cpp/main.cpp
  demo/ode/harmonic/cpp/main_solvedual.cpp demo/ode/stiff/cpp/main.cpp
  demo/pde/cahn-hilliard/cpp/main.cpp demo/pde/dg/biharmonic/cpp/main.cpp
  demo/pde/dg/poisson/cpp/main.cpp dolfin/common/Timer.h
  dolfin/io/GenericFile.cpp dolfin/io/GenericFile.h dolfin/io/XMLFile.h
  dolfin/io/XMLParameterList.cpp dolfin/io/XMLParameterList.h
  dolfin/io/XMLParameters.cpp dolfin/io/XMLParameters.h
  dolfin/la/DefaultFactory.cpp dolfin/la/EpetraPreconditioner.h
  dolfin/la/SLEPcEigenSolver.h dolfin/la/uBLASPreconditioner.h
  dolfin/mesh/Mesh.h dolfin/ode/Adaptivity.cpp dolfin/ode/Dependencies.cpp
  dolfin/ode/GMPObject.h dolfin/ode/MonoAdaptiveFixedPointSolver.cpp
  dolfin/ode/MonoAdaptiveNewtonSolver.cpp dolfin/ode/MonoAdaptiveTimeSlab.cpp
  dolfin/ode/MonoAdaptivity.cpp dolfin/ode/MultiAdaptiveFixedPointSolver.cpp
  dolfin/ode/MultiAdaptiveNewtonSolver.cpp
  dolfin/ode/MultiAdaptiveTimeSlab.cpp dolfin/ode/MultiAdaptivity.cpp
  dolfin/ode/ODE.cpp dolfin/ode/ODESolution.cpp dolfin/ode/ODESolver.cpp
  dolfin/ode/Partition.cpp dolfin/ode/TimeSlab.cpp dolfin/ode/TimeSlab.h
  dolfin/ode/TimeSlabSolver.cpp dolfin/ode/TimeStepper.cpp
  dolfin/parameter/DefaultParameters.h dolfin/parameter/NewParameters.cpp
  dolfin/parameter/NewParameters.h dolfin/parameter/Parameter.cpp
  dolfin/parameter/Parameter.h dolfin/parameter/ParameterList.cpp
  dolfin/parameter/ParameterList.h dolfin/parameter/ParameterSystem.cpp
  dolfin/parameter/ParameterSystem.h dolfin/parameter/ParameterValue.cpp
  dolfin/parameter/ParameterValue.h dolfin/parameter/Parametrized.cpp
  dolfin/parameter/Parametrized.h dolfin/parameter/dolfin_parameter.h
  dolfin/parameter/parameters.cpp dolfin/parameter/parameters.h
  dolfin/plot/plot.cpp dolfin/swig/dolfin_docstrings.i
  dolfin/swig/dolfin_function_post.i dolfin/swig/dolfin_headers.i
  dolfin/swig/dolfin_io_post.i description:
  Remove old parameter system, including dolfin_get, dolfin_set
  and use new global parameters everywhere. Python untested and
  probably needs work.
 
 Did you forget to commit SLEPcEigenSolver.cpp?

Strange, it compiled here, including all demos. I'll add the correct
version shortly. I'm working on renaming NewParameter to Parameter etc
so it will be in the same changeset.

-- 
Anders


 Johan
 
 
  changeset:   6418:af869a96c99f563c7fe8a49322033a168aea5d89
  user:Johan Hake h...@simula.no
  date:Sun Jul 05 21:57:08 2009 +0200
  files:   SConstruct scons/simula-scons/simula_scons/__init__.py
  description:
  Removed the deprication warnings in SCons.
  Also moved scons.PathOption to the new PathVariable.
 
  --
  For more details, visit http://www.fenics.org/hg/dolfin
  ___
  DOLFIN-dev mailing list
  DOLFIN-dev@fenics.org
  http://www.fenics.org/mailman/listinfo/dolfin-dev
 
 
 ___
 DOLFIN-dev mailing list
 DOLFIN-dev@fenics.org
 http://www.fenics.org/mailman/listinfo/dolfin-dev


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Sunday 05 July 2009 23:05:33 Anders Logg wrote:
 On Sun, Jul 05, 2009 at 10:59:21PM +0200, Johan Hake wrote:
  On Sunday 05 July 2009 22:41:40 DOLFIN wrote:
   One or more new changesets pushed to the primary dolfin repository.
   A short summary of the last three changesets is included below.
  
   changeset:   6420:920786635f4ec37a05fe3752d0701d9cf472f125
   tag: tip
   parent:  6419:8d098ee6533779a969591119a1073fc1c59d12fd
   parent:  6418:af869a96c99f563c7fe8a49322033a168aea5d89
   user:Anders Logg l...@simula.no
   date:Sun Jul 05 22:41:35 2009 +0200
   files:
   description:
   merge
  
  
   changeset:   6419:8d098ee6533779a969591119a1073fc1c59d12fd
   parent:  6416:e645d3295afb8732b2186e4fc62d026a48c6fb55
   user:Anders Logg l...@simula.no
   date:Sun Jul 05 22:40:47 2009 +0200
   files:   demo/la/eigensolver/cpp/main.cpp
   demo/ode/harmonic/cpp/main_solvedual.cpp demo/ode/stiff/cpp/main.cpp
   demo/pde/cahn-hilliard/cpp/main.cpp demo/pde/dg/biharmonic/cpp/main.cpp
   demo/pde/dg/poisson/cpp/main.cpp dolfin/common/Timer.h
   dolfin/io/GenericFile.cpp dolfin/io/GenericFile.h dolfin/io/XMLFile.h
   dolfin/io/XMLParameterList.cpp dolfin/io/XMLParameterList.h
   dolfin/io/XMLParameters.cpp dolfin/io/XMLParameters.h
   dolfin/la/DefaultFactory.cpp dolfin/la/EpetraPreconditioner.h
   dolfin/la/SLEPcEigenSolver.h dolfin/la/uBLASPreconditioner.h
   dolfin/mesh/Mesh.h dolfin/ode/Adaptivity.cpp
   dolfin/ode/Dependencies.cpp dolfin/ode/GMPObject.h
   dolfin/ode/MonoAdaptiveFixedPointSolver.cpp
   dolfin/ode/MonoAdaptiveNewtonSolver.cpp
   dolfin/ode/MonoAdaptiveTimeSlab.cpp dolfin/ode/MonoAdaptivity.cpp
   dolfin/ode/MultiAdaptiveFixedPointSolver.cpp
   dolfin/ode/MultiAdaptiveNewtonSolver.cpp
   dolfin/ode/MultiAdaptiveTimeSlab.cpp dolfin/ode/MultiAdaptivity.cpp
   dolfin/ode/ODE.cpp dolfin/ode/ODESolution.cpp dolfin/ode/ODESolver.cpp
   dolfin/ode/Partition.cpp dolfin/ode/TimeSlab.cpp dolfin/ode/TimeSlab.h
   dolfin/ode/TimeSlabSolver.cpp dolfin/ode/TimeStepper.cpp
   dolfin/parameter/DefaultParameters.h dolfin/parameter/NewParameters.cpp
   dolfin/parameter/NewParameters.h dolfin/parameter/Parameter.cpp
   dolfin/parameter/Parameter.h dolfin/parameter/ParameterList.cpp
   dolfin/parameter/ParameterList.h dolfin/parameter/ParameterSystem.cpp
   dolfin/parameter/ParameterSystem.h dolfin/parameter/ParameterValue.cpp
   dolfin/parameter/ParameterValue.h dolfin/parameter/Parametrized.cpp
   dolfin/parameter/Parametrized.h dolfin/parameter/dolfin_parameter.h
   dolfin/parameter/parameters.cpp dolfin/parameter/parameters.h
   dolfin/plot/plot.cpp dolfin/swig/dolfin_docstrings.i
   dolfin/swig/dolfin_function_post.i dolfin/swig/dolfin_headers.i
   dolfin/swig/dolfin_io_post.i description:
   Remove old parameter system, including dolfin_get, dolfin_set
   and use new global parameters everywhere. Python untested and
   probably needs work.
 
  Did you forget to commit SLEPcEigenSolver.cpp?

 Strange, it compiled here, including all demos.

Which indicates that you just forgot to include SLEPcEigenSolver.cpp in the 
commit.

 I'll add the correct 
 version shortly. I'm working on renaming NewParameter to Parameter etc
 so it will be in the same changeset.

Ok

johan
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Sun, Jul 05, 2009 at 11:12:00PM +0200, Johan Hake wrote:
 On Sunday 05 July 2009 23:05:33 Anders Logg wrote:
  On Sun, Jul 05, 2009 at 10:59:21PM +0200, Johan Hake wrote:
   On Sunday 05 July 2009 22:41:40 DOLFIN wrote:
One or more new changesets pushed to the primary dolfin repository.
A short summary of the last three changesets is included below.
   
changeset:   6420:920786635f4ec37a05fe3752d0701d9cf472f125
tag: tip
parent:  6419:8d098ee6533779a969591119a1073fc1c59d12fd
parent:  6418:af869a96c99f563c7fe8a49322033a168aea5d89
user:Anders Logg l...@simula.no
date:Sun Jul 05 22:41:35 2009 +0200
files:
description:
merge
   
   
changeset:   6419:8d098ee6533779a969591119a1073fc1c59d12fd
parent:  6416:e645d3295afb8732b2186e4fc62d026a48c6fb55
user:Anders Logg l...@simula.no
date:Sun Jul 05 22:40:47 2009 +0200
files:   demo/la/eigensolver/cpp/main.cpp
demo/ode/harmonic/cpp/main_solvedual.cpp demo/ode/stiff/cpp/main.cpp
demo/pde/cahn-hilliard/cpp/main.cpp demo/pde/dg/biharmonic/cpp/main.cpp
demo/pde/dg/poisson/cpp/main.cpp dolfin/common/Timer.h
dolfin/io/GenericFile.cpp dolfin/io/GenericFile.h dolfin/io/XMLFile.h
dolfin/io/XMLParameterList.cpp dolfin/io/XMLParameterList.h
dolfin/io/XMLParameters.cpp dolfin/io/XMLParameters.h
dolfin/la/DefaultFactory.cpp dolfin/la/EpetraPreconditioner.h
dolfin/la/SLEPcEigenSolver.h dolfin/la/uBLASPreconditioner.h
dolfin/mesh/Mesh.h dolfin/ode/Adaptivity.cpp
dolfin/ode/Dependencies.cpp dolfin/ode/GMPObject.h
dolfin/ode/MonoAdaptiveFixedPointSolver.cpp
dolfin/ode/MonoAdaptiveNewtonSolver.cpp
dolfin/ode/MonoAdaptiveTimeSlab.cpp dolfin/ode/MonoAdaptivity.cpp
dolfin/ode/MultiAdaptiveFixedPointSolver.cpp
dolfin/ode/MultiAdaptiveNewtonSolver.cpp
dolfin/ode/MultiAdaptiveTimeSlab.cpp dolfin/ode/MultiAdaptivity.cpp
dolfin/ode/ODE.cpp dolfin/ode/ODESolution.cpp dolfin/ode/ODESolver.cpp
dolfin/ode/Partition.cpp dolfin/ode/TimeSlab.cpp dolfin/ode/TimeSlab.h
dolfin/ode/TimeSlabSolver.cpp dolfin/ode/TimeStepper.cpp
dolfin/parameter/DefaultParameters.h dolfin/parameter/NewParameters.cpp
dolfin/parameter/NewParameters.h dolfin/parameter/Parameter.cpp
dolfin/parameter/Parameter.h dolfin/parameter/ParameterList.cpp
dolfin/parameter/ParameterList.h dolfin/parameter/ParameterSystem.cpp
dolfin/parameter/ParameterSystem.h dolfin/parameter/ParameterValue.cpp
dolfin/parameter/ParameterValue.h dolfin/parameter/Parametrized.cpp
dolfin/parameter/Parametrized.h dolfin/parameter/dolfin_parameter.h
dolfin/parameter/parameters.cpp dolfin/parameter/parameters.h
dolfin/plot/plot.cpp dolfin/swig/dolfin_docstrings.i
dolfin/swig/dolfin_function_post.i dolfin/swig/dolfin_headers.i
dolfin/swig/dolfin_io_post.i description:
Remove old parameter system, including dolfin_get, dolfin_set
and use new global parameters everywhere. Python untested and
probably needs work.
  
   Did you forget to commit SLEPcEigenSolver.cpp?
 
  Strange, it compiled here, including all demos.
 
 Which indicates that you just forgot to include SLEPcEigenSolver.cpp in the 
 commit.

No, I just did 'hg commit' which should pick up all the files. The
strange thing was that it even compiled on my machine with the old
wrong version there. Perhaps something with time stamps etc on the .os
files. It's a mystery. Anyway, I've pushed the new version now (I
think...).

-- 
Anders


  I'll add the correct 
  version shortly. I'm working on renaming NewParameter to Parameter etc
  so it will be in the same changeset.
 
 Ok
 
 johan


signature.asc
Description: Digital signature
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Sunday 05 July 2009 23:19:48 Anders Logg wrote:
 On Sun, Jul 05, 2009 at 11:12:00PM +0200, Johan Hake wrote:
  On Sunday 05 July 2009 23:05:33 Anders Logg wrote:
   On Sun, Jul 05, 2009 at 10:59:21PM +0200, Johan Hake wrote:
On Sunday 05 July 2009 22:41:40 DOLFIN wrote:
 One or more new changesets pushed to the primary dolfin repository.
 A short summary of the last three changesets is included below.

 changeset:   6420:920786635f4ec37a05fe3752d0701d9cf472f125
 tag: tip
 parent:  6419:8d098ee6533779a969591119a1073fc1c59d12fd
 parent:  6418:af869a96c99f563c7fe8a49322033a168aea5d89
 user:Anders Logg l...@simula.no
 date:Sun Jul 05 22:41:35 2009 +0200
 files:
 description:
 merge


 changeset:   6419:8d098ee6533779a969591119a1073fc1c59d12fd
 parent:  6416:e645d3295afb8732b2186e4fc62d026a48c6fb55
 user:Anders Logg l...@simula.no
 date:Sun Jul 05 22:40:47 2009 +0200
 files:   demo/la/eigensolver/cpp/main.cpp
 demo/ode/harmonic/cpp/main_solvedual.cpp
 demo/ode/stiff/cpp/main.cpp demo/pde/cahn-hilliard/cpp/main.cpp
 demo/pde/dg/biharmonic/cpp/main.cpp
 demo/pde/dg/poisson/cpp/main.cpp dolfin/common/Timer.h
 dolfin/io/GenericFile.cpp dolfin/io/GenericFile.h
 dolfin/io/XMLFile.h dolfin/io/XMLParameterList.cpp
 dolfin/io/XMLParameterList.h dolfin/io/XMLParameters.cpp
 dolfin/io/XMLParameters.h
 dolfin/la/DefaultFactory.cpp dolfin/la/EpetraPreconditioner.h
 dolfin/la/SLEPcEigenSolver.h dolfin/la/uBLASPreconditioner.h
 dolfin/mesh/Mesh.h dolfin/ode/Adaptivity.cpp
 dolfin/ode/Dependencies.cpp dolfin/ode/GMPObject.h
 dolfin/ode/MonoAdaptiveFixedPointSolver.cpp
 dolfin/ode/MonoAdaptiveNewtonSolver.cpp
 dolfin/ode/MonoAdaptiveTimeSlab.cpp dolfin/ode/MonoAdaptivity.cpp
 dolfin/ode/MultiAdaptiveFixedPointSolver.cpp
 dolfin/ode/MultiAdaptiveNewtonSolver.cpp
 dolfin/ode/MultiAdaptiveTimeSlab.cpp dolfin/ode/MultiAdaptivity.cpp
 dolfin/ode/ODE.cpp dolfin/ode/ODESolution.cpp
 dolfin/ode/ODESolver.cpp dolfin/ode/Partition.cpp
 dolfin/ode/TimeSlab.cpp dolfin/ode/TimeSlab.h
 dolfin/ode/TimeSlabSolver.cpp dolfin/ode/TimeStepper.cpp
 dolfin/parameter/DefaultParameters.h
 dolfin/parameter/NewParameters.cpp dolfin/parameter/NewParameters.h
 dolfin/parameter/Parameter.cpp dolfin/parameter/Parameter.h
 dolfin/parameter/ParameterList.cpp dolfin/parameter/ParameterList.h
 dolfin/parameter/ParameterSystem.cpp
 dolfin/parameter/ParameterSystem.h
 dolfin/parameter/ParameterValue.cpp
 dolfin/parameter/ParameterValue.h dolfin/parameter/Parametrized.cpp
 dolfin/parameter/Parametrized.h dolfin/parameter/dolfin_parameter.h
 dolfin/parameter/parameters.cpp dolfin/parameter/parameters.h
 dolfin/plot/plot.cpp dolfin/swig/dolfin_docstrings.i
 dolfin/swig/dolfin_function_post.i dolfin/swig/dolfin_headers.i
 dolfin/swig/dolfin_io_post.i description:
 Remove old parameter system, including dolfin_get, dolfin_set
 and use new global parameters everywhere. Python untested and
 probably needs work.
   
Did you forget to commit SLEPcEigenSolver.cpp?
  
   Strange, it compiled here, including all demos.
 
  Which indicates that you just forgot to include SLEPcEigenSolver.cpp in
  the commit.

 No, I just did 'hg commit' which should pick up all the files. The
 strange thing was that it even compiled on my machine with the old
 wrong version there. Perhaps something with time stamps etc on the .os
 files. It's a mystery. Anyway, I've pushed the new version now (I
 think...).

Ok, that's strange.

However now you need to commit changes to SLEPcEigenSolver.h:

dolfin/la/SLEPcEigenSolver.cpp: In 
constructor ‘dolfin::SLEPcEigenSolver::SLEPcEigenSolver()’:
dolfin/la/SLEPcEigenSolver.cpp:23: error: ‘parameters’ was not declared in 
this scope
dolfin/la/SLEPcEigenSolver.cpp:23: error: ‘default_parameters’ was not 
declared in this scope
dolfin/la/SLEPcEigenSolver.cpp: In member function ‘void 
dolfin::SLEPcEigenSolver::solve(const dolfin::PETScMatrix, dolfin::uint)’:
dolfin/la/SLEPcEigenSolver.cpp:43: error: expected `;' before ‘~’ token
cc1plus: warnings being treated as errors
dolfin/la/SLEPcEigenSolver.cpp:43: warning: statement has no effect
dolfin/la/SLEPcEigenSolver.cpp: In member function ‘void 
dolfin::SLEPcEigenSolver::read_parameters()’:
dolfin/la/SLEPcEigenSolver.cpp:155: error: ‘parameters’ was not declared in 
this scope
scons: *** [dolfin/la/SLEPcEigenSolver.os] Error 1
scons: building terminated because of errors.
dolfin/la/SLEPcEigenSolver.os failed: Error 1


Johan
___
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Sun, Jul 05, 2009 at 11:25:17PM +0200, Johan Hake wrote:
 On Sunday 05 July 2009 23:19:48 Anders Logg wrote:
  On Sun, Jul 05, 2009 at 11:12:00PM +0200, Johan Hake wrote:
   On Sunday 05 July 2009 23:05:33 Anders Logg wrote:
On Sun, Jul 05, 2009 at 10:59:21PM +0200, Johan Hake wrote:
 On Sunday 05 July 2009 22:41:40 DOLFIN wrote:
  One or more new changesets pushed to the primary dolfin repository.
  A short summary of the last three changesets is included below.
 
  changeset:   6420:920786635f4ec37a05fe3752d0701d9cf472f125
  tag: tip
  parent:  6419:8d098ee6533779a969591119a1073fc1c59d12fd
  parent:  6418:af869a96c99f563c7fe8a49322033a168aea5d89
  user:Anders Logg l...@simula.no
  date:Sun Jul 05 22:41:35 2009 +0200
  files:
  description:
  merge
 
 
  changeset:   6419:8d098ee6533779a969591119a1073fc1c59d12fd
  parent:  6416:e645d3295afb8732b2186e4fc62d026a48c6fb55
  user:Anders Logg l...@simula.no
  date:Sun Jul 05 22:40:47 2009 +0200
  files:   demo/la/eigensolver/cpp/main.cpp
  demo/ode/harmonic/cpp/main_solvedual.cpp
  demo/ode/stiff/cpp/main.cpp demo/pde/cahn-hilliard/cpp/main.cpp
  demo/pde/dg/biharmonic/cpp/main.cpp
  demo/pde/dg/poisson/cpp/main.cpp dolfin/common/Timer.h
  dolfin/io/GenericFile.cpp dolfin/io/GenericFile.h
  dolfin/io/XMLFile.h dolfin/io/XMLParameterList.cpp
  dolfin/io/XMLParameterList.h dolfin/io/XMLParameters.cpp
  dolfin/io/XMLParameters.h
  dolfin/la/DefaultFactory.cpp dolfin/la/EpetraPreconditioner.h
  dolfin/la/SLEPcEigenSolver.h dolfin/la/uBLASPreconditioner.h
  dolfin/mesh/Mesh.h dolfin/ode/Adaptivity.cpp
  dolfin/ode/Dependencies.cpp dolfin/ode/GMPObject.h
  dolfin/ode/MonoAdaptiveFixedPointSolver.cpp
  dolfin/ode/MonoAdaptiveNewtonSolver.cpp
  dolfin/ode/MonoAdaptiveTimeSlab.cpp dolfin/ode/MonoAdaptivity.cpp
  dolfin/ode/MultiAdaptiveFixedPointSolver.cpp
  dolfin/ode/MultiAdaptiveNewtonSolver.cpp
  dolfin/ode/MultiAdaptiveTimeSlab.cpp dolfin/ode/MultiAdaptivity.cpp
  dolfin/ode/ODE.cpp dolfin/ode/ODESolution.cpp
  dolfin/ode/ODESolver.cpp dolfin/ode/Partition.cpp
  dolfin/ode/TimeSlab.cpp dolfin/ode/TimeSlab.h
  dolfin/ode/TimeSlabSolver.cpp dolfin/ode/TimeStepper.cpp
  dolfin/parameter/DefaultParameters.h
  dolfin/parameter/NewParameters.cpp dolfin/parameter/NewParameters.h
  dolfin/parameter/Parameter.cpp dolfin/parameter/Parameter.h
  dolfin/parameter/ParameterList.cpp dolfin/parameter/ParameterList.h
  dolfin/parameter/ParameterSystem.cpp
  dolfin/parameter/ParameterSystem.h
  dolfin/parameter/ParameterValue.cpp
  dolfin/parameter/ParameterValue.h dolfin/parameter/Parametrized.cpp
  dolfin/parameter/Parametrized.h dolfin/parameter/dolfin_parameter.h
  dolfin/parameter/parameters.cpp dolfin/parameter/parameters.h
  dolfin/plot/plot.cpp dolfin/swig/dolfin_docstrings.i
  dolfin/swig/dolfin_function_post.i dolfin/swig/dolfin_headers.i
  dolfin/swig/dolfin_io_post.i description:
  Remove old parameter system, including dolfin_get, dolfin_set
  and use new global parameters everywhere. Python untested and
  probably needs work.

 Did you forget to commit SLEPcEigenSolver.cpp?
   
Strange, it compiled here, including all demos.
  
   Which indicates that you just forgot to include SLEPcEigenSolver.cpp in
   the commit.
 
  No, I just did 'hg commit' which should pick up all the files. The
  strange thing was that it even compiled on my machine with the old
  wrong version there. Perhaps something with time stamps etc on the .os
  files. It's a mystery. Anyway, I've pushed the new version now (I
  think...).
 
 Ok, that's strange.
 
 However now you need to commit changes to SLEPcEigenSolver.h:
 
 dolfin/la/SLEPcEigenSolver.cpp: In 
 constructor ‘dolfin::SLEPcEigenSolver::SLEPcEigenSolver()’:
 dolfin/la/SLEPcEigenSolver.cpp:23: error: ‘parameters’ was not declared in 
 this scope
 dolfin/la/SLEPcEigenSolver.cpp:23: error: ‘default_parameters’ was not 
 declared in this scope
 dolfin/la/SLEPcEigenSolver.cpp: In member function ‘void 
 dolfin::SLEPcEigenSolver::solve(const dolfin::PETScMatrix, dolfin::uint)’:
 dolfin/la/SLEPcEigenSolver.cpp:43: error: expected `;' before ‘~’ token
 cc1plus: warnings being treated as errors
 dolfin/la/SLEPcEigenSolver.cpp:43: warning: statement has no effect
 dolfin/la/SLEPcEigenSolver.cpp: In member function ‘void 
 dolfin::SLEPcEigenSolver::read_parameters()’:
 dolfin/la/SLEPcEigenSolver.cpp:155: error: ‘parameters’ was not declared in 
 this scope
 scons: *** [dolfin/la/SLEPcEigenSolver.os] Error 1
 scons: building terminated because of errors.
 dolfin/la/SLEPcEigenSolver.os failed: Error 1

This is getting stranger. It compiles perfectly fine here, but the
errors above are obviously there (even in my local copy of
SLEPcEigenSolver.h).

Re: [DOLFIN-dev] [HG DOLFIN] merge

On Sun, Jul 05, 2009 at 11:32:24PM +0200, Anders Logg wrote:
 On Sun, Jul 05, 2009 at 11:25:17PM +0200, Johan Hake wrote:
  On Sunday 05 July 2009 23:19:48 Anders Logg wrote:
   On Sun, Jul 05, 2009 at 11:12:00PM +0200, Johan Hake wrote:
On Sunday 05 July 2009 23:05:33 Anders Logg wrote:
 On Sun, Jul 05, 2009 at 10:59:21PM +0200, Johan Hake wrote:
  On Sunday 05 July 2009 22:41:40 DOLFIN wrote:
   One or more new changesets pushed to the primary dolfin 
   repository.
   A short summary of the last three changesets is included below.
  
   changeset:   6420:920786635f4ec37a05fe3752d0701d9cf472f125
   tag: tip
   parent:  6419:8d098ee6533779a969591119a1073fc1c59d12fd
   parent:  6418:af869a96c99f563c7fe8a49322033a168aea5d89
   user:Anders Logg l...@simula.no
   date:Sun Jul 05 22:41:35 2009 +0200
   files:
   description:
   merge
  
  
   changeset:   6419:8d098ee6533779a969591119a1073fc1c59d12fd
   parent:  6416:e645d3295afb8732b2186e4fc62d026a48c6fb55
   user:Anders Logg l...@simula.no
   date:Sun Jul 05 22:40:47 2009 +0200
   files:   demo/la/eigensolver/cpp/main.cpp
   demo/ode/harmonic/cpp/main_solvedual.cpp
   demo/ode/stiff/cpp/main.cpp demo/pde/cahn-hilliard/cpp/main.cpp
   demo/pde/dg/biharmonic/cpp/main.cpp
   demo/pde/dg/poisson/cpp/main.cpp dolfin/common/Timer.h
   dolfin/io/GenericFile.cpp dolfin/io/GenericFile.h
   dolfin/io/XMLFile.h dolfin/io/XMLParameterList.cpp
   dolfin/io/XMLParameterList.h dolfin/io/XMLParameters.cpp
   dolfin/io/XMLParameters.h
   dolfin/la/DefaultFactory.cpp dolfin/la/EpetraPreconditioner.h
   dolfin/la/SLEPcEigenSolver.h dolfin/la/uBLASPreconditioner.h
   dolfin/mesh/Mesh.h dolfin/ode/Adaptivity.cpp
   dolfin/ode/Dependencies.cpp dolfin/ode/GMPObject.h
   dolfin/ode/MonoAdaptiveFixedPointSolver.cpp
   dolfin/ode/MonoAdaptiveNewtonSolver.cpp
   dolfin/ode/MonoAdaptiveTimeSlab.cpp dolfin/ode/MonoAdaptivity.cpp
   dolfin/ode/MultiAdaptiveFixedPointSolver.cpp
   dolfin/ode/MultiAdaptiveNewtonSolver.cpp
   dolfin/ode/MultiAdaptiveTimeSlab.cpp 
   dolfin/ode/MultiAdaptivity.cpp
   dolfin/ode/ODE.cpp dolfin/ode/ODESolution.cpp
   dolfin/ode/ODESolver.cpp dolfin/ode/Partition.cpp
   dolfin/ode/TimeSlab.cpp dolfin/ode/TimeSlab.h
   dolfin/ode/TimeSlabSolver.cpp dolfin/ode/TimeStepper.cpp
   dolfin/parameter/DefaultParameters.h
   dolfin/parameter/NewParameters.cpp 
   dolfin/parameter/NewParameters.h
   dolfin/parameter/Parameter.cpp dolfin/parameter/Parameter.h
   dolfin/parameter/ParameterList.cpp 
   dolfin/parameter/ParameterList.h
   dolfin/parameter/ParameterSystem.cpp
   dolfin/parameter/ParameterSystem.h
   dolfin/parameter/ParameterValue.cpp
   dolfin/parameter/ParameterValue.h 
   dolfin/parameter/Parametrized.cpp
   dolfin/parameter/Parametrized.h 
   dolfin/parameter/dolfin_parameter.h
   dolfin/parameter/parameters.cpp dolfin/parameter/parameters.h
   dolfin/plot/plot.cpp dolfin/swig/dolfin_docstrings.i
   dolfin/swig/dolfin_function_post.i dolfin/swig/dolfin_headers.i
   dolfin/swig/dolfin_io_post.i description:
   Remove old parameter system, including dolfin_get, dolfin_set
   and use new global parameters everywhere. Python untested and
   probably needs work.
 
  Did you forget to commit SLEPcEigenSolver.cpp?

 Strange, it compiled here, including all demos.
   
Which indicates that you just forgot to include SLEPcEigenSolver.cpp in
the commit.
  
   No, I just did 'hg commit' which should pick up all the files. The
   strange thing was that it even compiled on my machine with the old
   wrong version there. Perhaps something with time stamps etc on the .os
   files. It's a mystery. Anyway, I've pushed the new version now (I
   think...).
  
  Ok, that's strange.
  
  However now you need to commit changes to SLEPcEigenSolver.h:
  
  dolfin/la/SLEPcEigenSolver.cpp: In 
  constructor ‘dolfin::SLEPcEigenSolver::SLEPcEigenSolver()’:
  dolfin/la/SLEPcEigenSolver.cpp:23: error: ‘parameters’ was not declared in 
  this scope
  dolfin/la/SLEPcEigenSolver.cpp:23: error: ‘default_parameters’ was not 
  declared in this scope
  dolfin/la/SLEPcEigenSolver.cpp: In member function ‘void 
  dolfin::SLEPcEigenSolver::solve(const dolfin::PETScMatrix, dolfin::uint)’:
  dolfin/la/SLEPcEigenSolver.cpp:43: error: expected `;' before ‘~’ token
  cc1plus: warnings being treated as errors
  dolfin/la/SLEPcEigenSolver.cpp:43: warning: statement has no effect
  dolfin/la/SLEPcEigenSolver.cpp: In member function ‘void 
  dolfin::SLEPcEigenSolver::read_parameters()’:
  dolfin/la/SLEPcEigenSolver.cpp:155: error: ‘parameters’ was not declared in 
  this scope
  scons: *** [dolfin/la/SLEPcEigenSolver.os] Error 1
  scons: building terminated because

Re: [DOLFIN-dev] [HG DOLFIN] merge