dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

Joachim!

Comments where I have comments:

I applied the three 

> 1) Allow tensor Constants in python (initialised from e.g. a numpy matrix)

Applied.

> 2) Define a split method on FunctionSpace in python. This seems natural
> since Function has one... but not important.

Applied.

> 3) Define the methods "near" and "between" in both compiled and python
> Expressions (etc). So you can write
>    def boundary(self):
>        return near(x[0], 0)
>    or
>    boundary = compile_subdomains("near(x[0], 0)")
> 
>    I think "near" is good and gets rid of many of those shouting
> DOLFIN_EPSs. "between" is perhaps more questionable... I leave it to you.

Maybe this should be implemented in C++ so one can use it there too? Your 
patch implements it in the generated code layer, which is kind off hidden.

> 4) This matches up with a viper patch sent to fenics-viper@lp, and
> simplifies plot() a bit. It also does less projection of those types viper
> can actually handle --- which means that for example DG plots are slightly
> different (but maybe not better?).

Applied. I guess this one requires a viper pull?

> 5) I find it easier to understand DIVERGED_INDEFINITE_MAT than -8 as an
> error message.
> 
> 6) PETSc development version requires some changes
> 
> 7) This one is really unimportant and you may not agree anyway.
> 
> 8) This one IS important. Allows assembly into rectangular matrices with
> epetra. This used to crash, and tracing it down was a bitch due to epetra
> throwing bare-int exceptions (which are rethrown by swig).
> 
> 9) A utility function on DirichletBC for symmetric modification of block
> matrices. Also implements EpetraMatrix::set_row. These can probably be made
> much more efficient by someone who knows the la backends better (I threw in
> a "this is inefficient" log msg there to make this point), but it seems to
> work in superficial testing.
> 
> Now the question: I seem to hit dolfin asserts a lot when I try things, and
> that's annoying since they call abort() and thus kill (i)python. I see that
> they used to be implemented as runtime exceptions, which plays much better
> with python, but that was changed. Was there a good reason for that change,
> or can we bring back exceptions? (the change itself is trivial and I can
> send a patch, but there was probably a reason...)

This is also enoying to me. I rather see an exception too.

Johan