On Dec 10, 2012, at 2:20 PM, Ataollah Mesgarnejad <[email protected]> wrote:
> > On Dec 10, 2012, at 1:45 PM, Roy Stogner <[email protected]> wrote: > >> >> On Fri, 7 Dec 2012, Ataollah Mesgarnejad wrote: >> >>> I managed to isolate the problem in my code: I use an added vector >>> to a system (third order CLOUGH) as the loading for one of systems; >>> I did two tests >>> >>> 1) >>> - I used system.project_vector to initialize this vector at each time >>> step. >>> - Solved with this loading. >>> >>> 2) >>> Code a) >>> - I used system.project_vector to initialize this vector at each time >>> step. >>> - I wrote this in a binary XDR file using: >>> equation_system.write(xdr_file_name.str(), >>> EquationSystems::WRITE_DATA | >>> >>> EquationSystems::WRITE_ADDITIONAL_DATA); >>> Code b) >>> - I read this additional vector at the beginning of the time step using: >>> equation_system.read(xdr_file_name.str(), >>> EquationSystems::READ_HEADER |EquationSystems::READ_DATA | >>> EquationSystems::READ_ADDITIONAL_DATA); >>> - Solve with this loading. >> >>> even though, everything else is unchanged between case 1 and 2, the >>> solutions are different and you can see that the solution of case 2 >>> visibly deteriorates at mesh partition boundaries. I'm attaching the >>> solutions at the 1st time step from both cases. >> >> The attachments didn't come through, but there's enough description >> here to make me wonder at one thing that's missing: >> >> In what way are you handling ghost degrees of freedom for your initial >> vector? There's code in libMesh itself to handle updating ghost >> degrees of freedom "behind the scenes" for your solution vector, but >> if you're creating additional vectors that will get used as inputs to >> an assembly then you'll typically also need additional code to make >> sure those vectors' ghost dof coefficients get communicated at the >> appropriate times. >> > I add the vector as GHOSTED. In my experience it worked fine when not > depending on XDR system::read. > >> It looks like we handle the communication step in library code at the >> end of System::project_vector(), but not in library code at the end of >> System::read*() methods. Worse yet: this isn't easy to fix without >> changing our xda/xdr file format, our I/O for which currently >> recreates any additional vectors as PARALLEL type, even if they were >> written out for something of GHOSTED type. >> >> We'll have other reasons to change our file format in the next year or >> so, so I'd just as soon table the problem at the library level until >> then. For now, the user level workaround for I/O of ghosted vectors >> would be: >> >> Manually create the systems containing such vectors and add the >> vectors themselves as GHOSTED before doing EquationSystems::read() >> (you're probably already doing this based on the above description, >> but I mention it for others who run into this problem) > Yes I do. > >> >> After the EquationSystems::read(), call close() on any ghosted >> vectors. (if you're not running with PETSc and --enable-ghosted, >> you'd currently need a more complicated localize(self, send_list) call >> instead; I'll see if we can fix that.) > I'm running with PETSc. I'll see if it would fix the issue. > > PS: the images are here if anyone wants to look. Forgot the link http://cl.ly/3y3U1C0z1k07 Sorry, Ata > > Thanks, > Ata > >> --- >> Roy > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
