Provide Trilinos-global CMake options to make it easier for apps to disable float & complex Scalar types #362

bartlettroscoe · 2016-05-17T00:19:11Z

Next Action Status:

Pushed to 'develop' branch as part of #482. Complete!

CC: @trilinos/framework, @trilinos/tpetra

Blocked By: #158

Blocking: #482

Description:

By default, in release and development mode, Trilinos provides support for float and complex (std::complex<float> and std::complex<double>) scalar types. When ETI is used, this massively increases the compile and link times for Trilinos. Most Trilihnos users don't even need float or complex scalar types.

Currently, to disable float and complex , the user has to set a bunch of separate Teuchos and Tpetra options. Very few users know what options these are so they get long build times by default and no idea how to disable them.

This story is to change the default for Trilinos to not build float or complex types by default. This story will also provide top level build options Trilinos_ENABLE_FLOAT and Trilinos_ENABLE_COMPLEX (and Trilinos_ENABLE_COMPLEX_FLOAT and Trilinos_ENABLE_COMPLEX_DOUBLE with obvious defaults based on Trilinos_ENABLE_FLOAT and Trilinos_ENABLE_COMPLEX) that all Trilinos packages that currently have their own variables will respond to.

Definition of Done:

By default Trilinos builds without support for (or ETI instantiations for) float or complex scalar types.
Users can turn on support for float and/or complex types by setting -DTrilinos_ENABLE_FLOAT=ON and/or -DTrilinos_ENABLE_COMPLEX=ON, respectively (or something similar).

Tasks:

Made a decision if support and explicit instantations for float and/or complex should be enabled by default or not. [DONE]
Add Trilinos repository options Trilinos_ENABLE_FLOAT, Trilinos_ENABLE_COMPLEX, Trilinos_ENABLE_COMPLEX_FLOAT and Trilinos_ENABLE_COMPLEX_DOUBLE and make Teuchos, Tpetra, Thyra, and other packages set their defaults based on this. (These should be Trilinos repository level options so that they can be set in meta projects like CASL VERA, MPACT, SCALE, as well) [Done]
Explicitly turn on Trilinos_ENABLE_FLOAT, Trilinos_ENABLE_COMPLEX, Trilinos_ENABLE_COMPLEX_FLOAT and Trilinos_ENABLE_COMPLEX_DOUBLE in a few automated Trilinos builds ... Not going to do this in this story

The text was updated successfully, but these errors were encountered:

mhoemmen · 2016-05-17T05:25:52Z

In Tpetra, Scalar = std::complex<double> and std::complex<float> are only enabled by default in a debug build. Scalar = float is always disabled by default.

Imagine that a supercomputer software vendor wants to support Trilinos. Do you think they will ask us how to enable complex Scalar types? Of course not. They will configure with the minimal settings to make it build, then install the thing. Users then get Scalar = double and that's it.

Applications can and do disable types that they don't need. Also, we could always make Tpetra's ETI work like the "ETI" in KokkosKernels, where any Scalar type works, but some types get pre-compiled kernels by default. The new extern template feature of C++11 might help make this easier.

I like your second feature request. A while back, I was trying to add Scalar = __float128 support to Tpetra. I found out the hard way that Thyra uses a separate set of ETI macros managed through Teuchos. It would make sense for Thyra and Tpetra to share the same ETI system, even if one doesn't necessarily support all the type combinations that the other supports.

bartlettroscoe · 2016-05-17T15:49:08Z

In Tpetra, Scalar = std::complex<double> and std::complex<float> are only enabled by default in a debug build. Scalar = float is always disabled by default.

I am not sure that we want to change what types are enabled by default based on a debug build or not. I think that would confuse users (I would be surprised and confused by this).

Imagine that a supercomputer software vendor wants to support Trilinos. Do you think they will ask us how to enable complex Scalar types? Of course not. They will configure with the minimal settings to make it build, then install the thing. Users then get Scalar = double and that's it.

I disagree. We make it clear in the Trilinos/INSTALL document that by default you only get support for double and if they want support for float and std:complex, then they need to add -DTrilinos_ENBALE_FLOAT=ON and -DTrilinos_ENBALE_COMPLEX=ON. I think that is the way to go. Otherwise, potential new Trilinos users will get turned off immediately when they try to build Trilinos the first time and it takes hours and hours to build a bunch of instantations that 99% of them will never use.

