ffc team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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?

Garth

> --
> Anders
> 
> 
>> 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?
>>>