On Tue, 20 Oct 2009, Andrea Hawkins wrote:
> I am wanting to implement a similar automatic adaptivity scheme as is in
> example 18. However, in testing the example itself I've run into a few
> issues.
>
> 1. If in the ex18.in file, the global tolerance is set to anything nonzero,
> the code breaks in the uniform_refinement_estimator.C on line 297 because it
> is looking for an adjoint_solution that has not been computed.
>
> It seems to me that the problem is that even though no solution_vector is
> passed into the estimate_error routine from ex18.C, the "if" check on line
> 290 in uniform_refinement_estimator.C is failing because the NULL
> solution_vector (originally "passed" into estimate_error) was wrapped into
> the map object solution_vectors which was then passed to the routine
> _estimate_error and thus, in the check, is not perceived as null.
That should be okay - what's supposed to happen in this codepath is
that the if check at line 290 fails, but solve_adjoint at line 297
evaluates to false, and so es.solve() just gets called at line 335
instead of line 291.
There is definitely a bug at line 297, though - get_adjoint_solution()
shouldn't be called there unless have_vector("adjoint_solution") is
true; otherwise we end up assuming the existence of an adjoint
solution vector that we don't intend to use! I'll fix that now.
(i.e. before releasing 0.6.4, thank you for the prompt bug report!)
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...
> 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...
---
Roy
------------------------------------------------------------------------------
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
