dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #24110
Re: 1.0-beta
-
To:
Anders Logg <logg@xxxxxxxxx>
-
From:
"Garth N. Wells" <gnw20@xxxxxxxxx>
-
Date:
Mon, 11 Jul 2011 11:51:03 +0100
-
Cc:
dolfin@xxxxxxxxxxxxxxxxxxx
-
In-reply-to:
<20110710114540.GB23814@smaug>
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
On 10/07/11 12:45, Anders Logg wrote:
> On Sun, Jul 10, 2011 at 10:56:02AM +0100, Garth N. Wells wrote:
>>
>>
>> On 10/07/11 10:08, Anders Logg wrote:
>>> On Thu, Jul 07, 2011 at 02:44:20PM -0700, Johan Hake wrote:
>>>> On Thursday July 7 2011 12:21:26 Anders Logg wrote:
>>>>> On Thu, Jul 07, 2011 at 02:20:44PM +0200, Marie E. Rognes wrote:
>>>>>> Is the plan for 1.0-beta to fix
>>>>>>
>>>>>> https://bugs.launchpad.net/ffc/+bug/787010
>>>>>>
>>>>>> and then release?
>>>>>
>>>>> Yes + decide on the interface for NonlinearVariationalProblem.
>>>>>
>>>>> I think that should be all.
>>>>>
>>>>> It would be good to hear more comments on the two suggestions:
>>>>>
>>>>> 1. (current)
>>>>>
>>>>> NonlinearVariationalProblen(lhs, rhs, u, bcs, [J])
>>>>>
>>>>> This is consistent with LinearVariationalProblem and the solve()
>>>>> functions; same order of arguments.
>>>>>
>>>>> 2. (Garth)
>>>>>
>>>>> NonlinearVariationalProblen(lhs, u, bcs, [J])
>>>>>
>>>>> This removes the unnecessary rhs argument which always has to be
>>>>> zero.
>>>>>
>>>>> I think there are good arguments for both but not very strong so it's
>>>>> a matter of taste.
>>>>
>>>> If:
>>>>
>>>> The point is that it makes the interface for all variational problems
>>>> (linear or nonlinear) the same:
>>>>
>>>> is the only reason, I go with Garth.
>>>
>>> Another reason is complications in the implementation, both in C++ and
>>> the Python layer. Nothing I can't handle but it leads to complications.
>>> I have started to implement it but it's looking messy.
>>>
>>> I also would like to keep the set_jacobian function. The constructors
>>> will otherwise be a mess: there will be very many constructors with
>>> varying order of arguments which is both error prone and tedious to
>>> implement/maintain.
>>>
>>
>> How is it error prone when each argument is a different type and can be
>> check at compile time?
>
> There would still be an error, even if it is caught by a check (at
> compile-time or run-time depending on whether C++ or Python is used).
>
> I claim it's less error prone (=less likely to cause errors, some of
> which may be caught) since users will learn the one common signature
> used by both Linear/NonlinearVariationalProblem and the solve() functions:
>
> lhs, rhs, solution, [bcs]
>
>>> We would need the following variations of constructors for linear and
>>> nonlinear variational problems:
>>>
>>> a, L, u
>>> a, L, u, bc
>>> a, L, u, bcs
>>> F, u
>>> F, u, J
>>> F, u, bc
>>> F, u, bc, J
>>> F, u, bcs
>>> F, u, bcs, J
>>
>>> Instead of one common signature:
>>>
>>> lhs, rhs, u, [bcs]
>>>
>>> Of course there will still need to be some variations to implement,
>>> but those are only handling various ways to specify the boundary
>>> conditions, either none, bc or bcs.
>>>
>>> The advantage is clarity: only needing to remember lhs, rhs, u, [bcs].
>>>
>>
>> I would argue the opposite; requiring a pointless function argument is
>> confusing.
>>
>> If it's too greater burden to provide all the above constructors, the
>> number of constructors can be rationalised.
>
> Exactly how do you propose to rationalize it?
>
Always provide a vector/list of bcs:
a, L, u, bcs
F, u, bcs, J = 0
>From the Python side, the empty list syntax is particularly neat,
pde = LinearVariationalProblem(a, L, u, [])
Garth
> --
> Anders
Follow ups
References