Posted by
Luigi Ballabio-4 on
Oct 05, 2001; 8:58am
URL: http://quantlib.414.s1.nabble.com/Docs-requesting-peer-review-tp1768p1772.html
Nicolas,
At 03:27 PM 10/5/01 +0200, Nicolas Di C=E9sar=E9 wrote:
>I have worked on a similar design for finite element
>method applied to stationnary equations (like Laplace or Poisson equations)
>that can be view as backward Euler equation. My conclusion was that=
boundary
>conditions (BC) can modify the equation operator and the right hand side=20
>(RHS)
>of the equation. Thus, the BC base class interface is :
>
>template <class Vec, class Mat>
>class BaseBdyCondition {
>public:
> virtual
> void applyTo(const Vec& bdyval, // BC values
> Mat & sparsemat, // Matrix representation of the operator
> Vec & systemrhs) // RHS
> =3D 0;
>
>};
I've been thinking along the same lines lately---although without coming to=
=20
your design, which I think covers the whole picture---and I completely=
agree.
This way we could also pass boundary conditions to the model itself rather=
=20
than setting them to the operator, which kind of makes more sense to me. I=
=20
usually picture to myself boundary conditions as part of the model together=
=20
with the operator, rather than part of the model itself. Of course I'm open=
=20
to corrections on this matter.
Also, this makes me think of passing to the model a function object as well=
=20
which would describe the pay off and would be used to set the initial=20
condition, rather than discretize the latter manually. Now that I think of=
=20
it, that would mean passing the grid as well.
Bottom line: apart from the initial condition thing which needs a bit more=
=20
thinking, if nobody disagrees with your design, I'll put in the todo list.
Bye,
Luigi