If super computing centers are installing Trilinos in a vacuum (i.e. not talking to Trilinos developers or Trilinos users), then people end up ignoring the default installed version of Trilnos anyway. How many people do you know who use the default installed version of Trilinos on these machines? Currently, if they don't enable enough TPLs, then people ignore the default installed version of Trilinos. Hopefully with Spack that will change (and we can make sure that Trilinos is configured appropriately with Spack which will include if float and complex types are enabled or not).

Applications can and do disable types that they don't need.

Close application customers are not a problem either way. We just tell them how to configure and they do it. The issue is new potential customers that are getting ridiculously long build times by default. That is the issue.

Also, we could always make Tpetra's ETI work like the "ETI" in KokkosKernels, where any Scalar type works, but some types get pre-compiled kernels by default. The new extern template feature of C++11 might help make this easier.

Not sure what extern template buys you but it is worth looking into.

I like your second feature request. A while back, I was trying to add Scalar = __float128 support to Tpetra. I found out the hard way that Thyra uses a separate set of ETI macros managed through Teuchos. It would make sense for Thyra and Tpetra to share the same ETI system, even if one doesn't necessarily support all the type combinations that the other supports.

I don't have any major objections to this but Tpetra is just an optional dependency for Thyra so it might take some work to get this to behave correctly. I think we would really rather have the selection of Scalar (and Ordinal) types specified by default at the global level and then the various Trilinos packages should use those, as described above for float and complex types.

We should discuss this at the Trilinos Leaders Meeting today.

mhoemmen · 2016-05-18T04:38:46Z

I'm renaming this, because not everyone agrees about default behavior. We agree that such options should be shared among Trilinos packages (in particular between Thyra, Tpetra, and their downstream packages). We also agree that it should be easy for installers and applications to change the settings.

bartlettroscoe · 2016-05-18T12:42:46Z

because not everyone agrees about default behavior.

Everyone does not have to agree, but we still need to define default behavior. We will discuss this at the next Trilinos leaders meeting but I will argue that the massive build times for Trilinos should make the default to exclude float and complex types in the default configure of Trilinos.

bartlettroscoe · 2016-05-18T12:57:03Z

I added blocking relationship with #158 since I don't think we can test such a change without building almost all of Trilinos (which is very hard to do right now).

mhoemmen · 2016-05-24T18:23:47Z

Should we let users specify a list of enabled e.g., Scalar types, rather than saying Trilinos_ENABLE_FLOAT etc.? This could get confusing, e.g., if users want to enable Scalar=int (does Trilinos_ENABLE_INT mean Scalar, LocalOrdinal, or GlobalOrdinal?).

bartlettroscoe · 2016-05-24T18:35:12Z

At the Trilinos Leaders meeting today, we discussed this if we should enabled float and complex by default or not. The consensus decision was to disable float and complex by default but make it easy and obvious for how to enable them.

Now the question is how to enable them?

Should we let users specify a list of enabled e.g., Scalar types, rather than saying Trilinos_ENABLE_FLOAT etc.? This could get confusing, e.g., if users want to enable Scalar=int (does Trilinos_ENABLE_INT mean Scalar, LocalOrdinal, or GlobalOrdinal?).

That is not a bad idea. I might suggest:

-DTrilinos_ENABLE_SCALAR_TYPES="float, complex, complex<float>, complex<double>, ..."

(the type double would be hard coded and could not be disabled. Or we could supply a separate option to disable the default double support and instantations.)

So above, if the user specified float,complex, then they would actually get support (and instantations with ETI enabled) for complex<float> and complex<double>. If they did not want, for example, complex<float>, then they would specify float,complex<double>. Sound good?

Then we could do something similar to for GlobalOrdinal andLocalOrdinal:

-DTrilinos_ENABLE_LOCAL_INT_TYPES="int, long int, long long int, ..."
-DTrilinos_ENABLE_GLOBAL_INT_TYPES="long long int, long int, int, ..."

These types of CMake arguments would require more CMake work to parse this (i.e.. long long and long long int are the same) but it would allow for better extendability.

Comments, opinions?

wfspotz · 2016-05-24T19:05:37Z

I think the lists approach is the right way to go. I have a couple questions:

Does complex<double> work without the std namespace? If so, why? What is the rule for type specification? Is using std assumed when parsing the list?
Are there any issues with user-defined types (presumably for SCALAR)?

mhoemmen · 2016-05-26T05:50:26Z

