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.

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

Reply via email to