On Thu, Jan 15, 2009 at 05:58, Kirk, Benjamin (JSC-EG)
wrote:
>> Giving identical degrees of freedom different ids on different
>> processors would not be natural for us, especially considering the
>> changes we'd be forced to make to the DofMap (which would now need to
>> talk to our numeric inte
On Thu, 15 Jan 2009, Kirk, Benjamin (JSC-EG) wrote:
> I believe this should be handled by the send_list.
You're right that it should be possible to make the send_list
redundant with (and then use it for) PETSc's local->global lookup, but
whether PETSc's APIs make that easy (and whether we can do
Dear Ben,
On Thu, 15 Jan 2009, Kirk, Benjamin (JSC-EG) wrote:
>>> My idea would be that PetscVector creates the global-to-local mapping (for
>>> the ghost cells only) itself (and stores it, e.g. as a std::map>> int,
>>> unsigned int>). This should still save a lot of memory compared with the
>>>
(forked to libmesh-devel)
> On Thu, 15 Jan 2009, Tim Kroeger wrote:
>
>> But there is another problem (things turn out to be more difficult than I
>> thought): In the ghost cell case, PETSc does not provide the appropriate
>> global-to-local mapping that would be required for e.g.
>> NumericVecto