Does complex<double> work without the std namespace? If so, why? What is the rule for type specification? Is using std assumed when parsing the list?

I think @bartlettroscoe was just abbreviating -- it would make sense for the list to be parsed as if it occurred in the global namespace with no using declarations.

bartlettroscoe · 2016-05-26T17:53:44Z

I think we could allow the CMake parsing to be smart enough to allow std::complex<double> or just complex<double>. We just need to document this.

The bigger question is if this will also support addon user-defined types? That is a another type of requirement that I would rather address in another Story ticket.

I would guess that given the current scope, this should be about a days work (i.e. 8 dev hours) including automated tests, full manual testing on Trilinos, documentation, etc. But this is the easiest thing that we can do that will result in a dramatic reduction in default build times (which we should time). But before we start this, we should do #158 to make this easy to test.

mhoemmen · 2016-05-26T18:39:46Z

The bigger question is if this will also support addon user-defined types? That is a another type of requirement that I would rather address in another Story ticket.

I agree that we don't have to go there for now. Any type that requires including a header file would not work without further modifications. Built-in but nonstandard types that don't require including a header file (or already have it included) should work fine. This includes GCC's __float128 (as long as users link with libquadmath).

mhoemmen · 2016-05-26T18:40:26Z

I think we could allow the CMake parsing to be smart enough to allow std::complex or just complex. We just need to document this.

Let's make users spell this out for us. How do we know the difference between std::complex and Kokkos::complex otherwise?

mhoemmen · 2016-05-26T19:19:19Z

But this is the easiest thing that we can do that will result in a dramatic reduction in default build times (which we should time).

A lot of the build time stuff is not ETI-related, it's that we instantiate too much code. To me, this issue is about simplifying Tpetra - Thyra - Stratimikos integration, and improving the user experience.

bartlettroscoe · 2016-06-24T23:36:46Z

Let's make users spell this out for us. How do we know the difference between std::complex and Kokkos::complex otherwise?

I think for the purposes of a global option to enable complex support, it should be just complex and that should enable or disable std::complex and Kokkos::complex. If package's want package-specific finer-grained enables/disables, then that is fine.

I am actually about to implement this soon since this will be important to create a more efficient pre-push testing process.

bartlettroscoe · 2016-06-25T15:53:11Z

Regardless what we use as the final user interface, we are going to want simple CMake variables like ${PROJECT_NAME}_ENABLE_FLOAT and ${PROJECT_NAME}_ENABLE_COMPLEX to make it easy to set the defaults for the vars:

Teuchos_ENABLE_FLOAT
Teuchos_ENABLE_COMPLEX
Sacado_ENABLE_COMPLEX
Thyra_ENABLE_COMPLEX
Tpetra_INST_COMPLEX_DOUBLE
Tpetra_INST_COMPLEX_FLOAT
Anasazi_ENABLE_COMPLEX

That should be fast and easy to implement for now.

crtrott · 2016-06-27T15:00:40Z

Just a comment to Kokkos vs std complex: std:: complex doesn't work in parallel environments well, since it a) doesn't exist on GPUs, and b) misses volatile overloads of its operators which prevents things like Kokkos reductions to work. What we did with Tpetra is that you request std::complex, but internally will get Kokkos::complex. The two types are interoperable (i.e. assignable and promotable to each other).

bartlettroscoe · 2016-06-29T15:13:58Z

Responding to @crtrott in above comment:

Just a comment to Kokkos vs std complex: std:: complex doesn't work in parallel environments well, since it a) doesn't exist on GPUs, and b) misses volatile overloads of its operators which prevents things like Kokkos reductions to work. What we did with Tpetra is that you request std::complex, but internally will get Kokkos::complex. The two types are interoperable (i.e. assignable and promotable to each other).

I think that means that it makes no sens to say that you are supporting "Kokkos::complex" and "std::complex". It will just be "complex" and the Kokkos::complex will be used where it needs to be and std::complex can be used else where. I that a fair assessment?

crtrott · 2016-06-29T15:38:23Z

Yeah that is pretty much what I think about this. Kokkos complex is not meant as an alternative to std::complex, it is meant to supplement it since std::complex has deficiencies which would prevent its usage throughout the threaded Trilinos stack.

bartlettroscoe · 2016-06-29T15:54:07Z

Yeah that is pretty much what I think about this. Kokkos complex is not meant as an alternative to std::complex, it is meant to supplement it since std::complex has deficiencies which would prevent its usage throughout the threaded Trilinos stack.

