forked from trilinos/Trilinos
-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathRELEASE_NOTES
6331 lines (4655 loc) · 271 KB
/
RELEASE_NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
###############################################################################
# #
# Trilinos Release 12.4 Release Notes #
# #
###############################################################################
Overview:
The Trilinos Project is an effort to develop algorithms and enabling
technologies within an object-oriented software framework for the solution of
large-scale, complex multi-physics engineering and scientific problems.
Packages:
The Trilinos 12.4 general release contains 58 packages: Amesos, Amesos2,
Anasazi, AztecOO, Belos, CTrilinos, Didasko, Domi, Epetra, EpetraExt, FEI,
ForTrilinos, Galeri, GlobiPack, Ifpack, Ifpack2, Intrepid, Isorropia, Kokkos,
Komplex, LOCA, Mesquite, ML, Moertel, MOOCHO, MueLu, NOX, Optika, OptiPack,
Pamgen, Phalanx, Pike, Piro, Pliris, PyTrilinos, ROL*, RTOp, Rythmos, Sacado,
SEACAS, Shards, ShyLU, STK, Stokhos, Stratimikos, Sundance, Teko, Teuchos,
ThreadPool, Thyra, Tpetra, TriKota, TrilinosCouplings, Trios, Triutils, Xpetra,
Zoltan, Zoltan2.
(* denotes package is being released externally as a part of Trilinos for the
first time.)
Amesos2
- Added MUMPS 5.0 support
- KLU2 is enabled by default
- Bug fixes
- Superlu_dist multiple version support (up to 4.0)
Domi
- Various bug fixes:
- Fixed a bug where a periodic axis under a serial build would not
update communication padding. The parallel version uses MPI
capabilities to do this, so a serial-only capability had to be
added for this corner case.
- Fixed a test that was doing a dynamic type comparison to be more
robust.
- Fixed some minor bugs in the MDVector getTpetraMultiVector()
method.
- The MDArrayView size() method was made const, as it should be
- Created serial tests
- Domi does not provide much in the way of unique capabilities if it
is compiled in serial. Nevertheless, all tests that run on 1
processor were updated to run under a serial build of Trilinos as
well.
Ifpack2
- Deprecated Ifpack2::Krylov
If you want a Krylov solver, just use Belos. Ifpack2::Factory now
throws with an informative exception message if you ask for "KRYLOV".
Muelu
- MueLu requires certain C++11 features. Minimum compiler versions are
gcc 4.7.2 or icc 13. (See https://trilinos.org/about/cxx11.)
- Kokkos is a required dependency.
- New MatrixAnalysis Factory.
- Deprecated Create[TE]petraPreconditioner interfaces taking
Tpetra::CrsMatrix types as input argument in favor of interfaces
accepting Tpetra::Operator types.
- Numerous improvements to MueMex (MueLu's interface to Matlab).
- Mumps can now be used as a coarse grid solver through Amesos2.
- Unification of MueLu Epetra and Tpetra interfaces through Stratimikos.
PyTrilinos
- General
- Fixed several memory management bugs
- Fixed a pervasive bug where C++ exceptions were caught in the
wrong order. This fix results in Python errors that have much
better messages, making it easier to debug problems that employ
cross-language polymorphism.
- Epetra
- Added new Python-to-C++ converters that convert a wider variety of
Python objects to distributed Epetra vectors (Epetra_MultiVector,
Epetra_Vector, Epetra_IntVector). This includes any Python object
that exports the Distributed Array Protocol, such as Enthought's
DistArray. It also includes NumPy arrays when running in a serial
environment.
- Added __distarray__() method to Epetra vector classes, so that
they now export the Distributed Array Protocol.
- Memory management issues associated with the Epetra.LinearProblem
class and the new Epetra vector converters were fixed.
- Tpetra
- Fixed wrappers for Tpetra MultiVector and Vector classes.
- Added __distarray__() method to Tpetra vector classes, so that
they now export the Distributed Array Protocol.
- Bug fixes related to latest Tpetra upgrade
- LOCA
- Introduced a new LOCA test in which the Chan problem is solved
using a preconditioner.
ROL
- Enhancements
- Hierarchical XML parameter lists. This makes ROL easier to use and
control. Demonstrated in all examples and test. Also created
the tierParameterList function to generate a hierarchical list
from a flat list, in rol/src/zoo/ROL_ParameterListConverters.hpp,
demonstrated in rol/test/parameters.
- Algorithm constructor now takes reference-counted pointers to
Step and StatusTest. There is another constructor that takes a step
name (string) and a parameter list. This makes it easier to initialize
a ROL algorithm, based on default choices of steps and status tests.
- New elementwise functions in ROL::Vector allow application of general
nonlinear unary and binary functions as well as reduce operations.
- Modified ROL::BoundConstraint to work with any vector type for which
Vector::applyUnary, Vector::applyBinary, and Vector::reduce are
implemented.
- Modified default behavior of line search so that when the maximum
number of function evaluations is reached and sufficient decrease has
not been attained, optimization terminates. The previous behavior can
be recovered by setting the parameter "Accept Last Alpha" to true in
the Step->Line Search sublist.
- Added line search parameter "Accept Linesearch Minimizer" to the
Step->Line Search sublist. If this parameter is selected to be true,
the argmin step length will be used if the maximum number of function
evaluations is reached without attaining sufficient decrease.
- Renamed CompositeStepSQP to CompositeStep.
- New Features
- Methods
- Bundle Step, for solving nonsmooth problems; see example/minimax/*.
- Moreau-Yosida Penalty, for solving general NLPs; see
example/burgers-control/example_04.
- Augmented Lagrangian, for solving general NLPs; see
example/burgers-control/example_04.
- Higher Moment Coherent Risk Measure. This method is a new risk measure
for stochastic problems, see example/burgers-control/example_06.
- Buffered Probability of Exceedance. This method is a new capability to
minimize the probability of a stochastic cost function. It is
demonstrated in example/burgers-control/example_06.
- Infrastructure
- In ROL_ScaledStdVector.hpp, added a variant of ROL::StdVector that
supports constant (positive) diagonal scalings in the dot product.
This variant comprises the pair of classes ROL::PrimalScaledStdVector
and ROL::DualScaledStdVector; changed the examples in
example/diode-circuit to use variable scalings through these new
classes.
- Distribution Factory, to enable general sampling for stochastic
problems; demonstrated in example/burgers-control/example_05 through
_07.
- SROMSampler. This method permits the use of optimization-based
sampling for stochastic problem. It is demonstrated in
test/sol/test_04.
- ROL::PartitionedVector, for handling vectors of vectors, e.g., when
using slack variables, see /rol/test/vector/test_04.cpp.
- Bug Fixes
- Removed reset of counters for objective function and gradient evaluations
contained in the AlgorithmState in rol/src/step/ROL_TrustRegionStep.hpp.
- Corrected reading of the constraint tolerance parameter in
ROL::AugmentedLagrangianStep.
Tpetra
- Changed CMake option for setting default Node type
To set the default Node type, use the Tpetra_DefaultNode CMake option.
We support the old KokkosClassic_DefaultNode CMake option for
backwards compatibility.
Tpetra will eventually change from using Node types to using
Kokkos::Device types directly. For now, though, if you wish to set
the default Node type explicitly, you must use one of the following:
- Kokkos::Compat::KokkosCudaWrapperNode (CUDA)
- Kokkos::Compat::KokkosOpenMPWrapperNode (OpenMP)
- Kokkos::Compat::KokkosSerialWrapperNode (Serial (no threads))
- Kokkos::Compat::KokkosThreadsWrapperNode (Pthreads)
Tpetra normally only enables one Node type, so you only need to set
the default Node type if you have enabled more than one Node type.
- Rules for which Node type gets enabled by default
Tpetra only enables one Node type by default, whether or not ETI
(explicit template instantiation) is enabled. Here are the rules for
which Node type gets enabled by default:
1. If you're building with CUDA, Tpetra uses CUDA by default.
2. Otherwise, if you're building with OpenMP, Tpetra uses OpenMP by
default.
3. Otherwise, if Kokkos enables the Serial execution space (if
Kokkos_ENABLE_Serial is ON), Tpetra uses Serial by default.
4. Otherwise, if Kokkos enables the Threads execution space (if
Kokkos_ENABLE_Pthread is ON), Tpetra uses Threads by default.
If you wish to enable other Node types, you may set the following
CMake options. You do NOT need to set any of these options explicitly
if the Node type would be enabled by default anyway.
- Tpetra_INST_CUDA (Kokkos_ENABLE_Cuda must be ON, and Trilinos must
be built with CUDA; ON by default if building with CUDA)
- Tpetra_INST_OPENMP (Kokkos_ENABLE_OpenMP must be ON, and Trilinos
must be built with OpenMP support)
- Tpetra_INST_PTHREAD (Kokkos_ENABLE_Pthread must be ON)
- Tpetra_INST_SERIAL (Kokkos_ENABLE_Serial must be ON)
While it is legal to enable both the OpenMP and Pthreads back-ends in
the same executable, it is a bad idea. Both back-ends spawn their own
worker threads, and those threads will fight over cores.
- Completely removed the "classic" version of Tpetra
You might recall that a while back, we split Tpetra into "classic"
(old) and "Kokkos refactor" (new) versions. As of Trilinos 12.0, the
classic version was no longer supported, but we kept it in place for a
few users. As of this release, we have removed the classic version
completely.
You no longer need to set Tpetra_ENABLE_Kokkos_Refactor to get the new
verson of Tpetra. It is ON (TRUE). If you attempt to set it to OFF
(FALSE), Tpetra's CMake raises an error at configure time. Just
enable Tpetra -- that's all you need to do!
This change affects both the Classic and Core subpackages of Tpetra.
All the "classic" Node types are gone now, along with their associated
computational kernels. Use the Kernels subpackage of Tpetra for local
kernels. (We left KokkosClassic::DefaultArithmetic in place for
Stokhos, but ONLY for Stokhos.) The "classic" versions of Tpetra
classes are also now gone. We have replaced them completely with
their "Kokkos refactor" versions.
You might have noticed that Doxygen had a hard time generating
documentation for the classes which had "classic" and "refactor"
versions. These changes should fix that. Furthermore, it's easier to
find header files for classes. In particular, most of the header
files in the tpetra/core/src/kokkos_refactor directory now just have
trivial definitions and only remain for backwards compatibility.
- Improved build times and fewer .cpp files in source directory
Tpetra does a better job now of splitting up explicit instantiations
into separate .cpp files. In some cases, it uses CMake to generate
those .cpp files automatically. This means fewer .cpp files in
tpetra/core/src, so it's easier to find what you want.
- 128-bit floating-point arithmetic through Scalar = __float128
__float128 is a GCC language extension to C(++) that implements
"double-double" 128-bit floating-point arithmetic. It requires
linking with libquadmath, which comes with GCC.
You must use GCC in order to try this feature. Also, set the
following CMake variables:
Tpetra_INST_FLOAT128:BOOL=ON
CMAKE_CXX_FLAGS:STRING="-std=gnu++11 -fext-numeric-literals"
TPL_ENABLE_quadmath:BOOL=ON
You may also have to tell CMake where to find the libquadmath library
and quadmath.h header file:
quadmath_LIBRARY_DIRS:FILEPATH="${QUADMATH_LIB_DIR}"
quadmath_INCLUDE_DIRS:FILEPATH="${QUADMATH_INC_DIR}"
Here, ${QUADMATH_LIB_DIR} points to the directory containing the
libquadmath library (usually your GCC library directory), and
${QUADMATH_INC_DIR} points to the directory containing its header file
(quadmath.h). For example, if you use a GCC installed in
$HOME/pkg/gcc-5.2.0, you might need to set those variables as follows:
QUADMATH_LIB_DIR=$HOME/pkg/gcc-5.2.0/lib
QUADMATH_INC_DIR=\
$HOME/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include
Trilinos likes to set the "-pedantic" flag, which causes warnings for
__float128 literals. The build works regardless, but it would be more
pleasing to your eyes if you could figure out how to shut off the
warnings.
I implemented this because the Kokkos refactor of Tpetra broke QD
support (dd_real and qd_real -- "double-double" and "quad-double,"
128- resp. 256-bit floating-point arithmetic). Applications were
asking for a work-around solution.
Zoltan2
- Template argument for arbitrary global identifiers (zgid_t) has been
removed for greater efficiency in the code as well as greater conformity
with Trilinos.
- BasicUserTypes now has only three template parameters;
the zgid_t template argument has been removed.
- OrderingSolution now has two different template parameters:
<lno_t, gno_t> for <local ordinal type, global ordinal type>
- A new test driver capability has been added to Zoltan2 for more robust
testing and experimentation.
- An interface to the Zoltan partitioners has been added to Zoltan2.
Parameter "algorithm" == "zoltan" invokes Zoltan partitioners; parameters
needed by Zoltan are provided through a parameter sublist called
"zoltan_parameters". Zoltan's geometric and hypergraph methods are
available.
- A new interface to third-party library ParMA (from Rensselaer Polytechnic
Institute) is available. ParMA provides mesh partition improvement to
balance both primary and secondary entities.
It assumes the number of processors is equal to the number of requested
parts, and that the input mesh distribution corresponds to the input part
assignments. RPI's SCOREC repository is needed to use ParMA.
- A new hypergraph mesh partitioning model is available in Zoltan2
through the MeshAdapter.
- Parameters to third-party libraries Scotch and ParMETIS are provided
through parameter sublists "scotch_parameters" and
"parmetis_parameters", respectively.
###############################################################################
# #
# Trilinos Release 12.2 Release Notes #
# #
###############################################################################
Overview:
The Trilinos Project is an effort to develop algorithms and enabling
technologies within an object-oriented software framework for the solution of
large-scale, complex multi-physics engineering and scientific problems.
Packages:
The Trilinos 12.2 general release contains 58 packages: Amesos, Amesos2,
Anasazi, AztecOO, Belos, CTrilinos, Didasko, Domi, Epetra, EpetraExt, FEI,
ForTrilinos, Galeri, GlobiPack, Ifpack, Ifpack2, Intrepid, Isorropia, Kokkos,
Komplex, LOCA, Mesquite, ML, Moertel, MOOCHO, MueLu, NOX, Optika, OptiPack,
Pamgen, Phalanx, Pike, Piro, Pliris, PyTrilinos, ROL*, RTOp, Rythmos, Sacado,
SEACAS, Shards, ShyLU, STK, Stokhos, Stratimikos, Sundance, Teko, Teuchos,
ThreadPool, Thyra, Tpetra, TriKota, TrilinosCouplings, Trios, Triutils, Xpetra,
Zoltan, Zoltan2.
(* denotes package is being released externally as a part of Trilinos for the
first time.)
Domi
- Input arguments that come in the form of const Domi::MDArrayView<
int > have been changed to be const-correct, i.e., they are now
const Domi::MDArrayView< const int >. This allowed for more logical
wrappers in PyTrilinos.
- A new Domi::DefaultNode class has been added. If Tpetra is enabled,
it uses the Tpetra default node. If Tpetra is not enabled, it uses
the serial wrapper node from Teuchos.
- Domi's required dependencies have been simplified, to Teuchos,
Kokkos, and TeuchosKokkosCompat. Optional dependencies are Epetra,
TpetraClassic, and TpetraCore.
MueLu
- Allow to dynamically switch transfer operators between different multigrid
levels. Can be used in context of semi-coarsening.
- Enabled semi-coarsening (using Ray's line detection algorithm).
- Add support for line smoothing (Ifpack/Ifpack2) [EXPERIMENTAL]
- New AMGX Adapter [EXPERIMENTAL]
New experimental adapter which allows a user with AMGX installed to utilize
this software for the preconditioning and solution of linear systems. If a
user provides AMGX configuration options instead of a MueLu input deck, the
adapter will be called. Currently supported with Tpetra objects.
- Matlab interface for MueLu [EXPERIMENTAL]
Setup and solve hierarchies from Matlab and use Matlab functions as MueLu
factories.
PyTrilinos
- General
- Updated the Developers Guide
- Teuchos
- Made Teuchos a required dependency for PyTrilinos.
- Domi
- Domi wrappers now use new Domi::DefaultNode class
- Added HAVE_DOMI as a macro in PyTrilinos_config.h
- Fixed docstrings for Domi package
- Added a simple Domi example
- Fixed Domi.MDVector extensions
- Tpetra
- Enabled Tpetra wrappers in the release branch
- Fixed a dynamic typing problem
- Bug fixes in Tpetra.Map
- Added HAVE_TPETRA as a macro in PyTrilinos_config.h
- Fixed docstrings for Tpetra package
- Got wrappers for all requiredTpetra constructors to work
- Expanded Tpetra.Vector unit tests
- Added unit tests for Tpetra.MultiVector
ROL
Rapid Optimization Library (ROL) is a C++ package for large-scale
optimization. It is used for the solution of optimal design, optimal control
and inverse problems in large-scale engineering applications. Other uses
include mesh optimization and image processing.
ROL aims to combine flexibility, efficiency and robustness. Key features:
- Matrix-free application programming interfaces (APIs) --enable direct use
of application data structures and memory spaces, linear solvers,
nonlinear solvers and preconditioners.
- State-of-the-art algorithms for unconstrained optimization, constrained
optimization and optimization under uncertainty --enable inexact and
adaptive function evaluations and iterative linear system solves.
- Special APIs for simulation-based optimization --enable a streamlined
embedding into engineering applications, rigorous implementation
verification and efficient use.
- Modular interfaces throughout the optimization process --enable custom
and user-defined algorithms, stopping criteria, hierarchies of algorithms,
and selective use of a variety of tools and components.
For a detailed description of user interfaces and algorithms included in this
release, see the presentation ROL-Trilinos-12.2.pptx (or .pdf) in the
doc/presentations directory.
Tpetra
- Improvements to the "local" part of Tpetra::Map
Tpetra::Details::FixedHashTable implements the "local" part of
Tpetra::Map, where the "local part" is that which does not use MPI
communication. For example, FixedHashTable knows how to convert from
global indices to local indices, for all the global indices known by
the calling process.
FixedHashTable now uses Kokkos for its data structures. Its
initialization is completely Kokkos parallel, and its conversions
between global and local indices are Kokkos device functions. This
achieves an important goal of making the local part of Tpetra::Map
functionality available for Kokkos parallel operations.
- Many Tpetra classes now split instantiations into multiple files
This matters only when explicit template instantiation (ETI) is ON.
(This _should_ be ON by default, but is not ON by default yet.)
The largest Tpetra classes (e.g., CrsGraph, CrsMatrix, and
MultiVector) now split their explicit instantiations into multiple
.cpp files. This helps reduce build times and memory usage when ETI
is ON, and makes setting ETI ON an even more attractive option for
applications.
- Fixed Bugs 6335, 6336, 6377, and others
- Improved tests to catch errors on processes other than Process 0
- Improved CMake output and internal ETI-related documentation
###############################################################################
# #
# Trilinos Release 12.0 Release Notes #
# #
###############################################################################
Overview:
The Trilinos Project is an effort to develop algorithms and enabling
technologies within an object-oriented software framework for the solution of
large-scale, complex multi-physics engineering and scientific problems.
Packages:
The Trilinos 12.0 general release contains 57 packages: Amesos, Amesos2,
Anasazi, AztecOO, Belos, CTrilinos, Didasko, Domi, Epetra, EpetraExt, FEI,
ForTrilinos, Galeri, GlobiPack, Ifpack, Ifpack2, Intrepid, Isorropia, Kokkos,
Komplex, LOCA, Mesquite, ML, Moertel, MOOCHO, MueLu, NOX, Optika, OptiPack,
Pamgen, Phalanx, Pike, Piro, Pliris, PyTrilinos, RTOp, Rythmos, Sacado, SEACAS,
Shards, ShyLU, STK, Stokhos, Stratimikos, Sundance, Teko, Teuchos, ThreadPool,
Thyra, Tpetra, TriKota, TrilinosCouplings, Trios, Triutils, Xpetra, Zoltan,
Zoltan2.
Domi
Domi provides distributed data structures for multi-dimensional data.
The inspirational use case is parallel domain decomposition for finite
difference applications. To that end, Domi provides the following
classes:
- MDArray, MDArrayView, MDArrayRCP
These classes define multi-dimensional arrays, with arbitrary
runtime-defined dimensions, built on top of the Teuchos Array,
ArrayView, and ArrayRCP classes, respectively. These are serial
in nature and provide the mechanism for data manipulation on each
processor of distributed MDVectors.
- Slice
The Slice class is inspired by the Python slice object, which
stores a start, stop, and step index, and can be constructed to
utilize a variety of logical default values. Slices can be used
on all multi-dimensional objects to return views into subsets of
those objects.
- MDComm
Multi-dimensional communicator. This communicator provides a map
between a multi-dimensional array of processors and their ranks,
and can be queried for neighbor ranks. MDComms can be sliced,
which returns a sub-sommunicator.
- MDMap
An MDMap describes the decomposition of an MDVector on an MDComm.
It stores the start and stop indexes along each dimension,
including boundary padding for algorithms that require extra
indexes along boundaries, and communication padding used to
update values from neighboring processors. MDMaps can be sliced,
and the resulting MDMap may reside on a sub-communicator. An
MDMap can be converted to an equivalent Epetra or Tpetra Map.
- MDVector
An MDVector is a multi-dimensional array, distrubuted in a
structured manner across multiple processors. This distribution
is described by an MDVector's MDMap. The MDVector's data is
stored locally on each processor with an MDArrayRCP. An MDVector
can update its communication padding from neighboring processors
automatically. An MDVector can be sliced, and the resulting
MDVector may reside on a sub-communicator. An MDVector can be
converted to equivalent Epetra or Tpetra Vectors or MultiVectors.
If there are no stride gaps in the data due to slicing, these
converted Epetra and Tpetra objects may be views of the original
data.
MueLU
- Hierarchy::Iterate now understands tolerance
When MueLu::Hierarchy is being used as a standalone solver, and not as a
preconditioner, a user may now create a stopping criteria based on a
provided tolerance for the relative residual in addition to the maximum
number of iterations
- New reuse options option: "tP"
This reuse option allows reuse of only tentative prolongators, while
rebuilding smoothed prolongator and coarse level operators.
- Selected bugfixes:
6301: Operator complexity was computed incorrectly for large size
problems
Pike
PIKE: Physics Integration KErnels
Pike is a blackbox multiphysics coupling tool. It provides basic
interfaces and implementations for building high level multiphysics
coupling strategies. In particular, PIKE provides utilities for
Picard-style couplings. For Newton-based couplings, use the NOX and
Thyra packages to build the block phsyics systems. In the future,
interoperability tools between NOX, PIKE and PIRO will be added.
- Initial release!
- Supports block Jacobi and block Gauss-Seidel coupling.
- Supports global and local convergence criteria.
- Supports hierarchical solves.
- Supports subcycled transient solves and steady-state.
- Support both Parameter and Response interfaces.
- Contains a multiphysics distributor to support parallel
distribution of applications.
- Provides abstract factories for solvers and global status tests
- Supports observers for user injection of code. Special observers
for logging and debugging are implemeted.
- Pure virtual interfaces for applications and data transfers.
- Adapter for nesting a solver as a model evaluator for hierarchical
solves.
****************************************
PyTrilinos
- General
- Changed to BSD license
- Mpi4Py support has been made optional. Previously, if Mpi4Py was
found, it was automatically enabled within PyTrilinos. Now that
behavior can be turned off.
- LOCA
- The LOCA module has been refactored and now has been demonstrated
to work for the Chan problem. We have two example problems
working, one without preconditioning, and one with.
- Tpetra
- Package is still experimental. The recent refactor has broken
MultiVectors and Vectors.
- Map support has been improved
- Anasazi
- Fixed a bug where return eigenvalues are converted to a NumPy
array, but the dimension used the wrong type.
- Kokkos
- Fixed a macro issue
- NOX
- Started PETSc compatibility. This is still experimental, and
includes compatibility with petsc4py.
- STK
- Removed PyPercept, as it is currently not a part of the new STK.
- Domi
- Added package
Tpetra
- Tpetra now requires C++11
This requirement comes in part from Tpetra itself, and in part from
the Kokkos package, on which Tpetra depends.
- "Kokkos refactor" (new) version of Tpetra is the only version
We no longer enable or support the old ("classic") version of Tpetra.
The new ("Kokkos refactor") implementation of Tpetra is now the only
supported version.
Do not use any of the Node types in the KokkosClassic namespace. We
do not support any of those Node types anymore. Instead, use any of
the following Node types:
- Kokkos::Compat::KokkosOpenMPWrapperNode (OpenMP)
- Kokkos::Compat::KokkosCudaWrapperNode (NVIDIA CUDA)
- Kokkos::Compat::KokkosSerialWrapperNode (no threads)
- Kokkos::Compat::KokkosThreadsWrapperNode (Pthreads)
Each of these is a typedef for
Kokkos::Compat::KokkosDeviceWrapperNode<ExecSpace>, for the
corresponding Kokkos execution space.
- Set / rely on the default Node type as much as possible
Tpetra classes have a template parameter, "Node", which determines
what thread-level parallel programming model Tpetra will use. This
corresponds directly to the "execution space" concept in Kokkos.
Tpetra classes have a default Node type. Users do NOT need to specify
this explicitly. I cannot emphasize this enough:
IF YOU ONLY EVER USE THE DEFAULT VALUES OF TEMPLATE PARAMETERS, DO NOT
SPECIFY THEM EXPLICITLY.
If you need to refer to the default values of template parameters, ask
Tpetra classes. For example, 'Tpetra::Map<>::node_type' is the
default Node type.
Tpetra pays attention to Kokkos' build configuration when determining
the default Node type. For example, it will not use a disabled
execution space. If you do not like the default Node type, but you
only ever use one Node type in your application, you should change the
default Node type at Trilinos configure time. You may do this by
setting the 'KokkosClassic_DefaultNode' CMake option. Here is a list
of reasonable values:
"Kokkos::Compat::KokkosSerialWrapperNode": use Kokkos::Serial
execution space (execute in a single thread on the CPU)
"Kokkos::Compat::KokkosOpenMPWrapperNode": use Kokkos::OpenMP
execution space (use OpenMP for thread-level parallelism on the CPU)
"Kokkos::Compat::KokkosThreadsWrapperNode": use Kokkos::Threads
execution space (use Pthreads (the POSIX Threads library) for
thread-level parallelism on the CPU)
"Kokkos::Compat::KokkosCudaWrapperNode": use Kokkos::Cuda execution
space (use NVIDIA's CUDA programming model for thread-level
parallelism on the CPU)
You must use the above strings with the 'KokkosClassic_DefaultNode'
CMake option. If you choose (unwisely, in many cases) to specify the
Node template parameter directly in your code, you may use those
names. Alternately, you may let the Kokkos execution space determine
the Node type, by using the templated class
Kokkos::Compat::KokkosDeviceWrapperNode. This class is templated on
the Kokkos execution space. The above four types are typedefs to
their corresponding specializations of KokkosDeviceWrapperNode. For
example, KokkosSerialWrapperNode is a typedef of
KokkosDeviceWrapperNode<Kokkos::Serial>. This may be useful if your
code already makes use of Kokkos execution spaces.
- Removed (deprecated classes) Tpetra::VbrMatrix, Tpetra::BlockMap,
Tpetra::BlockCrsGraph, and Tpetra::BlockMultiVector.
All these classes relate to VBR (variable-block-size block sparse
matrix) functionality. We may reimplement that at some point, but for
now it's going away.
- Removed (deprecated class) Tpetra::HybridPlatform
Teuchos
- Fixed Teuchos::Ptr::operator=() to catch dangling references (6 April 2015)
###############################################################################
# #
# Trilinos Release 11.14 Release Notes #
# #
###############################################################################
Overview:
The Trilinos Project is an effort to develop algorithms and enabling
technologies within an object-oriented software framework for the solution of
large-scale, complex multi-physics engineering and scientific problems.
Packages:
The Trilinos 11.14 general release contains 55 packages: Amesos, Amesos2,
Anasazi, AztecOO, Belos, CTrilinos, Didasko, Epetra, EpetraExt, FEI,
ForTrilinos, Galeri, GlobiPack, Ifpack, Ifpack2, Intrepid, Isorropia, Kokkos,
Komplex, LOCA, Mesquite, ML, Moertel, MOOCHO, MueLu, NOX, Optika, OptiPack,
Pamgen, Phalanx, Piro, Pliris, PyTrilinos, RTOp, Rythmos, Sacado, SEACAS,
Shards, ShyLU, STK, Stokhos, Stratimikos, Sundance, Teko, Teuchos, ThreadPool,
Thyra, Tpetra, TriKota, TrilinosCouplings, Trios, Triutils, Xpetra, Zoltan,
Zoltan2.
Muelu
- Support for Amesos2 native serial direct solver "Basker".
- ML parameters can be used through MueLu::CreateEpetraPreconditioner and
MueLu::CreateTpetraPreconditioner interfaces
- Several bug fixes:
6256: ML parameter "coarse: type" does not work in
MueLu::MLParameterListInterpreter
6255: Multiple issues in MueLu::MLParameterListInterpreter
- Explicit template instantiation (ETI) changes
The new version of MueLu uses Tpetra macros for specifying the desired
template instantiations values (scalars, local ordinals, global ordinals and
note types). As such, Tpetra instantiation configure options provide the
necessary MueLu instantiations. For instance, instead of the previous option
-D MueLu_INST_DOUBLE_INT_LONGLONGINT=ON
a user should write
-D Tpetra_INST_INT_LONG_LONG
See Tpetra documentation for a full set of options.
- New reuse feature [EXPERIMENTAL]
MueLu introduced a new experimental reuse feature. A user may specify
partial preservation of a multigrid hierarchy through the "reuse: type"
option. Few variants have been implemented:
- "none"
No reuse, the preconditioner is constructed from scratch
- "emin"
Reuse old prolongator as an initial guess to energy minimization, and
reuse the prolongator pattern.
- "RP"
Reuse smoothed prolongator and restrictor. Smoothers and coarse grid
operators are recomputed.
- "RAP"
Recompute only the finest level smoother.
- "full"
Reuse full hierarchy, no changes.
The current user interface is as follows:
// User constructs a hierarchy for the first time
Teuchos::RCP<MueLu::TpetraOperator<SC,LO,GO,NO> > H =
MueLu::CreateTpetraPreconditioner<SC,LO,GO,NO>(A0, xmlFileName);
...
// User reuses existing hierarchy for consequent steps
MueLu::ReuseTpetraPreconditioner(A1, *H);
- Support for user-provided data [EXPERIMENTAL]
New release of MueLu allows user to provide the data for the first few
levels of the multigrid Hierarchy, while allowing MueLu to construct
remaining levels. At the minimum, user needs to provide the data for
fine-level operator A, prolongation operator (P), restriction operator (R)
and coarse-level operator (Ac). These operator are required to derive from
Xpetra::Operator class. This scenario is driven through a ParameterList
interface (see muelu/example/advanced/levelwrap for some use cases).
Tpetra
- Public release of "Kokkos refactor" version of Tpetra
The "Kokkos refactor" version of Tpetra is a new implementation of
Tpetra. It is based on the new Kokkos programming model in the
KokkosCore subpackage. It coexists with the "classic" version of
Tpetra, which has been DEPRECATED and will be removed entirely in the
12.0 major release of Trilinos. Thus, the Kokkos refactor version
will become the /only/ version of Tpetra at that time.
The Kokkos refactor version of Tpetra maintains mostly backwards
compatibility [SEE NOTE BELOW] with the classic version's interface.
Its interface will continue to evolve. For this first public release,
we have prioritized backwards compatibility over interface innovation.
The implementation of the Kokkos refactor version of Tpetra currently
lives in tpetra/core/src/kokkos_refactor. It works by partial
specialization on the 'Node' template parameter, and by a final 'bool'
template parameter (which users must NEVER SPECIFY EXPLICITLY). The
"classic" version of Tpetra uses the old ("classic") Node types that
live in the KokkosClassic namespace. All of the classic Node types
have been DEPRECATED, which is how users can see that classic Tpetra
has been deprecated.
If you wish to disable the Kokkos refactor version of Tpetra, set the
Tpetra_ENABLE_Kokkos_Refactor CMake option to OFF. Please note that
this will result in a large number of warnings about deprecated
classes. This CMake option will go away in the 12.0 release.
- Note on backwards compatibility of Tpetra interface
In the new version of Tpetra, MultiVector and Vector implement /view
semantics/. That is, the one-argument copy constructor and the
assignment operator (operator=) perform shallow copies. (By default,
in the classic version of Tpetra, they did deep copies.) For deep
copies, use one of the following:
- Two-argument "copy constructor" with Teuchos::Copy as the second
argument (to create a new MultiVector or Vector which is a deep
copy of an existing one)
- Tpetra::deep_copy (works like Kokkos::deep_copy)
- What if I have trouble building with Scalar=std::complex<T>?
The new version of Tpetra should be able to build with Scalar =
std::complex<float> or std::complex<double>. If you have trouble
building, you may disable explicit template instantiation (ETI) and
tests for those Scalar types, using the following CMake options:
Tpetra_INST_COMPLEX_FLOAT:BOOL=OFF
Tpetra_INST_COMPLEX_DOUBLE:BOOL=OFF
- Accessing and changing the default Node type
Tpetra classes have a template parameter, "Node", which determines
what thread-level parallel programming model Tpetra will use. This
corresponds directly to the "execution space" concept in Kokkos.
Tpetra classes have a default Node type. Users do NOT need to specify
this explicitly. I cannot emphasize this enough:
IF YOU ONLY EVER USE THE DEFAULT VALUES OF TEMPLATE PARAMETERS, DO NOT
SPECIFY THEM EXPLICITLY.
If you need to refer to the default values of template parameters, ask
Tpetra classes. For example, 'Tpetra::Map<>::node_type' is the
default Node type.
Tpetra pays attention to Kokkos' build configuration when determining
the default Node type. For example, it will not use a disabled
execution space. If you do not like the default Node type, but you
only ever use one Node type in your application, you should change the
default Node type at Trilinos configure time. You may do this by
setting the 'KokkosClassic_DefaultNode' CMake option. Here is a list
of reasonable values:
"Kokkos::Compat::KokkosSerialWrapperNode": use Kokkos::Serial
execution space (execute in a single thread on the CPU)
"Kokkos::Compat::KokkosOpenMPWrapperNode": use Kokkos::OpenMP
execution space (use OpenMP for thread-level parallelism on the CPU)
"Kokkos::Compat::KokkosThreadsWrapperNode": use Kokkos::Threads
execution space (use Pthreads (the POSIX Threads library) for
thread-level parallelism on the CPU)
"Kokkos::Compat::KokkosCudaWrapperNode": use Kokkos::Cuda execution
space (use NVIDIA's CUDA programming model for thread-level
parallelism on the CPU)
You must use the above strings with the 'KokkosClassic_DefaultNode'
CMake option. If you choose (unwisely, in many cases) to specify the
Node template parameter directly in your code, you may use those
names. Alternately, you may let the Kokkos execution space determine
the Node type, by using the templated class
Kokkos::Compat::KokkosDeviceWrapperNode. This class is templated on
the Kokkos execution space. The above four types are typedefs to
their corresponding specializations of KokkosDeviceWrapperNode. For
example, KokkosSerialWrapperNode is a typedef of
KokkosDeviceWrapperNode<Kokkos::Serial>. This may be useful if your
code already makes use of Kokkos execution spaces.
- Changes to subpackages
Tpetra is now divided into subpackages. What was formerly just
"Tpetra" is now "TpetraCore". Other subpackages of Kokkos have moved,
some into Teuchos and some into Tpetra. Those subpackages have
changed from Experimental (EX) to Primary Tested (PT), so that they
build by default if Tpetra is enabled.
The most important change is that Tpetra now has a required dependency
on the Kokkos programming model. See below.
If your application links against Trilinos using either the
Makefile.export.* system or the CMake FIND_PACKAGE(Trilinos ...)
system, you do not need to worry about this. Just enable Tpetra and
let Trilinos' build system handle the rest.
- New required dependency on Kokkos
Tpetra now has a required dependency on the Kokkos programming model.
In particular, TpetraCore (see above) has required dependencies on the
KokkosCore, KokkosContainers, and KokkosAlgorithms subpackages of
Kokkos.
This means that Tpetra is now subject to Kokkos' build requirements.
C++11 support is still optional in this release, but future releases
will require C++11 support. Please refer to Kokkos' documentation for
more details.
- Deprecated variable-block-size classes (like VbrMatrix).
We have deprecated the following classes in the Tpetra namespace:
- BlockCrsGraph
- BlockMap
- BlockMultiVector (NOT Tpetra::Experimental::BlockMultiVector)
- VbrMatrix
These classes relate to "variable-block-size" vectors and matrices.
Tpetra::BlockMultiVector (NOT the same as
Tpetra::Experimental::BlockMultiVector) implements a
variable-block-size block analogue of MultiVector. Each row of a
MultiVector corresponds to a single degree of freedom; each block row
of a BlockMultiVector corresponds to any number of degrees of freedom.
"Variable block size" means that different block rows may have
different numbers of degrees of freedom. An instance of
Tpetra::BlockMap represents the block (row) Map of a BlockMultiVector.
Tpetra::VbrMatrix implements a variable-block-size block sparse matrix