On 23 July 2010 13:30, Florian Rathgeber
<florian.rathge...@googlemail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23.07.2010 14:22, Kristian Ølgaard wrote:
>> On 23 July 2010 13:02, Florian Rathgeber
>> <florian.rathge...@googlemail.com> 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.rathge...@googlemail.com> 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
> f = Coefficient(scalar)
>
> instead of
>
> f = Expression(code_expr)
>
> Florian
>
>>>>> Illustration example (UFL file):
>>>>> from dolfin import Expression
>>>>>
>>>>> code_expr = """
>>>>> class Source : public Expression
>>>>> {
>>>>> public:
>>>>> void eval(Array<double>& values, const Array<double>& x) const
>>>>> {
>>>>> values[0] = ((x[0]-0.25)*(x[0]-0.25)+(x[1]-0.5)*(x[1]-0.5) <
>>>>> 0.025) ? 1.0 : 0.0;
>>>>> }
>>>>> };
>>>>> """
>>
>>> In UFL you can do:
>>
>>> f = conditional( (x[0]-0.25)**2 + (x[1]-0.5)**2 < 0.025), 1.0, 0.0 )
>>
>>> although no output is generated yet because Conditionals are not
>>> supported yet, but the code which will be generated should look an
>>> awful lot like what you have i.e.
>>
>>> f = ((x[0]-0.25)*(x[0]-0.25)+(x[1]-0.5)*(x[1]-0.5) < 0.025) ? 1.0 : 0.0;
>>
>>> Kristian
>>
>>>>> scalar = FiniteElement("Lagrange", triangle, 1)
>>>>>
>>>>> v = TestFunction(scalar)
>>>>> u = TrialFunction(scalar)
>>>>> u0 = Coefficient(scalar)
>>>>> f = Expressions(code_expr)
>>>>>
>>>>> c = 0.05
>>>>> k = 0.1
>>>>> alpha = 1.0
>>>>>
>>>>> a = v*u*dx + k*alpha*u*v*dx + k*c*dot(grad(v), grad(u))*dx
>>>>> L = v*u0*dx + k*v*f*dx
>>>>>
>>>>> Florian
>>>>>>
>>>>>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ffc
>> Post to : ffc@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~ffc
>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>
>>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.12 (MingW32)
>
> iEYEARECAAYFAkxJi3wACgkQ8Z6llsctAxZoNwCgg0mSVE6b7jupVWLKyoQoFrbZ
> e/wAoIXtwpNyC+40gF1DVG9UGmvXBnCa
> =Z4Co
> -----END PGP SIGNATURE-----
>
>
_______________________________________________
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
