<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 14, 2015 at 4:09 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  I don't buy that this is good code. 1) It is strange to keep solver state in the vector instead of the solver object and 2) it is very dangerous as anybody who calls VecGetArray() on the vector in, for example, a monitor breaks the code and gets the wrong answer. Using VecGetArray() might slow down code because things need to be recalculated but assuming the user did not write into the array it should not change the progress of the code.<br>
<br>
   I vote that this code is refactored to not use this hairy storage of solver state in "some vector that is lying around".<br>
<br>
  if (ts->equation_type >= TS_EQ_IMPLICIT && tab->explicit_first_stage) {<br>
    PetscReal valid_time;<br>
    PetscBool isvalid;<br>
    ierr = PetscObjectComposedDataGetReal((PetscObject)ts->vec_sol,explicit_stage_time_id,valid_time,isvalid);CHKERRQ(ierr);<br>
    if (!isvalid || valid_time != ts->ptime) {<br>
</blockquote></div><br>I agree completely. If we need more state, it should go in the solver.</div><div class="gmail_extra"><br></div><div class="gmail_extra">  Matt<br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>