dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #24108
Re: 1.0-beta
-
To:
dolfin@xxxxxxxxxxxxxxxxxxx
-
From:
"Garth N. Wells" <gnw20@xxxxxxxxx>
-
Date:
Sun, 10 Jul 2011 10:56:02 +0100
-
In-reply-to:
<20110710090834.GA23814@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 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?
> 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.
Garth
> --
> Anders
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help : https://help.launchpad.net/ListHelp
Follow ups
References