Roy,

I tried what you suggested, however when I check the NumericVector type of my 
added vector (I add it as GHOSTED before read) after EquationSystems::Read() it 
changes to parallel ?!!  ( I checked with NumericVector::type() it was 3 before 
the read and 2 after) 

Is there a work around so I can make a GHOSTED NumericVector myself from this 
PARALLEL vector?

Thanks,
Ata 


On Dec 10, 2012, at 2:21 PM, Ataollah Mesgarnejad <[email protected]> 
wrote:

> 
> 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

Reply via email to