[petsc-dev] sor smoothers

[Barry Smith]

#if (PETSC_SIZEOF_LONG_LONG == 8)
typedef long long Petsc64bitInt;
#elif defined(PETSC_HAVE___INT64)
typedef __int64 Petsc64bitInt;
#else
typedef unknown64bit Petsc64bitInt
#endif

  I assume all machines support one or the other of these ?

  Should we introduce an unsigned version of this Petsc64bitUInt, for these type of things?

   Barry


On Sep 8, 2013, at 1:44 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>> An alternative would be to add a scalar parameter to MatMultAdd.
>> 
>>   MatResidual() is an important enough case to merit its own
>>   method. The odd ball scalar parameter that is not 1 or -1 is so
>>   extremely rare as to lead to confusion instead of useful
>>   generality.
> 
> Fine, but implementations might want to unify the add and subtract
> kernels because it's half the code.
> 
>>> Perhaps PetscObjects should get a 64-bit unique ID assigned by a global
>> 
>>   Why 64 bit? Surely we will never have more than 2 billion objects created?
> 
> It's not the number of objects in scope, but the cumulative number of
> objects.  Some simulations take billions of time steps.  You might say
> they should ensure that everything is reused over that period, but it's
> hard to guarantee and this failure mode is just not worth allowing into
> the realm of possibility.  If it were up to me, I would also make the
> State integer 64-bit.  (You don't want to hand a Vec off to a stochastic
> optimizer that does a million forward and adjoint simulations, each with
> 1000 time steps, and have a possibility of reusing some stale cache
> once you get the solution vector back.)
> 
>>> counter, or even a slightly longer hash of information that should never
>>> repeat.  Caching the pointer leaves the ABA problem.
>> 
>>  We currently have 
>>  h->id                    = idcnt++;
>>  in PetscHeaderCreate_Private(). 
>> 
>>   The id is not consistent across processes for a given object but I
>>   don't think that matters. Why can't we just stash this value? I
>>   think this value plus the Vec/Mat state uniquely define the values
>>   in the Vec/Mat.
> 
> I forgot about that, but I think we should make it 64-bit.
> 
>> There is a possibility of some processes having the same state and
>> others different ones and thus errors due to different functions being
>> used; for example if one process called VecGetArrayWrite() but another
>> one didn't. This is perverse so ….?
> 
> VecGetArray is documented to be logically collective.  There are some,
> ahem, C++ libraries downstream that are dedicated to abusing the
> interface with unstructured operator overloading.