[Trilinos-Users] [EXTERNAL] instantiation with long and long?

[Cihan Altinay]

Hi Andrey,

That's totally fine and now that I know we can actually put this in the 
guide for our software. Locally I might do as you suggest, have two (or 
more, thinking of CUDA) installations and test things with the 
appropriate one.

Cheers,
Cihan

On 18/04/16 23:22, Prokopenko, Andrey (-EXP) wrote:
> Hi Cihan,
>
> Sorry for my late reply, I've been on travel.
>
> I don't think you'll be able to have a single installation of Trilinos to support long local ordinals. As you've seen, many external packages that you may want to use when running with int will produce compilation errors when compiling with long. As long as you make a call to some part of code that references those libraries, you'll get an error.
>
> I don't see a way to avoid two Trilinos installations, one with ETI on, LO=int, and all TPLs enabled, and the second one with ETI=off, LO=long, and incompatible TPLs disabled. One thing that I'm wondering about if it is possible to merge the libraries from two Trilinos builds in a single one.
>
> Sorry I could not be of more help.
>
> -Andrey
> ________________________________________
> From: Cihan Altinay <c.altinay at uq.edu.au>
> Sent: Thursday, April 7, 2016 7:53 PM
> To: Prokopenko, Andrey (-EXP)
> Cc: trilinos-users at trilinos.org
> Subject: Re: [EXTERNAL] [Trilinos-Users] instantiation with long and long?
>
> Hi Andrey,
>
> Thanks for the info. I disabled ETI as suggested but now I am getting
> compile errors using Amesos2:
>
> /opt/trilinos/include/Amesos2_MUMPS_def.hpp:420:19: error: cannot
> convert ‘Amesos2::MUMPS<Tpetra::CrsMatrix<double, long int, long int,
> Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> >,
> Tpetra::MultiVector<double, long int, long int,
> Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> >
>   >::local_ordinal_type* {aka long int*}’ to ‘int*’ in assignment
>        mumps_par.irn = (local_ordinal_type*)malloc(mumps_par.nz
> *sizeof(local_ordi
>                      ^
>
> I know MUMPS only supports ordinal type int and I did build Trilinos
> with MUMPS support, however I do NOT instantiate a solver for MUMPS in
> this example. In fact as soon as I put any Amesos2::create<...>() call
> in my code the compilation aborts with the above.
>   From this my conclusion was that I need explicit instantiation but
> again that does not work either.
>
> Just to clarify my aim was to build a fairly full-featured trilinos once
> and use it with different "versions" of our project (i.e. using
> different ordinal types and maybe enable/disable OpenMP etc). I was
> hoping I could conditionally compile in certain features, for example
> remove any reference to MUMPS and other TPLs in my project that don't
> support the ordinal type in use. But if I can't use Amesos2 at all that
> will obviously not work.
>
> Hints?
>
> Thanks again,
> Cihan
>
> On 08/04/16 06:27, Andrey Prokopenko wrote:
>> Hi Cihan,
>>
>> I don't think it will easily work with explicit instantiation turned on.
>> This is not our typical use case, and we don't test for local ordinals =
>> long. If you are not too concerned with build times, it may be easier to
>> simply disable Trilinos ETI to get what you want. If you have reasons
>> why you have to use ETI, we can discuss the next steps that may be
>> necessary.
>>
>> -Andrey
>>
>> On 04/05/2016 01:12 AM, Cihan Altinay wrote:
>>> Howdy,
>>>
>>> We would like to use Tpetra, Belos, Amesos2 and MueLu with both local
>>> index type = long and global index type = long. Unfortunately, this
>>> does not appear to be supported out of the box, at least I couldn't
>>> find the right CMake settings.
>>> I suppose I have to manually instantiate all the required classes with
>>> the appropriate types or is there another way?
>>> At the moment I am getting undefined symbol errors at runtime in our
>>> project such as (demangled):
>>>
>>> MueLu::TpetraOperator<double, long, long,
>>> Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP,
>>> Kokkos::HostSpace> >::getDomainMap() const
>>>
>>>
>>> Thanks for any hints!
>>> Cihan
>>>
>>
>


-- 
Cihan Altinay

Computer Scientist, Centre for Geoscience Computing
eResearch Analyst,  Queensland Cyber Infrastructure Foundation
The University of Queensland
T: +61 7 334 64118 / F: +61 7 334 64134