On Fri, 9 May 2008, Lorenzo Botti wrote: > I have finally find out why I couldn't restart properly a transient > system in parallel. The problem is that transient system doens't have > an update(...) method. > So I have added one coping it from the re_update(...) method. It works > for me but it will be good if someone could check it and add it to the svn.
I finally found this old message on my TODO list, looked over the code, and checked in this update (as well as removing an out-of-date assert() that you noticed in a related message. If you've got time to try the latest SVN head I'd appreciate it. > Another problem is that we should avoid reading the RHS_Vector I disagree with this; we don't know whether or not some user might want to do something creative with the RHS and want to preserve it through a restart. Not reading it wouldn't break my code, but might break someone else's. > becuase as I said in a previous message Petsc doesn't allowed to set > the values of a PetscVector an then zero it without calling close(). > This happens in ImplicitSystem::init(..). I don't have a good > solution for this... of course we can call close() before zero() but > this is an horrible hack. I think calling close() before zero() is the correct thing to do; calling close() in ImplicitSystem::init() would be a hack, but at the end of System::read_serialized_vector() should be appropriate. I'll add it there for now; hopefully Ben will correct me if I'm misunderstanding his I/O refactoring. --- Roy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
