ffc team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23.07.2010 20:33, Kristian Ølgaard wrote:
> On 23 July 2010 13:30, Florian Rathgeber
> <florian.rathgeber@xxxxxxxxxxxxxx> wrote:
> On 23.07.2010 14:22, Kristian Ølgaard wrote:
>>>> On 23 July 2010 13:02, Florian Rathgeber
>>>> <florian.rathgeber@xxxxxxxxxxxxxx> wrote:
>>>> I guess I haven't made my point very clear. The demo you gave is a good
>>>> example of what's currently possible and where the limit is I think.
>>>>
>>>> Say you take dolfin/demo/pde/spatial-coordinates/cpp and want to
>>>> restrict the source term f to only a circle in the center of the domain.
>>>> How would you do that? I wouldn't know another way than a conditional
>>>> and I couldn't find a way to get that working with FFC.
>>>>
>>>>> Now it makes more sense, I think you would need a conditional indeed.
>>>>
>>>> I was not talking about constants, but about expressions that are not
>>>> uniform over the whole domain, should have made that more clear.
>>>>
>>>> Florian
>>>>
>>>> On 23.07.2010 13:51, Kristian Ølgaard wrote:
>>>>>>> On 23 July 2010 12:40, Florian Rathgeber
>>>>>>> <florian.rathgeber@xxxxxxxxxxxxxx> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Profiling DOLFIN assembly shows that for forms with many coefficients or
>>>>>>> computationally expensive expressions assigned to coefficients, a great
>>>>>>> deal of the whole assembly is spent in expression evaluation.
>>>>>>>
>>>>>>> An idea I wanted to investigate was giving an expresssion in UFL and
>>>>>>> have FFC generate corresponding code to evaluate it inline during tensor
>>>>>>> tabulation. That should have the potential of eliminating some of the
>>>>>>> overhead.
>>>>>>>
>>>>>>> However, currently that is only possible within very limited bounds. FFC
>>>>>>> does not yet support UFL conditionals, which essentially limits possible
>>>>>>> expressions to depend on coordinates only and be the same over the whole
>>>>>>> domain (which is not very useful for most form coefficients, e.g. source
>>>>>>> terms).
>>>>>>>
>>>>>>>> Did you have a look at the dolfin/demo/pde/spatial-coordinates/cpp
>>>>>>>> demo? It is essentially the dolfin/demo/pde/poisson/cpp demo but it
>>>>>>>> uses source and boundary terms defined using coordinates and is not
>>>>>>>> the same over the whole domain (I don't really get your point here).
>>>>>>>> The coordinates are defined as the coordinates of the current
>>>>>>>> integration point located on the current cell which is being
>>>>>>>> integrated. Have a look at the generated code, then it might be
>>>>>>>> clearer what's going on.
>>>>>>>
>>>>>>>> Kristian
>>>>>>>
>>>>>>> This brings me to my questions:
>>>>>>> 1) Do you see a reasonable chance for speeding up assembly in the way
>>>>>>> described?
>>>>>>> 2) Is my assessement correct? Or do I miss some capabilities of FFC that
>>>>>>> support my use case?
>>>>>>> 3) Since UFL basically support arbitrary python syntax, would it be
>>>>>>> reasonable to support translation for user-defined Expressions given in
>>>>>>> python (either overloading eval in a class defived from Expression or
>>>>>>> passing C++ code to the SWIG constructor of Expression)? FFC would
>>>>>>> generate code to evaluate these Expressions inline during tensor
>>>>>>> tabulation. That would of course require the Expression to be stateless
>>>>>>> and have not input other than the coordinates. But at least it would
>>>>>>> provide much more flexibility and also consistency with the DOLFIN
>>>>>>> interface in general
>>>>
>>>>> I think it sounds complicated, much better to defined the function
>>>>> directly in terms of coordinates.
>>>>
>>>>>>> (sidenote: it is possible to specify Expressions in this way in UFL, but
>>>>>>> they are treated just like Coefficients by FFC)
>>>>
>>>>> I don't think this is the case, it is possible in the Python interface
>>>>> to DOLFIN, but not in UFL.
> 
> You are right, it is not in the UFL specification. It is technically
> possible with FFC though. I passed the example UFL file I gave to FFC
> and it was accepted, however the generated code was the very same as if
> I had just written
> 
>> No, it is technically possible in PyDolfin. Not UFL or FFC
>> Anyway, I've implemented support for conditionals see if it works.
>> (dolfin/demo/pde/conditional)
>> I only tested '<' so far but the other operators should work the same way.
> 
>> Kristian

Thank you for implementing that and sorry for not coming back to this
earlier. As far as I can see, it is only implemented for quadrature. Is
there a fundamental problem that would inhibit implementing it for
tensor representation as well?

Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)

iEYEARECAAYFAkxWtSYACgkQ8Z6llsctAxZwpACfaAKeewvmEknig7ySe9nxGaM1
2ZwAn07Mkka+BMcvbuVlWMMV1iVRF0QP
=0E1w
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature