[Trilinos-Users] [EXTERNAL] Running Rythmos DAE with a user defined Epetra_Operator as Jacobian

Andrea Mola amola at sissa.it
Thu May 22 12:35:47 MDT 2014

Dear all,
I am continuing to struggle in implementing a Rythmos DAE. As previously 
suggested in this thread, I have converted the EpetraExt::ModelEvaluator 
to a Thyra::ModelEvaluator, and managed to run Rythmos with a 
user-defined Epetra_Operator as Jacobian.
Unfortunately, I still haven't had success in using a used-defined 
Epetra_Operator as Jacobian preconditioner.
Within my Thyra::ModelEvaluator, I define a Thyra::linearOpWithSolve and 
initialize it with the initializePreconditionedOp method so as to 
specify my own preconditioner. If I try a "test run" for the resulting 
linear system with solve, it works correctly and the preconditioner 
matrix-vector (the Apply member of the preconditioner Epetra_Operator) 
is correctly called multiple times during the system resolution.
But for some reason, during the time integration Rythmos is completely 
ignoring the preconditioner, and the corresponding matrix-vector product 
is never called. The OutArgs of my Thyra::ModelEvaluator support W, 
W_op, and W_prec. I thought that maybe I should re-initialize 
linearOpWithSolve at each evaluation. But this is not even possible, 
since the W and W_prec pointers assigned during the time integration to 
the evalModel function are always null.
I initially thought that Eric's concerns regarding the user defined 
preconditioner in Rythmos were only referred to 
EpetraExt::ModelEvaluator, but I am now afraid that they were also 
referred to the Thyra class. So is there a way to provide a user-defined 
preconditioner to Rythmos? Has anyone succeeded in doing that?
Thanks a lot for the help.


On 2014-05-05 18:34, Andrea Mola wrote:
> Eric,
> I am currently using version 11.2.3, but maybe the issue isn't there.
> I realized the problem was most likely my fault. The create_W method
> in the model evaluator class was returning an Epetra_CrsMatrix. I
> never called that method, so I din't know it was effectively used.
> Nonetheless, I now run into a further exception
> terminate called after throwing an instance of 'std::logic_error'
>   what():
> /home/amola/trilinos-11.2.3-Source/packages/thyra/adapters/epetraext/src/model_evaluator/Thyra_EpetraModelEvaluator.cpp:751:
> Throw number = 1
> Throw test that evaluated to true: !allFuncsWhereScaled
> Error, we can not currently handle epetra output objects that could
> not be scaled.  Special code will have to be added to handle this
> (i.e. using implicit diagonal and multiplied linear operators to
> implicitly do the scaling.
> which is maybe called because in my operator some methods are not 
> properly set.
> However, given the possible preconditioning problems you are hinting
> at, I'm converting everything into a Thyra model evaluator, as
> previously suggested by Roscoe.
> Thanks for the help.
>        Andrea
> On 2014-05-05 16:36, Phipps, Eric T wrote:
>> Andrea,
>> What version of Trilinos are you using?  I believe Andy Salinger 
>> recently
>> fixed some of these issues when using an Epetra_Operator generated 
>> from an
>> EpetraExt::ModelEvaluator in Rythmos.  However I believe those fixes 
>> are
>> only in the development branch which should be accessible from the 
>> public
>> git repository.  Even with the fix for the failed dynamic casts,
>> there may still be an issue with supplying a user-defined 
>> preconditioner
>> to Rythmos.
>> -Eric
>> On 5/5/14, 7:45 AM, "Andrea Mola" <amola at sissa.it> wrote:
>>> Dear all,
>>> I am trying to use Ryrhmos to solve a DAE system for the time
>>> advancement of a PDE system.
>>> So far, I have already been able to set up a small example which 
>>> solves
>>> correctly a small DAE using a Jacobian defined as an 
>>> Epetra_CrsMatrix.
>>> Unfortunately, I need to use a different Linear Operator, which I 
>>> define
>>> as an Epetra_Operator (JacobianOperator :public Epetra_Operator). The
>>> problem comes when I define my AztecOOLinearOpWithSolveFactory to be
>>> passed to my EpetraExt::ModelEvaluator constructor. Even though I try 
>>> to
>>> specify through the Thyra::initializeOp function that I will use a
>>> JacobianOperator instead of an Epetra_CrsMatrix, it still seems to 
>>> think
>>> that the jacobian of my system is an Epetra_CrsMatrix. In fact, upon
>>> execution, when the model evaluator calls for a Jacobian evaluation, 
>>> the
>>> dynamic cast
>>> JacobianOperator &jac = dyn_cast<JacobianOperator>(*W_out);
>>> fails with the following exception
>>> terminate called after throwing an instance of 'Teuchos::m_bad_cast'
>>>   what():
>>> /home/amola/trilinos-11.2.3-Source/packages/teuchos/core/src/Teuchos_dyn_c
>>> ast.cpp:61:
>>> Throw number = 1
>>> Throw test that evaluated to true: true
>>> dyn_cast<16JacobianOperator>(15Epetra_Operator) : Error, the object 
>>> with
>>> the concrete type '16Epetra_CrsMatrix' (passed in through the 
>>> interface
>>> type '15Epetra_Operator')  does not support the interface
>>> '16JacobianOperator' and the dynamic cast failed!
>>> Aborted.
>>> So, my question is: what should I do to be able to use an arbitrary
>>> Epetra_Operator in an EpetraExt::ModelEvaluator? I am not very 
>>> familiar
>>> with the parameter lists, so probably the answer is there. Or,
>>> Thyra::initializeOp is just the wrong function to do what I need. Can
>>> anyone point me out an example that does that, or suggest me some
>>> solution?
>>> Thank you very much in advance for the help.
>>> Regards,
>>>     Andrea
>>> _______________________________________________
>>> Trilinos-Users mailing list
>>> Trilinos-Users at software.sandia.gov
>>> https://software.sandia.gov/mailman/listinfo/trilinos-users
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at software.sandia.gov
> https://software.sandia.gov/mailman/listinfo/trilinos-users

More information about the Trilinos-Users mailing list