replace() fails if the new function spaces have a different mesh

[Simon Funke]

I submit this bug report following Marie's suggestions on the related DOLFIN question (https://answers.launchpad.net/dolfin/+question/215120)

DOLFIN crashes in the solve() routine after using replace() to replace the function spaces of a form.

While the solve succeeds if replaced function spaces have:
- a different polynomial degree or
- a different polynomial degree and a different mesh,
it does not work if the new function spaces is based on a new mesh only.

This is the error message I get:
*** -------------------------------------------------------------------------
*** Error: Unable to define linear variational problem a(u, v) = L(v) for all v.
*** Reason: Expecting the solution variable u to be a member of the trial space.
*** Where: This error was encountered inside LinearVariationalProblem.cpp.
*** ------------------------------------------------------------------------

The attached file demonstrates the problem.

[Martin Sandve Alnæs (martinal)]

Probably a caching issue somewhere in the PyDolfin layer. The form sigature
is unaffected by the mesh.
Den 27. nov. 2012 19:15 skrev "Simon Funke" <email address hidden>
følgende:

> Public bug reported:
>
> I submit this bug report following Marie's suggestions on the related
> DOLFIN question (https://answers.launchpad.net/dolfin/+question/215120)
>
> DOLFIN crashes in the solve() routine after using replace() to replace
> the function spaces of a form.
>
> While the solve succeeds if replaced function spaces have:
> - a different polynomial degree or
> - a different polynomial degree and a different mesh,
> it does not work if the new function spaces is based on a new mesh only.
>
> This is the error message I get:
> ***
> -------------------------------------------------------------------------
> *** Error: Unable to define linear variational problem a(u, v) = L(v) for
> all v.
> *** Reason: Expecting the solution variable u to be a member of the trial
> space.
> *** Where: This error was encountered inside LinearVariationalProblem.cpp.
> ***
> ------------------------------------------------------------------------
>
> The attached file demonstrates the problem.
>
> ** Affects: dolfin
> Importance: Undecided
> Status: New
>
> ** Attachment added: "poisson.py"
>
> https://bugs.launchpad.net/bugs/1083720/+attachment/3445290/+files/poisson.py
>
> --
> You received this bug notification because you are a member of DOLFIN
> Core Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1083720
>
> Title:
> replace() fails if the new function spaces have a different mesh
>
> Status in DOLFIN:
> New
>
> Bug description:
> I submit this bug report following Marie's suggestions on the related
> DOLFIN question
> (https://answers.launchpad.net/dolfin/+question/215120)
>
> DOLFIN crashes in the solve() routine after using replace() to replace
> the function spaces of a form.
>
> While the solve succeeds if replaced function spaces have:
> - a different polynomial degree or
> - a different polynomial degree and a different mesh,
> it does not work if the new function spaces is based on a new mesh only.
>
> This is the error message I get:
> ***
> -------------------------------------------------------------------------
> *** Error: Unable to define linear variational problem a(u, v) = L(v)
> for all v.
> *** Reason: Expecting the solution variable u to be a member of the
> trial space.
> *** Where: This error was encountered inside
> LinearVariationalProblem.cpp.
> ***
> ------------------------------------------------------------------------
>
> The attached file demonstrates the problem.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/1083720/+subscriptions
>

[Johan Hake (johan-hake)]

On 11/27/2012 07:31 PM, Martin Sandve Alnæs wrote:
> Probably a caching issue somewhere in the PyDolfin layer.

Isn't it always somewhere in the PyDolfin layer :)

> The form sigature is unaffected by the mesh.

Could it be that it is the formdata that need to be recomputed?

Johan

> Den 27. nov. 2012 19:15 skrev "Simon Funke" <email address hidden>
> følgende:
>
>> Public bug reported:
>>
>> I submit this bug report following Marie's suggestions on the related
>> DOLFIN question (https://answers.launchpad.net/dolfin/+question/215120)
>>
>> DOLFIN crashes in the solve() routine after using replace() to replace
>> the function spaces of a form.
>>
>> While the solve succeeds if replaced function spaces have:
>> - a different polynomial degree or
>> - a different polynomial degree and a different mesh,
>> it does not work if the new function spaces is based on a new mesh only.
>>
>> This is the error message I get:
>> ***
>> -------------------------------------------------------------------------
>> *** Error: Unable to define linear variational problem a(u, v) = L(v) for
>> all v.
>> *** Reason: Expecting the solution variable u to be a member of the trial
>> space.
>> *** Where: This error was encountered inside LinearVariationalProblem.cpp.
>> ***
>> ------------------------------------------------------------------------
>>
>> The attached file demonstrates the problem.
>>
>> ** Affects: dolfin
>> Importance: Undecided
>> Status: New
>>
>> ** Attachment added: "poisson.py"
>>
>> https://bugs.launchpad.net/bugs/1083720/+attachment/3445290/+files/poisson.py
>>
>> --
>> You received this bug notification because you are a member of DOLFIN
>> Core Team, which is subscribed to DOLFIN.
>> https://bugs.launchpad.net/bugs/1083720
>>
>> Title:
>> replace() fails if the new function spaces have a different mesh
>>
>> Status in DOLFIN:
>> New
>>
>> Bug description:
>> I submit this bug report following Marie's suggestions on the related
>> DOLFIN question
>> (https://answers.launchpad.net/dolfin/+question/215120)
>>
>> DOLFIN crashes in the solve() routine after using replace() to replace
>> the function spaces of a form.
>>
>> While the solve succeeds if replaced function spaces have:
>> - a different polynomial degree or
>> - a different polynomial degree and a different mesh,
>> it does not work if the new function spaces is based on a new mesh only.
>>
>> This is the error message I get:
>> ***
>> -------------------------------------------------------------------------
>> *** Error: Unable to define linear variational problem a(u, v) = L(v)
>> for all v.
>> *** Reason: Expecting the solution variable u to be a member of the
>> trial space.
>> *** Where: This error was encountered inside
>> LinearVariationalProblem.cpp.
>> ***
>> ------------------------------------------------------------------------
>>
>> The attached file demonstrates the problem.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/dolfin/+bug/1083720/+subscriptions
>>
>

[Martin Sandve Alnæs (martinal)]

The form data is not carried over to the new form returned by replace, so
no...
Den 27. nov. 2012 20:00 skrev "Johan Hake" <email address hidden>
følgende:

> On 11/27/2012 07:31 PM, Martin Sandve Alnæs wrote:
> > Probably a caching issue somewhere in the PyDolfin layer.
>
> Isn't it always somewhere in the PyDolfin layer :)
>
> > The form sigature is unaffected by the mesh.
>
> Could it be that it is the formdata that need to be recomputed?
>
> Johan
>
> > Den 27. nov. 2012 19:15 skrev "Simon Funke" <email address hidden>
> > følgende:
> >
> >> Public bug reported:
> >>
> >> I submit this bug report following Marie's suggestions on the related
> >> DOLFIN question (https://answers.launchpad.net/dolfin/+question/215120)
> >>
> >> DOLFIN crashes in the solve() routine after using replace() to replace
> >> the function spaces of a form.
> >>
> >> While the solve succeeds if replaced function spaces have:
> >> - a different polynomial degree or
> >> - a different polynomial degree and a different mesh,
> >> it does not work if the new function spaces is based on a new mesh only.
> >>
> >> This is the error message I get:
> >> ***
> >>
> -------------------------------------------------------------------------
> >> *** Error: Unable to define linear variational problem a(u, v) = L(v)
> for
> >> all v.
> >> *** Reason: Expecting the solution variable u to be a member of the
> trial
> >> space.
> >> *** Where: This error was encountered inside
> LinearVariationalProblem.cpp.
> >> ***
> >> ------------------------------------------------------------------------
> >>
> >> The attached file demonstrates the problem.
> >>
> >> ** Affects: dolfin
> >> Importance: Undecided
> >> Status: New
> >>
> >> ** Attachment added: "poisson.py"
> >>
> >>
> https://bugs.launchpad.net/bugs/1083720/+attachment/3445290/+files/poisson.py
> >>
> >> --
> >> You received this bug notification because you are a member of DOLFIN
> >> Core Team, which is subscribed to DOLFIN.
> >> https://bugs.launchpad.net/bugs/1083720
> >>
> >> Title:
> >> replace() fails if the new function spaces have a different mesh
> >>
> >> Status in DOLFIN:
> >> New
> >>
> >> Bug description:
> >> I submit this bug report following Marie's suggestions on the related
> >> DOLFIN question
> >> (https://answers.launchpad.net/dolfin/+question/215120)
> >>
> >> DOLFIN crashes in the solve() routine after using replace() to replace
> >> the function spaces of a form.
> >>
> >> While the solve succeeds if replaced function spaces have:
> >> - a different polynomial degree or
> >> - a different polynomial degree and a different mesh,
> >> it does not work if the new function spaces is based on a new mesh
> only.
> >>
> >> This is the error message I get:
> >> ***
> >>
> -------------------------------------------------------------------------
> >> *** Error: Unable to define linear variational problem a(u, v) = L(v)
> >> for all v.
> >> *** Reason: Expecting the solution variable u to be a member of the
> >> trial space.
> >> *** Where: This error was encountered inside
> >> LinearVariationalProblem.cpp.
> >> ***
> >> ------------------------------------...

[Martin Sandve Alnæs (martinal)]

Have you tried replacing all the coefficients as well, e.g. creating a new Constant for the other form? I can take a closer look tomorrow.

[Johan Hake (johan-hake)]

On 11/27/2012 09:04 PM, Martin Sandve Alnæs wrote:
> The form data is not carried over to the new form returned by replace, so
> no...

:)

It actually looks like it is replace or compute_form_data that is not
doing its job. If you add the following lines:

form_data = F_fine.compute_form_data()

print [V_fine == func.function_space() for func in
form_data.original_arguments]
print [V == func.function_space() for func in form_data.original_arguments]

after:
F_fine = replace(F, {u:u_fine, v:v_fine})

you see that it is still the original functionspace that is used.

Johan

> Den 27. nov. 2012 20:00 skrev "Johan Hake" <email address hidden>
> følgende:
>
>> On 11/27/2012 07:31 PM, Martin Sandve Alnæs wrote:
>>> Probably a caching issue somewhere in the PyDolfin layer.
>>
>> Isn't it always somewhere in the PyDolfin layer :)
>>
>>> The form sigature is unaffected by the mesh.
>>
>> Could it be that it is the formdata that need to be recomputed?
>>
>> Johan
>>
>>> Den 27. nov. 2012 19:15 skrev "Simon Funke" <email address hidden>
>>> følgende:
>>>
>>>> Public bug reported:
>>>>
>>>> I submit this bug report following Marie's suggestions on the related
>>>> DOLFIN question (https://answers.launchpad.net/dolfin/+question/215120)
>>>>
>>>> DOLFIN crashes in the solve() routine after using replace() to replace
>>>> the function spaces of a form.
>>>>
>>>> While the solve succeeds if replaced function spaces have:
>>>> - a different polynomial degree or
>>>> - a different polynomial degree and a different mesh,
>>>> it does not work if the new function spaces is based on a new mesh only.
>>>>
>>>> This is the error message I get:
>>>> ***
>>>>
>> -------------------------------------------------------------------------
>>>> *** Error: Unable to define linear variational problem a(u, v) = L(v)
>> for
>>>> all v.
>>>> *** Reason: Expecting the solution variable u to be a member of the
>> trial
>>>> space.
>>>> *** Where: This error was encountered inside
>> LinearVariationalProblem.cpp.
>>>> ***
>>>> ------------------------------------------------------------------------
>>>>
>>>> The attached file demonstrates the problem.
>>>>
>>>> ** Affects: dolfin
>>>> Importance: Undecided
>>>> Status: New
>>>>
>>>> ** Attachment added: "poisson.py"
>>>>
>>>>
>> https://bugs.launchpad.net/bugs/1083720/+attachment/3445290/+files/poisson.py
>>>>
>>>> --
>>>> You received this bug notification because you are a member of DOLFIN
>>>> Core Team, which is subscribed to DOLFIN.
>>>> https://bugs.launchpad.net/bugs/1083720
>>>>
>>>> Title:
>>>> replace() fails if the new function spaces have a different mesh
>>>>
>>>> Status in DOLFIN:
>>>> New
>>>>
>>>> Bug description:
>>>> I submit this bug report following Marie's suggestions on the related
>>>> DOLFIN question
>>>> (https://answers.launchpad.net/dolfin/+question/215120)
>>>>
>>>> DOLFIN crashes in the solve() routine after using replace() to replace
>>>> the function spaces of a form.
>>>>
>>>> While the solve succeeds if replaced function spaces have:
>>>> - a different polynomial degree or
>>>> - a different polynomial degree and a different mesh,
>>>> it does not work ...

[Martin Sandve Alnæs (martinal)]

I think I know... Create an Argument instead of TestFunction and it should
work fine.
Den 27. nov. 2012 21:55 skrev "Johan Hake" <email address hidden>
følgende:

> On 11/27/2012 09:04 PM, Martin Sandve Alnæs wrote:
> > The form data is not carried over to the new form returned by replace, so
> > no...
>
> :)
>
> It actually looks like it is replace or compute_form_data that is not
> doing its job. If you add the following lines:
>
> form_data = F_fine.compute_form_data()
>
> print [V_fine == func.function_space() for func in
> form_data.original_arguments]
> print [V == func.function_space() for func in form_data.original_arguments]
>
> after:
> F_fine = replace(F, {u:u_fine, v:v_fine})
>
> you see that it is still the original functionspace that is used.
>
> Johan
>
> > Den 27. nov. 2012 20:00 skrev "Johan Hake" <email address hidden>
> > følgende:
> >
> >> On 11/27/2012 07:31 PM, Martin Sandve Alnæs wrote:
> >>> Probably a caching issue somewhere in the PyDolfin layer.
> >>
> >> Isn't it always somewhere in the PyDolfin layer :)
> >>
> >>> The form sigature is unaffected by the mesh.
> >>
> >> Could it be that it is the formdata that need to be recomputed?
> >>
> >> Johan
> >>
> >>> Den 27. nov. 2012 19:15 skrev "Simon Funke" <email address hidden>
> >>> følgende:
> >>>
> >>>> Public bug reported:
> >>>>
> >>>> I submit this bug report following Marie's suggestions on the related
> >>>> DOLFIN question (
> https://answers.launchpad.net/dolfin/+question/215120)
> >>>>
> >>>> DOLFIN crashes in the solve() routine after using replace() to replace
> >>>> the function spaces of a form.
> >>>>
> >>>> While the solve succeeds if replaced function spaces have:
> >>>> - a different polynomial degree or
> >>>> - a different polynomial degree and a different mesh,
> >>>> it does not work if the new function spaces is based on a new mesh
> only.
> >>>>
> >>>> This is the error message I get:
> >>>> ***
> >>>>
> >>
> -------------------------------------------------------------------------
> >>>> *** Error: Unable to define linear variational problem a(u, v) = L(v)
> >> for
> >>>> all v.
> >>>> *** Reason: Expecting the solution variable u to be a member of the
> >> trial
> >>>> space.
> >>>> *** Where: This error was encountered inside
> >> LinearVariationalProblem.cpp.
> >>>> ***
> >>>>
> ------------------------------------------------------------------------
> >>>>
> >>>> The attached file demonstrates the problem.
> >>>>
> >>>> ** Affects: dolfin
> >>>> Importance: Undecided
> >>>> Status: New
> >>>>
> >>>> ** Attachment added: "poisson.py"
> >>>>
> >>>>
> >>
> https://bugs.launchpad.net/bugs/1083720/+attachment/3445290/+files/poisson.py
> >>>>
> >>>> --
> >>>> You received this bug notification because you are a member of DOLFIN
> >>>> Core Team, which is subscribed to DOLFIN.
> >>>> https://bugs.launchpad.net/bugs/1083720
> >>>>
> >>>> Title:
> >>>> replace() fails if the new function spaces have a different mesh
> >>>>
> >>>> Status in DOLFIN:
> >>>> New
> >>>>
> >>>> Bug description:
> >>>> I submit this bug report following Marie's suggestions on the
> related
> >>>> DOLFIN question
> >>>> (https://answers...

[Martin Sandve Alnæs (martinal)]

Here's a workaround:

Replace

u_fine = TrialFunction(V_fine)
v_fine = TestFunction(V_fine)

with

v_fine = Argument(V_fine)
u_fine = Argument(V_fine)

and it works fine.

Note that it's important that the test function is created before the trial function when using Argument, or you'll make the transpose when assembling the matrix.

The reason for this is that Test/TrialF. are simple hacks that fix the count (i.e. the identifier of the argument) to -2/-1 such that they get the right internal ordering. When the ufl element is the same, they compare equal from a ufl point of view and are reused in the replace algorithm. Specifically, since v_fine == v at the ufl representation level, grad(v) is reused instead of constructing grad(v_fine). This is not a problem for Functions, because they get unique counts identifying them.

I think I have a solution, but use the above workaround in the meantime.

[Simon Funke (simon-funke)]

Hi Martin,

I tried your workaround and it does indeed work.
I attached the working poisson.py as a reference.

Thanks for the help so far.

Simon

[Martin Sandve Alnæs (martinal)]

I fixed this permanently by constructing both test and trial function simultaneously on demand using Argument(V) and storing them to V._argument_functions. Will the circular references "functionspace <-> testfunction" be a problem for garbage collection?

[Johan Hake (johan-hake)]

On 11/28/2012 07:15 PM, Martin Sandve Alnæs wrote:
> I fixed this permanently by constructing both test and trial function
> simultaneously on demand using Argument(V) and storing them to
> V._argument_functions. Will the circular references "functionspace <->
> testfunction" be a problem for garbage collection?

Yes.

I wonder how this can be implemented without some error prone
heuristics. A robust, but quite intrusive way, would be to always
instantiate a TestFunction together with a TrialFunction whenever one
need the latter.

Or one could introduce a trial and test space specific counter.
Something like:

class Argument(.):
   _test_and_trial_counters = [dict(test=False, trial=False)]
   ...

class TestFunction(.):
    def __init__(.):
        .
        counters = Argument._test_and_trial_counters
        if counters[-1]["test"]:
            counters.append(dict(test=False, trial=False))
        counters[-1]["test"] = True
        Argument(self, ., count=len(counters)*2)

class TrialFunction(.):
    def __init__(.):
        .
        counters = Argument._test_and_trial_counters
        if counters[-1]["trial"]:
            counters.append(dict(test=False, trial=False))
        counters[-1]["trial"] = True
        Argument(self, ., count=len(counters)*2-1)

Johan

[Martin Sandve Alnæs (martinal)]

I think I got a slightly simpler idea based on your test/trial counter
idea. Just need to think it through. Will attempt to implement it tomorrow.

On 28 November 2012 20:03, Johan Hake <email address hidden> wrote:

> On 11/28/2012 07:15 PM, Martin Sandve Alnæs wrote:
> > I fixed this permanently by constructing both test and trial function
> > simultaneously on demand using Argument(V) and storing them to
> > V._argument_functions. Will the circular references "functionspace <->
> > testfunction" be a problem for garbage collection?
>
> Yes.
>
> I wonder how this can be implemented without some error prone
> heuristics. A robust, but quite intrusive way, would be to always
> instantiate a TestFunction together with a TrialFunction whenever one
> need the latter.
>
> Or one could introduce a trial and test space specific counter.
> Something like:
>
> class Argument(.):
> _test_and_trial_counters = [dict(test=False, trial=False)]
> ...
>
> class TestFunction(.):
> def __init__(.):
> .
> counters = Argument._test_and_trial_counters
> if counters[-1]["test"]:
> counters.append(dict(test=False, trial=False))
> counters[-1]["test"] = True
> Argument(self, ., count=len(counters)*2)
>
> class TrialFunction(.):
> def __init__(.):
> .
> counters = Argument._test_and_trial_counters
> if counters[-1]["trial"]:
> counters.append(dict(test=False, trial=False))
> counters[-1]["trial"] = True
> Argument(self, ., count=len(counters)*2-1)
>
> Johan
>
> --
> You received this bug notification because you are a member of DOLFIN
> Core Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1083720
>
> Title:
> replace() fails if the new function spaces have a different mesh
>
> Status in DOLFIN:
> Fix Committed
>
> Bug description:
> I submit this bug report following Marie's suggestions on the related
> DOLFIN question
> (https://answers.launchpad.net/dolfin/+question/215120)
>
> DOLFIN crashes in the solve() routine after using replace() to replace
> the function spaces of a form.
>
> While the solve succeeds if replaced function spaces have:
> - a different polynomial degree or
> - a different polynomial degree and a different mesh,
> it does not work if the new function spaces is based on a new mesh only.
>
> This is the error message I get:
> ***
> -------------------------------------------------------------------------
> *** Error: Unable to define linear variational problem a(u, v) = L(v)
> for all v.
> *** Reason: Expecting the solution variable u to be a member of the
> trial space.
> *** Where: This error was encountered inside
> LinearVariationalProblem.cpp.
> ***
> ------------------------------------------------------------------------
>
> The attached file demonstrates the problem.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/1083720/+subscriptions
>

[Joachim Haga (jobh)]

>> Will the circular references "functionspace <->
>> testfunction" be a problem for garbage collection?
>
> Yes.

I am not familiar with the particulars here, but the circular
references are only a problem if the objects have custom deleters
(__del__ methods). Swig likes to generate (empty) __del__ methods, but
they can be disabled by the should-have-been-default flag
--noproxydel.

-j.

On 28 November 2012 20:03, Johan Hake <email address hidden> wrote:
> On 11/28/2012 07:15 PM, Martin Sandve Alnæs wrote:
>> I fixed this permanently by constructing both test and trial function
>> simultaneously on demand using Argument(V) and storing them to
>> V._argument_functions. Will the circular references "functionspace <->
>> testfunction" be a problem for garbage collection?
>
> Yes.
>
> I wonder how this can be implemented without some error prone
> heuristics. A robust, but quite intrusive way, would be to always
> instantiate a TestFunction together with a TrialFunction whenever one
> need the latter.
>
> Or one could introduce a trial and test space specific counter.
> Something like:
>
> class Argument(.):
> _test_and_trial_counters = [dict(test=False, trial=False)]
> ...
>
> class TestFunction(.):
> def __init__(.):
> .
> counters = Argument._test_and_trial_counters
> if counters[-1]["test"]:
> counters.append(dict(test=False, trial=False))
> counters[-1]["test"] = True
> Argument(self, ., count=len(counters)*2)
>
> class TrialFunction(.):
> def __init__(.):
> .
> counters = Argument._test_and_trial_counters
> if counters[-1]["trial"]:
> counters.append(dict(test=False, trial=False))
> counters[-1]["trial"] = True
> Argument(self, ., count=len(counters)*2-1)
>
> Johan
>
> --
> You received this bug notification because you are a member of DOLFIN
> Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1083720
>
> Title:
> replace() fails if the new function spaces have a different mesh
>
> Status in DOLFIN:
> Fix Committed
>
> Bug description:
> I submit this bug report following Marie's suggestions on the related
> DOLFIN question
> (https://answers.launchpad.net/dolfin/+question/215120)
>
> DOLFIN crashes in the solve() routine after using replace() to replace
> the function spaces of a form.
>
> While the solve succeeds if replaced function spaces have:
> - a different polynomial degree or
> - a different polynomial degree and a different mesh,
> it does not work if the new function spaces is based on a new mesh only.
>
> This is the error message I get:
> *** -------------------------------------------------------------------------
> *** Error: Unable to define linear variational problem a(u, v) = L(v) for all v.
> *** Reason: Expecting the solution variable u to be a member of the trial space.
> *** Where: This error was encountered inside LinearVariationalProblem.cpp.
> *** ------------------------------------------------------------------------
>
> The attached file demonstrates the problem.
>
> To manage notifications about this bug go to:
> https://bugs.launchp...

[Martin Sandve Alnæs (martinal)]

I have pushed an alternative fix to lp:~martinal/dolfin/work,
but I'm not yet comfortable pushing it to trunk. It would be nice
if the buildbot got green again sometime soon...

On 28 November 2012 20:58, Joachim Haga <email address hidden> wrote:

> >> Will the circular references "functionspace <->
> >> testfunction" be a problem for garbage collection?
> >
> > Yes.
>
> I am not familiar with the particulars here, but the circular
> references are only a problem if the objects have custom deleters
> (__del__ methods). Swig likes to generate (empty) __del__ methods, but
> they can be disabled by the should-have-been-default flag
> --noproxydel.
>
> -j.
>
> On 28 November 2012 20:03, Johan Hake <email address hidden> wrote:
> > On 11/28/2012 07:15 PM, Martin Sandve Alnæs wrote:
> >> I fixed this permanently by constructing both test and trial function
> >> simultaneously on demand using Argument(V) and storing them to
> >> V._argument_functions. Will the circular references "functionspace <->
> >> testfunction" be a problem for garbage collection?
> >
> > Yes.
> >
> > I wonder how this can be implemented without some error prone
> > heuristics. A robust, but quite intrusive way, would be to always
> > instantiate a TestFunction together with a TrialFunction whenever one
> > need the latter.
> >
> > Or one could introduce a trial and test space specific counter.
> > Something like:
> >
> > class Argument(.):
> > _test_and_trial_counters = [dict(test=False, trial=False)]
> > ...
> >
> > class TestFunction(.):
> > def __init__(.):
> > .
> > counters = Argument._test_and_trial_counters
> > if counters[-1]["test"]:
> > counters.append(dict(test=False, trial=False))
> > counters[-1]["test"] = True
> > Argument(self, ., count=len(counters)*2)
> >
> > class TrialFunction(.):
> > def __init__(.):
> > .
> > counters = Argument._test_and_trial_counters
> > if counters[-1]["trial"]:
> > counters.append(dict(test=False, trial=False))
> > counters[-1]["trial"] = True
> > Argument(self, ., count=len(counters)*2-1)
> >
> > Johan
> >
> > --
> > You received this bug notification because you are a member of DOLFIN
> > Team, which is subscribed to DOLFIN.
> > https://bugs.launchpad.net/bugs/1083720
> >
> > Title:
> > replace() fails if the new function spaces have a different mesh
> >
> > Status in DOLFIN:
> > Fix Committed
> >
> > Bug description:
> > I submit this bug report following Marie's suggestions on the related
> > DOLFIN question
> > (https://answers.launchpad.net/dolfin/+question/215120)
> >
> > DOLFIN crashes in the solve() routine after using replace() to replace
> > the function spaces of a form.
> >
> > While the solve succeeds if replaced function spaces have:
> > - a different polynomial degree or
> > - a different polynomial degree and a different mesh,
> > it does not work if the new function spaces is based on a new mesh
> only.
> >
> > This is the error message I get:
> > ***
> -------------------------------------------------------------------------
> > *** Error: Unable to define lin...

[Johan Hake (johan-hake)]

On 11/28/2012 08:58 PM, Joachim Haga wrote:
>>> Will the circular references "functionspace <->
>>> testfunction" be a problem for garbage collection?
>>
>> Yes.
>
> I am not familiar with the particulars here, but the circular
> references are only a problem if the objects have custom deleters
> (__del__ methods). Swig likes to generate (empty) __del__ methods, but
> they can be disabled by the should-have-been-default flag
> --noproxydel.

Ok, nice to know. Also see:

http://stackoverflow.com/questions/2428301/should-i-worry-about-circular-references-in-python

for some nice references.

It also seems like none of the classes implements __del__ so in theory
we should be fine. The thread above do mention possible slowness in
performance in these type of garbage collections, but I guess that would
be for larger chain of circular references?

You could also use weak refs I guess, or just implement the test/trial
count discussed later in the thread.

Johan

> -j.
>
> On 28 November 2012 20:03, Johan Hake <email address hidden> wrote:
>> On 11/28/2012 07:15 PM, Martin Sandve Alnæs wrote:
>>> I fixed this permanently by constructing both test and trial function
>>> simultaneously on demand using Argument(V) and storing them to
>>> V._argument_functions. Will the circular references "functionspace <->
>>> testfunction" be a problem for garbage collection?
>>
>> Yes.
>>
>> I wonder how this can be implemented without some error prone
>> heuristics. A robust, but quite intrusive way, would be to always
>> instantiate a TestFunction together with a TrialFunction whenever one
>> need the latter.
>>
>> Or one could introduce a trial and test space specific counter.
>> Something like:
>>
>> class Argument(.):
>> _test_and_trial_counters = [dict(test=False, trial=False)]
>> ...
>>
>> class TestFunction(.):
>> def __init__(.):
>> .
>> counters = Argument._test_and_trial_counters
>> if counters[-1]["test"]:
>> counters.append(dict(test=False, trial=False))
>> counters[-1]["test"] = True
>> Argument(self, ., count=len(counters)*2)
>>
>> class TrialFunction(.):
>> def __init__(.):
>> .
>> counters = Argument._test_and_trial_counters
>> if counters[-1]["trial"]:
>> counters.append(dict(test=False, trial=False))
>> counters[-1]["trial"] = True
>> Argument(self, ., count=len(counters)*2-1)
>>
>> Johan
>>
>> --
>> You received this bug notification because you are a member of DOLFIN
>> Team, which is subscribed to DOLFIN.
>> https://bugs.launchpad.net/bugs/1083720
>>
>> Title:
>> replace() fails if the new function spaces have a different mesh
>>
>> Status in DOLFIN:
>> Fix Committed
>>
>> Bug description:
>> I submit this bug report following Marie's suggestions on the related
>> DOLFIN question
>> (https://answers.launchpad.net/dolfin/+question/215120)
>>
>> DOLFIN crashes in the solve() routine after using replace() to replace
>> the function spaces of a form.
>>
>> While the solve succeeds if replaced function spaces have:
>> - a different polynomial degree or
>> - a different polynomial degree and a different mesh...

[Martin Sandve Alnæs (martinal)]

I had to revert the change I did yesterday, we cannot make test/trial
functions with different counts than -1/-2 without breaking a lot of code.
In particular, it won't work with test/trial functions in different spaces.
So we're back to square one, and the conclusion is that these fixed counts
are evil, but that can't be fixed with more index trickery.

On 29 November 2012 13:22, Johan Hake <email address hidden> wrote:

> On 11/28/2012 08:58 PM, Joachim Haga wrote:
> >>> Will the circular references "functionspace <->
> >>> testfunction" be a problem for garbage collection?
> >>
> >> Yes.
> >
> > I am not familiar with the particulars here, but the circular
> > references are only a problem if the objects have custom deleters
> > (__del__ methods). Swig likes to generate (empty) __del__ methods, but
> > they can be disabled by the should-have-been-default flag
> > --noproxydel.
>
> Ok, nice to know. Also see:
>
> http://stackoverflow.com/questions/2428301/should-i-worry-about-
> circular-references-in-python
>
> for some nice references.
>
> It also seems like none of the classes implements __del__ so in theory
> we should be fine. The thread above do mention possible slowness in
> performance in these type of garbage collections, but I guess that would
> be for larger chain of circular references?
>
> You could also use weak refs I guess, or just implement the test/trial
> count discussed later in the thread.
>
> Johan
>
> > -j.
> >
> > On 28 November 2012 20:03, Johan Hake <email address hidden>
> wrote:
> >> On 11/28/2012 07:15 PM, Martin Sandve Alnæs wrote:
> >>> I fixed this permanently by constructing both test and trial function
> >>> simultaneously on demand using Argument(V) and storing them to
> >>> V._argument_functions. Will the circular references "functionspace <->
> >>> testfunction" be a problem for garbage collection?
> >>
> >> Yes.
> >>
> >> I wonder how this can be implemented without some error prone
> >> heuristics. A robust, but quite intrusive way, would be to always
> >> instantiate a TestFunction together with a TrialFunction whenever one
> >> need the latter.
> >>
> >> Or one could introduce a trial and test space specific counter.
> >> Something like:
> >>
> >> class Argument(.):
> >> _test_and_trial_counters = [dict(test=False, trial=False)]
> >> ...
> >>
> >> class TestFunction(.):
> >> def __init__(.):
> >> .
> >> counters = Argument._test_and_trial_counters
> >> if counters[-1]["test"]:
> >> counters.append(dict(test=False, trial=False))
> >> counters[-1]["test"] = True
> >> Argument(self, ., count=len(counters)*2)
> >>
> >> class TrialFunction(.):
> >> def __init__(.):
> >> .
> >> counters = Argument._test_and_trial_counters
> >> if counters[-1]["trial"]:
> >> counters.append(dict(test=False, trial=False))
> >> counters[-1]["trial"] = True
> >> Argument(self, ., count=len(counters)*2-1)
> >>
> >> Johan
> >>
> >> --
> >> You received this bug notification because you are a member of DOLFIN
> >> Team, which is subscribed to DOLFIN.
> >> https://bugs.launchpad.net/bugs/1083720
> >>
>...

[Martin Sandve Alnæs (martinal)]

Finally I think I've fixed it the right way, the original poisson.py above works, tests pass. This was a tricky one :)

[Simon Funke (simon-funke)]

I tried the new implementation in my particular application and it works fine.

Thanks for your effort and the fix.