Right, so that argues that my recommendation in the above comment to use:

-DTrilinos_ENABLE_SCALAR_TYPES="float, complex, complex<float>, complex<double>, ..."

It makes no sense to differentiate "std::complex" from "complex" because Trilinos will pick the right complex impl for the given situation. The user would interact with Kokkos::complex or std::complex or a C-struct or Fortran equivalent depending on their situation. It is just "complex".

crtrott · 2016-06-29T17:38:43Z

Agreed.

Now that complex is disbaled by default (trilinos#362), we need to enable it in some nightly testing. It looks like there are several Trilinos builds on this machine so this is a good place to start.

Now there are top-level options for float and complex and these are off by default as per the conversation and decision documented in trilinos#362. This makes it easy to enable and disable support for these types. Some work needs to be done to get some of the packages to allow enabling and disabling float, std:complexfloat> and std::complex<double> somewhat independently but that can be done later. Really only Tpetra allows this correctly. Also, these are disabled by default to speed up the default build of Trilinos and very few customers use or need float and std::complex types. As a matter of fact, float support in Tpetra and downstream is currently broken. This is likely due to the fact that Tpetra unconditionally disabled float by default and it is doubtful that anyone has tested this in a long time (and there are no automated tests that test float support). I fixed the logic for Tpetra complex<double> support in Anasazi so that Tpetra (take a look at the updated logic). I also fixed some typos in documentation.

…os#362) This is a bit of a hack since Teuchos is not properly respond to Trilinos_ENABLE_COMPLEX_FLOAT. I noticed this while working on trilinos#362.

…os#482, trilinos#362) Until we get get the CI server changed over to the new PT server and get a bunch of other Nighty tests to turn on complex, we want this CI build to at least test complex.

Now that complex is disbaled by default (trilinos#362), we need to enable it in some nightly testing. It looks like there are several Trilinos builds on this machine so this is a good place to start.

…158, #831, #811, #826, #410)

bartlettroscoe · 2016-12-10T03:40:48Z

This has been merged to Trilinos 'develop' branch for a long time. In am not going to bother with the task

Explicitly turn on Trilinos_ENABLE_FLOAT, Trilinos_ENABLE_COMPLEX, Trilinos_ENABLE_COMPLEX_FLOAT and Trilinos_ENABLE_COMPLEX_DOUBLE in a few automated Trilinos builds.

Closing as complete.

…trilinos#10636, trilinos#362) This now keys off of Trilinos_ENABLE_COMPLEX_DOUBLE and Trilinos_ENABLE_COMPLEX_FLOAT to make it so that: -D Trilinos_ENABLE_FLOAT=ON \ -D Trilinos_ENABLE_COMPLEX_DOUBLE=ON \ causes the Teuchos ETI macros in Teuchos_ExplicitInstantiationHelpers.hpp to do instatiations for complex<double> but not complex<float>. More details: * Added new cache vars Teuchos_INST_FLOAT, Teuchos_INST_COMPLEX_FLOAT, and Teuchos_INST_COMPLEX_DOUBLE with identical defaults to Tpetra versions of these vars and then used these vars to determine instantations in Teuchos_ExplicitInstantiationHelpers.hpp and teuchos/numerics/src/Teuchos_ExpandScalarTypeMacros.hpp. To make setting Teuchos_INST_COMPLEX_FLOAT consistent, it must take its default value from Trilinos_ENABLE_COMPLEX_FLOAT if that var is non-empty. * Removed duplicate warnings coming from macros in Teuchos_ExplicitInstantiationHelpers.hpp being redefined in Teuchos_ExpandScalarTypeMacros.hpp. (I made the latter include the former.) * Removed assert_defined() calls for Trilinos_ENABLE_COMPLEX_FLOAT and Trilinos_ENABLE_COMPLEX_DOUBLE so at least there is a chance that we can still build Teuchos as its own CMake project.

…plex<float> not supported (trilinos#10636, trilinos#362) That test fails if you try to run it with complex<double> ETIs enabled but not complex<float>. (There is no existing nightly or PR build of Trilinos that matches that configuration yet it is the configuration for the most important Trilinos customer, Sierra.)

…trilinos#10635, trilinos#362) This now keys off of Trilinos_ENABLE_COMPLEX_DOUBLE and Trilinos_ENABLE_COMPLEX_FLOAT to make it so that: -D Trilinos_ENABLE_FLOAT=ON \ -D Trilinos_ENABLE_COMPLEX_DOUBLE=ON \ causes the Teuchos ETI macros in Teuchos_ExplicitInstantiationHelpers.hpp to do instatiations for complex<double> but not complex<float>. More details: * Added new cache vars Teuchos_INST_FLOAT, Teuchos_INST_COMPLEX_FLOAT, and Teuchos_INST_COMPLEX_DOUBLE with identical defaults to Tpetra versions of these vars and then used these vars to determine instantations in Teuchos_ExplicitInstantiationHelpers.hpp and teuchos/numerics/src/Teuchos_ExpandScalarTypeMacros.hpp. To make setting Teuchos_INST_COMPLEX_FLOAT consistent, it must take its default value from Trilinos_ENABLE_COMPLEX_FLOAT if that var is non-empty. * Removed duplicate warnings coming from macros in Teuchos_ExplicitInstantiationHelpers.hpp being redefined in Teuchos_ExpandScalarTypeMacros.hpp. (I made the latter include the former.) * Removed assert_defined() calls for Trilinos_ENABLE_COMPLEX_FLOAT and Trilinos_ENABLE_COMPLEX_DOUBLE so at least there is a chance that we can still build Teuchos as its own CMake project.

…plex<float> (trilinos#10635, trilinos#362) This is to make the instantiations consistent with (updated) Teuchos and Tpetra so that if you configure with: -D Trilinos_ENABLE_FLOAT=ON \ -D Trilinos_ENABLE_COMPLEX_DOUBLE=ON \ you will get consistent instantations and tests. Specific changes: * Removed HAVE_THYRA_TEUCHOS_BLASFLOAT, HAVE_THYRA_FLOAT, and HAVE_THYRA_COMPLEX and go with Teuchos versions of these. * Fix build errors for some float tests (Shows that float testing has not been enabled in a long time?) * Loosen tolerance for some float tests so they pass. With this set of changes, the full Thyra test suite passes for the above configure arguments (with GCC 7.2.0).

…plex<float> not supported (trilinos#10635, trilinos#362) That test fails if you try to run it with complex<double> ETIs enabled but not complex<float>. (There is no existing nightly or PR build of Trilinos that matches that configuration yet it is the configuration for the most important Trilinos customer, Sierra.)

…plex<float> (trilinos#10635, trilinos#362) This is to make the instantiations consistent with (updated) Teuchos and Tpetra so that if you configure with: -D Trilinos_ENABLE_FLOAT=ON \ -D Trilinos_ENABLE_COMPLEX_DOUBLE=ON \ you will get consistent instantations and tests. Specific changes: * Removed HAVE_THYRA_TEUCHOS_BLASFLOAT, HAVE_THYRA_FLOAT, and HAVE_THYRA_COMPLEX and go with Teuchos versions of these. * Fix build errors for some float tests (Shows that float testing has not been enabled in a long time?) * Loosen tolerance for some float tests so they pass. With this set of changes, the full Thyra test suite passes for the above configure arguments (with GCC 7.2.0).

…plex<float> not supported (trilinos#10635, trilinos#362) That test fails if you try to run it with complex<double> ETIs enabled but not complex<float>. (There is no existing nightly or PR build of Trilinos that matches that configuration yet it is the configuration for the most important Trilinos customer, Sierra.)

…plex<float> (trilinos#10635, trilinos#362) This is to make the instantiations consistent with (updated) Teuchos and Tpetra so that if you configure with: -D Trilinos_ENABLE_FLOAT=ON \ -D Trilinos_ENABLE_COMPLEX_DOUBLE=ON \ you will get consistent instantations and tests. Specific changes: * Removed HAVE_THYRA_TEUCHOS_BLASFLOAT, HAVE_THYRA_FLOAT, and HAVE_THYRA_COMPLEX and go with Teuchos versions of these. * Fix build errors for some float tests (Shows that float testing has not been enabled in a long time?) * Loosen tolerance for some float tests so they pass. With this set of changes, the full Thyra test suite passes for the above configure arguments (with GCC 7.2.0).

…plex<float> not supported (trilinos#10635, trilinos#362) That test fails if you try to run it with complex<double> ETIs enabled but not complex<float>. (There is no existing nightly or PR build of Trilinos that matches that configuration yet it is the configuration for the most important Trilinos customer, Sierra.)

…trilinos#10635, trilinos#362) This now keys off of Trilinos_ENABLE_COMPLEX_DOUBLE and Trilinos_ENABLE_COMPLEX_FLOAT to make it so that: -D Trilinos_ENABLE_FLOAT=ON \ -D Trilinos_ENABLE_COMPLEX_DOUBLE=ON \ causes the Teuchos ETI macros in Teuchos_ExplicitInstantiationHelpers.hpp to do instatiations for complex<double> but not complex<float>. More details: * Added new cache vars Teuchos_INST_FLOAT, Teuchos_INST_COMPLEX_FLOAT, and Teuchos_INST_COMPLEX_DOUBLE with identical defaults to Tpetra versions of these vars and then used these vars to determine instantations in Teuchos_ExplicitInstantiationHelpers.hpp and teuchos/numerics/src/Teuchos_ExpandScalarTypeMacros.hpp. To make setting Teuchos_INST_COMPLEX_FLOAT consistent, it must take its default value from Trilinos_ENABLE_COMPLEX_FLOAT if that var is non-empty. * Removed duplicate warnings coming from macros in Teuchos_ExplicitInstantiationHelpers.hpp being redefined in Teuchos_ExpandScalarTypeMacros.hpp. (I made the latter include the former.) * Removed assert_defined() calls for Trilinos_ENABLE_COMPLEX_FLOAT and Trilinos_ENABLE_COMPLEX_DOUBLE so at least there is a chance that we can still build Teuchos as its own CMake project.

…plex<float> (trilinos#10635, trilinos#362) This is to make the instantiations consistent with (updated) Teuchos and Tpetra so that if you configure with: -D Trilinos_ENABLE_FLOAT=ON \ -D Trilinos_ENABLE_COMPLEX_DOUBLE=ON \ you will get consistent instantations and tests. Specific changes: * Removed HAVE_THYRA_TEUCHOS_BLASFLOAT, HAVE_THYRA_FLOAT, and HAVE_THYRA_COMPLEX and go with Teuchos versions of these. * Fix build errors for some float tests (Shows that float testing has not been enabled in a long time?) * Loosen tolerance for some float tests so they pass. With this set of changes, the full Thyra test suite passes for the above configure arguments (with GCC 7.2.0).

…plex<float> not supported (trilinos#10635, trilinos#362) That test fails if you try to run it with complex<double> ETIs enabled but not complex<float>. (There is no existing nightly or PR build of Trilinos that matches that configuration yet it is the configuration for the most important Trilinos customer, Sierra.)

…s:develop' (816e7eb). * trilinos-develop: Xpetra: Use as<Scalar>() to fix complex<float> tests (trilinos#10635) Stratimikos: Exclude test Galeri_double_Jacobi_HalfPrecision when complex<float> not supported (trilinos#10635, trilinos#362) Thyra: Use Teuchos vars to consistent ETI including for float and complex<float> (trilinos#10635, trilinos#362) Teuchos: Support ETI macros do complex<double> without complex<float> (trilinos#10635, trilinos#362) name default mpi tag constants Remove ifdefs for SUN_CXX (trilinos#10636) Tpetra: Get rid of unnecessary function on DistributorActor Tpetra: Strip out remainder of deprecated useDistinctTags usage Tpetra: remove the no-longer-necessary DistributorPlan::getTag Tpetra: use DistributorActor's tag for all communication in the actor Tpetra: change pathTags so Plan's is 0 Tpetra: add missing include in DistributorActor Tpetra: Add a variable to store the MPI tag for DistributorActor

bartlettroscoe added type: enhancement Issue is an enhancement, not a bug pkg: Tpetra pkg: Teuchos Issues primarily dealing with the Teuchos Package pkg: Thyra Issues primarily dealing with the Thyra Package labels May 17, 2016

bartlettroscoe added this to the Reduce build times for Trilinos milestone May 17, 2016

mhoemmen changed the title ~~Disable float and complex scalar types by default for Trilinos and provide global enable options~~ Provide Trilinos-global CMake options to make it easier for apps to disable float & complex Scalar types May 18, 2016

bartlettroscoe mentioned this issue Jul 2, 2016

Set up robust portable pre-push and post-push CI tools and process based on the SEMS Dev Env #482

Closed

bartlettroscoe mentioned this issue Aug 5, 2016

Create a SEMSDevEnv.cmake file to automatically use loaded SEMS dev env #158

Closed

mhoemmen added the story The issue corresponds to a Kanban Story (vs. Epic or Task) label Sep 16, 2016

mhoemmen added this to the Tpetra-backlog milestone Nov 2, 2016

bartlettroscoe added a commit that referenced this issue Nov 29, 2016

Merge branch 'cleanup-better-ci-build-482' into develop (#482, #362, #…

0acaa65

…158, #831, #811, #826, #410)

bartlettroscoe closed this as completed Dec 10, 2016

bartlettroscoe removed the stage: in review Primary work is completed and now is just waiting for human review and/or test feedback label Dec 10, 2016

bartlettroscoe mentioned this issue Dec 10, 2016

Teuchos, Sacado, and Anasazi to split ENABLE_COMPLEX into ENABLE_COMPLEX_FLOAT and ENABLE_COMPLEX_DOUBLE #916

Closed

mhoemmen mentioned this issue Mar 29, 2017

Write new ETI system compatible with Makefile-based build system kokkos/kokkos-kernels#21

Closed

bartlettroscoe mentioned this issue Apr 20, 2017

Amesos2: Implement Umfpack wrappers for Amesos2 #1069

Merged

bartlettroscoe mentioned this issue May 16, 2017

New compile error in NOX_LAPACK_LinearSolver.H #1327

Closed

This was referenced Jun 2, 2017

Get templated code in Trilinos to use ETI as much as possible to reduce (re)build times and resources #1388

Open

Make Trilinos' use of ETI consistent #546

Closed

bartlettroscoe mentioned this issue Jun 21, 2022

teuchos: Teuchos_ExplicitInstantiationHelpers.hpp incorrectly instantiates for complex<float> if Trilinos_ENABLE_FLOAT and Trilinos_ENABLE_COMPLEX_DOUBLE are set to ON, but TRILINOS_ENABLE_COMPLEX_FLOAT is off. #10635

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Provide Trilinos-global CMake options to make it easier for apps to disable float & complex Scalar types #362

Provide Trilinos-global CMake options to make it easier for apps to disable float & complex Scalar types #362

bartlettroscoe commented May 17, 2016 •

edited by mhoemmen

Loading

mhoemmen commented May 17, 2016

bartlettroscoe commented May 17, 2016

mhoemmen commented May 18, 2016

bartlettroscoe commented May 18, 2016

bartlettroscoe commented May 18, 2016

mhoemmen commented May 24, 2016

bartlettroscoe commented May 24, 2016

wfspotz commented May 24, 2016

mhoemmen commented May 26, 2016

bartlettroscoe commented May 26, 2016

mhoemmen commented May 26, 2016

mhoemmen commented May 26, 2016 •

edited

Loading

mhoemmen commented May 26, 2016

bartlettroscoe commented Jun 24, 2016

bartlettroscoe commented Jun 25, 2016

crtrott commented Jun 27, 2016

bartlettroscoe commented Jun 29, 2016

crtrott commented Jun 29, 2016

bartlettroscoe commented Jun 29, 2016

crtrott commented Jun 29, 2016

bartlettroscoe commented Dec 10, 2016

Provide Trilinos-global CMake options to make it easier for apps to disable float & complex Scalar types #362

Provide Trilinos-global CMake options to make it easier for apps to disable float & complex Scalar types #362

Comments

bartlettroscoe commented May 17, 2016 • edited by mhoemmen Loading

mhoemmen commented May 17, 2016

bartlettroscoe commented May 17, 2016

mhoemmen commented May 18, 2016

bartlettroscoe commented May 18, 2016

bartlettroscoe commented May 18, 2016

mhoemmen commented May 24, 2016

bartlettroscoe commented May 24, 2016

wfspotz commented May 24, 2016

mhoemmen commented May 26, 2016

bartlettroscoe commented May 26, 2016

mhoemmen commented May 26, 2016

mhoemmen commented May 26, 2016 • edited Loading

mhoemmen commented May 26, 2016

bartlettroscoe commented Jun 24, 2016

bartlettroscoe commented Jun 25, 2016

crtrott commented Jun 27, 2016

bartlettroscoe commented Jun 29, 2016

crtrott commented Jun 29, 2016

bartlettroscoe commented Jun 29, 2016

crtrott commented Jun 29, 2016

bartlettroscoe commented Dec 10, 2016

bartlettroscoe commented May 17, 2016 •

edited by mhoemmen

Loading

mhoemmen commented May 26, 2016 •

edited

Loading