On 26/04/11 16:39, Johan Hake wrote:
> On Tuesday April 26 2011 08:33:11 Garth N. Wells wrote:
>> On 26/04/11 16:31, Johan Hake wrote:
>>> On Tuesday April 26 2011 08:16:29 Garth N. Wells wrote:
>>>> On 26/04/11 16:07, Anders Logg wrote:
>>>>> On Tue, Apr 26, 2011 at 03:59:52PM +0100, Garth N. Wells wrote:
>>>>>> On 26/04/11 15:55, Anders Logg wrote:
>>>>>>> On Tue, Apr 26, 2011 at 03:45:22PM +0100, Garth N. Wells wrote:
>>>>>>>> On 26/04/11 13:51, Anders Logg wrote:
>>>>>>>>> On Tue, Apr 26, 2011 at 02:00:50PM +0200, Anders Logg wrote:
>>>>>>>>>> It feels good that you trust me enough to handle it. ;-)
>>>>>>>>>>
>>>>>>>>>> Will add it sometime this afternoon and then we can revisit the
>>>>>>>>>> JIT compiler caching.
>>>>>>>>>
>>>>>>>>> I'm getting confused here... Looking at preprocess.py in UFL, I see
>>>
>>> this:
>>>>>>>> It is confusing. Does the function 'preprocess' do anything that the
>>>>>>>> old FormData class didn't? It would be easier to follow if Form just
>>>>>>>> had a member function form_data() that computes and stores data
>>>>>>>> (like it used to), or if Form had a 'preprocess' function. Having
>>>>>>>> the function preprocess return a new form is really confusing.
>>>>>>>
>>>>>>> I don't find that particularly confusing. It's the same as
>>>>>>>
>>>>>>> refined_mesh = refine(mesh)
>>>>>>
>>>>>> Which is the whole problem. By creating a new object, FormData is
>>>>>> thrown away. The preprocessing should just compute some more data,
>>>>>> just like we *don't* do
>>>>>>
>>>>>> initialised_mesh = mesh.init(0)
>>>>>>
>>>>>> What was wrong with Martin's original design that necessitated the
>>>>>> change?
>>>>>
>>>>> As I explained, I thought it was better to have an explicit call to
>>>>> preprocess since that makes it clear that one makes a call to a
>>>>> function which may take some time to execute (instead of just calling
>>>>> a member function which seems to just return some data).
>>>>>
>>>>> But as I say above: I added the caching back at some point (maybe even
>>>>> the day after I removed it 2 years ago) so we don't need to discuss
>>>>> why I removed it (as I realized myself I shouldn't have removed it and
>>>>> added it back a long time ago).
>>>>>
>>>>> What has me confused now is that the caching seems to be in place but
>>>>> we still need the extra caching in FFC/DOLFIN and I don't see why.
>>>>
>>>> Because preprocess returns a new form, e.g. define a form
>>>>
>>>> a = u*v*dx
>>>> jit(a)
>>>>
>>>> Inside jit,
>>>>
>>>> a.form_data() is None:
>>>> b = preprocess(a) # b now has data attached, but a doesn't
>>>>
>>>> else:
>>>> b = a
>>>>
>>>> Now 'b' has been preprocessed, and has form data attached, but 'a'
>>>> doesn't. Calling 'jit(a)' again, the code will never enter the 'else'
>>>> part of the clause because 'a' never gets any form data. Johan has added
>>>> some code FFC that attaches the form data of 'b' to 'a', but it is a bit
>>>> clumsy.
>>>
>>> No, it was already attached. I just made ffc use it.
>>
>> Didn't you add the line
>>
>> form._form_data = preprocessed_form.form_data()
>
> No, I added:
>
bzr says that you did ;). I'd take credit for it because it adds the
missing data to the original form.
Garth
> preprocessed_form = form.form_data()._form
>
> I think the thing here is that form_data has always had a preprocessed form.
> Someone (lets not point fingers!) thought that was too much magic and added
> an
> explicit need to call:
>
> form = preprocess(form)
>
> in jit_compiler(). This made the design more complicated and also introduced
> a
> cirucular dependency, as the return preprocessed form need to know of its
> form_data, but the form_data already had a reference to the preprocessed
> form.
> The latter is what I used in the one line I altered.
>
> Johan
>
>> ?
>>
>> Garth
>>
>>>> Better would be
>>>>
>>>> a.preprocess()
>>>>
>>>> or
>>>>
>>>> a.form_data()
>>>
>>> As already mentioned in a previous email, I suggest we only call
>>> form_data(). This will return the form_data. The preprocessed form is
>>> attached to the form_data and this is what is passed to the code
>>> generator. I am pretty sure this is what was there from the beginning.
>>>
>>> It is confusing to call:
>>> form = preprocess(form)
>>>
>>> as the preprocessed form was never ment to be doing anything but being
>>> passed to the code generator, AFAIK.
>>>
>>> Johan
>>>
>>>> Garth
>>>>
>>>>> --
>>>>> Anders
>>>>>
>>>>>> Garth
>>>>>>
>>>>>>>> Garth
>>>>>>>>
>>>>>>>>> def preprocess(form, object_names={}, common_cell=None):
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> # Check that form is not already preprocessed
>>>>>>>>>
>>>>>>>>> if form.form_data() is not None:
>>>>>>>>> debug("Form is already preprocessed. Not updating form
>>>>>>>>> data.") return form
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> # Attach form data to form
>>>>>>>>> form._form_data = form_data
>>>>>>>>>
>>>>>>>>> # Attach preprocessed form to form data
>>>>>>>>> form_data._form = form
>>>>>>>>>
>>>>>>>>> And when I look at the blamelist (bzr annotate), it looks like I
>>>>>>>>> added those lines, so I must have come to my senses and added it
>>>>>>>>> back at some point (way back). So in conclusion, calling
>>>>>>>>> preprocess() should not taking any time.
>>>>>>>>>
>>>>>>>>> What am I missing?
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~ffc
>>>> Post to : ffc@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~ffc
>>>> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
