Re: [Libmesh-users] XDR read bug with C1 elements

[Ataollah M. <am...@ti...>]

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 <am...@ti...> wrote:

> 
> On Dec 10, 2012, at 2:20 PM, Ataollah Mesgarnejad <am...@ti...> wrote:
> 
>> 
>> On Dec 10, 2012, at 1:45 PM, Roy Stogner <roy...@ic...> 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
>> 
>