[petsc-dev] Jed!!!

[Barry Smith]

On Apr 27, 2014, at 10:29 AM, Jed Brown <jed at jedbrown.org> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>> On Apr 26, 2014, at 11:54 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>> 
>>>>  Mat nest is just an optimization. That, BTW makes it impossible to do the simplest tests of your code!!
>>> 
>>> It is intended to be used with MatGetLocalSubMatrix and
>>> MatSetValuesLocal.  It would be significant complexity (including memory
>>> scalability) to support MatSetValues, and supporting that mode would
>>> encourage people to write code that needs refactoring to perform.  At
>>> least that was my thinking.  If you are assembling with a global
>>> MatSetValues, MATNEST doesn't offer much so just don't use it.
>>> 
>>> How do you want to change this?
>> 
>>  Somehow have a way of testing the resulting Jacobian against a
>>  “known” accurate one. 
> 
> -dm_mat_type aij -snes_type test?

   The application doesn’t use dm. It has code like

cmake/Findcutil.cmake:  add_subdirectory("${_moddir}/nested_targets/cutil")
FEM/rf_pcs_TH.cpp:              ierr = MatCreateNest(PETSC_COMM_WORLD, dof, NULL, dof, NULL, &eqs_new->vec_subA[0], &eqs_new->A);CHKERRCONTINUE(ierr);
FEM/rf_pcs_TH.cpp:              ierr = MatNestGetISs(eqs_new->A, &eqs_new->vec_isg[0], NULL);CHKERRCONTINUE(ierr);
FEM/rf_pcs_TH.cpp:              MatNestGetSubMats(mat,NULL,NULL,&mats);
FEM/rf_pcs_TH.cpp~:             ierr = MatCreateNest(PETSC_COMM_WORLD, dof, NULL, dof, NULL, &eqs_new->vec_subA[0], &eqs_new->A);CHKERRCONTINUE(ierr);
FEM/rf_pcs_TH.cpp~:             ierr = MatNestGetISs(eqs_new->A, &eqs_new->vec_isg[0], NULL);CHKERRCONTINUE(ierr);
FEM/rf_pcs_TH.cpp~:             MatNestGetSubMats(*mat,NULL,NULL,&mats);

> 

> Comparison of this type is a "monolithic" operation, like LU is a
> monolithic operation, so why not use a monolithic format?  I'm not
> objecting to something else, but I want the code to be as simple as
> possible.
> 
>>  We all know how users fuck up Jacobians; given that this one is even
>>  more complicated to build we sure as hell should have a way of
>>  comparing it to a finite difference Jacobian. And for that
>>  scalability and efficiency don’t mater.