> > Good thing you caught this today, too - the new adjoints API (that I > haven't committed to SVN yet) "helpfully" creates adjoint solutions, > etc. if they're requested and if they don't already exist. I'd > intended this to make things easier for user code, but if it had > already been in place then this bug would have just led to an > inefficient creation of an unused adjoint_solution - still a bug, but > one that wouldn't have triggered an assert and wouldn't have been > caught. Now I think I'll let adjoint_solve handle adjoint vector > creation, but force it to be done explicitly... > Great! I will watch for an svn update!
> > 2. If you perform an adaptive strategy based on a target number of >> elements >> with PetscDiffSolver instead of the default NewtonSolver, there is a crash >> during the residual assembly after the refinement. (Everything seems to >> work >> if NewtonSolver is used.) >> > > I can repeat this one too, but haven't figured it out: > > [0]PETSC ERROR: Nonconforming object sizes! > [0]PETSC ERROR: Mat mat,Mat *fact: global dimensions are different 7250 > should = 3803 7250 should = 3803! > > Odd that it's complaining about the matrices... I would understand if > there was some new issue with the ghosted PETSc vectors that > PetscDiffSolver wasn't handling properly, but the matrix indexing > isn't complicated and hasn't changed since I was using PetscDiffSolver > myself. > > PetscDiffSolver calls enforce_constraints_exactly without including the >> vector, so in the routine enforce_constraints_exactly the vector v is >> initialized with the call >> >> v = system.solution.get(); >> >> However, in the following lines of code, it is evident that this is >> recognized as type SERIAL, PARALLEL, or GHOST in dof_map_constraints.C. >> What >> else would it be? >> > > I think I'm missing some context here - are you implying that the > error you get is the Unknown v->type at dof_map_constraints.C line > 641? It would be interesting if we were seeing two different failures > here... > Ok, first of all... I apparently missed an important word of "not" in "However, in the following lines of code, it is evident that this is recognized as type SERIAL, PARALLEL, or GHOST in dof_map_constraints.C." It is not recognized! Anyway, yes, I am getting an error thrown from the libMesh assertion at line 641. Perhaps the difference is our PETSc versions? I'm using an older one, 2.3.3-p13. Thanks, Andrea ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
