Matthew Knepley wrote: > Maybe I still misunderstand. Example: > > 1) gVec(state 21)
In the current implementation, gVec cannot exist without lVec. Let's say we start with lVec(state 0) because you have been messing with gVec for a while without touching lVec. > 2) GetLocalForm(gVec) --> lVec(state 0) You must change the state of lVec here, because you could have changed gVec since the last time you were looking at lVec. You can do this by increasing it by one, or you can do it by taking the max with gVec. In the latter case, it won't invalidate the cache if you have not changed gVec. So in your scheme, you necessarily have lVec(state 1) (unless lVec is brand new in which case it doesn't matter, but this is not how the implementation works and it would take major changes to make it work this way). > 3) Change lVec, which changes gVec Right, this increases the state of lVec. It is now 2 in your scheme and 22 in my scheme. > 4) RestoreLocalForm(lVec) --> gVec(state max(21,1)) In your scheme, we just increment the state of gVec, resulting in gVec(state 22). In my scheme, we have gVec(state max(21,22)) because we have lVec(state 22). > I am opposed to this, because I really do not like the state mechanism > in the first place. It is dangerous (as your debugging shows), and > relying on it makes it very easy for people to introduce errors, as we > see. It is dangerous, but it's nice to just call VecNorm wherever you need it without worrying about it being wasteful. In any case, using the maximum scheme and syncronization, the state will change any time you change either vector, as long as that vector's state is increased when you change it (which is already required for any vector). > However, if you really want to synchronize the state of local and > global vectors, I will not stop it this time. If there is another > error, I am wiping this out altogether. Wiping what out? VecGhost? State? Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090430/efc592ca/attachment.pgp>