Posted by
Peter Caspers-2 on
May 12, 2012; 5:24pm
URL: http://quantlib.414.s1.nabble.com/fd-questions-ctd-tp12480p12484.html
Hi Klaus,
yes, I totally agree. Concerning the time dependent Dirichlet bc I guess
one should insert a
bc->setTime( t );
before each call of applyAfterApplying(Array&),
applyAfterSolving(Array&) or applyAfterApplying(Real,Real) to ensure
that valueOnBoundaryTimeDep_ / valuesOnBoundaryTimeDep_ are correctly
set. No?
Concerning the Neumann bc, I was too optimistic about what has to be
done to adapt the existing operators. You are right, it is not enough to
provide discretizations for the base operators in the general case. It
works fine in my toy example but it is useless otherwise. Sorry I should
have spent some more thoughts on this.
I will be happy if you find the Dirichlet bc extension useful and add it
to the SVN. I will also continue to think about the Neumann bc and try
to send more useful code next time ;-)
thank you again and regards
Peter
Am 10.05.2012 23:16, schrieb Klaus Spanderen:
> Hi Peter,
>
> cool stuff. The Dirichlet bc was introduced to implement barrier options only.
> Your time dependent code the right step forward..and yes, the implementation
> of the schemes is based on either free bc's or non time dependent Dirichlet
> bc's. This is also the main reason why FdmBoundaryConditionSet is linked to
> FdmDirichletBoundary instead of OperatorTraits<FdmLinearOp>::bc_set. One
> think we still need to do is to make
>
> FdmDirichletBoundary::applyAfterApplying(Real x, Real value) const;
>
> time dependent as well.
>
> As you have written It's difficult to implement the Neumann bc in a general
> manner for the multi dimensional framework. In the one dim. framework all
> linear operators are tridiagonal operators and the Neumann bc is "doable". I
> have no idea how to translate this idea into the multi dimensional case
> except implementing the Neumann bc for all 10+ operators individually. (hmm..
> I don't think it is enough to do this for the three basis operators alone).
>
>> Needless to say that I am totally not sure if I did that correctly.
> good question. I haven't seen much in the literature on the topic "Neumann bc
> and operator splitting". I think we'll also at least need to call
> applyBeforeSolving in the schemes for the Neumann bc case.
>
> IMO the Neumann bc task will take a bit longer. Shall we first lift the time
> dependent Dirichlet bc to the QL 1.2 file structure and add this to SVN?
>
> regards
> Klaus
>
>
> On Sunday 06 May 2012 21:24:39 Peter Caspers wrote:
>> Hallo Klaus,
>>
>> thanks a lot for your answers. I implemented a Neumann condition for the
>> multidimensional case. I tested the new class against known solutions
>> for the 1d heat equation with Neumann and mixed lower Dirichlet / upper
>> Neumann conditions using some of the existing multidim schemes. The
>> results suggest that the implementation is ok. Also, the testsuite runs
>> without problems which is good I guess.
>>
>> However, I could not see how to implement the condition by changing the
>> final operator directly as done in the 1d framework. Instead I added
>> functionality to change the discretization of multidim operators from
>> default = FreeBoundary to Neumann by adding a method
>>
>> void FdmLinearOp::discretization(Size direction, Discretization d);
>>
>> The enum DiscretizationType in the same class can be used to specify a
>> Neumann discretization together with the side (using bitwise or; this
>> could be extended for other boundary conditions later). The method calls
>> another protected virtual method changeDiscretization(...) which should
>> be implemented by user defined operators. I did not do that for the
>> existing operators yet (in case I am on the wrong road with my
>> approach), but rather added a test operator FdmHeat1dOp (representing
>> the pde u_t = \alpha u_xx) which demonstrates the principle. The
>> required extension of operators can easily be done being supported by
>> extended constructors of the 'basis' operators (first, second and mixed
>> second derivatives) allowing for Neumann discretization now. I think I
>> did that discretization in the standard way, but it should be cross
>> checked.
>>
>> I amended the scheme implementations w.r.t. their calls to the
>> apply...() methods having the impression that these accounted for the
>> Dirichlet case only so far. Needless to say that I am totally not sure
>> if I did that correctly. Since I also extended the Dirichlet condition
>> to the time (and spatial) dependent case, I inserted the needed
>> setTime() calls in the schemes accordingly. In the Dirichlet condition
>> itself I implemented the applyBeforeSolving() method because I think it
>> is necessary for the time dependent case (and comparisions to known 1d
>> heat equation solutions do confirm this).
>>
>> I removed the FdmBoundaryConditionSet typedef from the multidim
>> Dirichlet condition, instead refering to
>> OperatorTraits<FdmLinearOp>::bc_set in the schemes, solvers, engines and
>> operators now. There is a applyAfterApplying(Real,Real) method in the
>> Dirichlet condition (used in some engine I think) which I added to the
>> general interface (by default throwing an exception to ensure that only
>> the implementation in the Dirichlet boundary is actually used).
>>
>> Finally I amended the concentrating1dmesher once again because I noted
>> that it throws an exception when QL_EXTRA_SAFETY_CHECKS are enabled and
>> the concentrating point is equal to one of the endpoints (this having to
>> do with an extra check concerning the strict order of x values in
>> interpolation.hpp).
>>
>> I attach my changes (zips with changed files as per directory and new
>> files attached directly, all based on ql 1.1) and would be happy if you
>> could have a look.
>>
>> Thank you
>> Peter
>>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev