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