On Mon, 2010-08-02 at 14:08 +0200, Florian Rathgeber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 23.07.2010 20:33, Kristian Ølgaard wrote: > > On 23 July 2010 13:30, Florian Rathgeber > > <[email protected]> wrote: > > On 23.07.2010 14:22, Kristian Ølgaard wrote: > >>>> On 23 July 2010 13:02, Florian Rathgeber > >>>> <[email protected]> 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 > >>>>>>> <[email protected]> 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? >
Yes. The tensor contraction relies on computing everything which is not related to cell geometry a priori, so it won't be able to handle conditionals. Garth > Florian > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > > iEYEARECAAYFAkxWtSYACgkQ8Z6llsctAxZwpACfaAKeewvmEknig7ySe9nxGaM1 > 2ZwAn07Mkka+BMcvbuVlWMMV1iVRF0QP > =0E1w > -----END PGP SIGNATURE----- > > _______________________________________________ > Mailing list: https://launchpad.net/~ffc > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ffc > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : [email protected] Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
