forked from trilinos/Trilinos
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRELEASE_NOTES
6497 lines (4779 loc) · 278 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.6 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.6 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.)
Ifpack2
- Fixed Ifpack2's part of Bug 6358
Ifpack2, as well as its tests and examples, no longer require
GlobalOrdinal = int to be enabled in Tpetra.
- Fixed Bug 6443
One unit test for RILUK had an excessively tight tolerance for Scalar
= float. This commit relaxes the tolerance in a principled way. As a
result, the test now passes.
ROL
- Enhancements:
- Default template parameters for ROL::TpetraMultiVector.
- StdVector, TpetraMultiVector, and PartitionedVector now do
dimensional compatibility checks.
- More unary and binary elementwise functions added.
- New Features:
- Methods:
- InteriorPointStep class, and classes it uses (e.g. PenalizedObjective,
InequalityConstraint, and CompositeConstraint) to solve Interior Point
problems with the CompositeStep SQP solver with successive penalty
reduction.
- Standalone GMRES solver in the Krylov directory.
- Mixed quantile risk measure.
- New risk measure corresponding to Kullback-Liebler based
distributionally robust optimization.
- SROM SampleGenerator: The associated samples are determined
by solving an optimization problem. Current objective functions
correspond to moment matching and the squared L2 error between
distribution functions.
- The PDE-OPT Application Development Kit (ADK) enables the rapid
prototyping of large-scale risk-averse optimization problems with
PDE constraints. The PDE-OPT ADK comprises three key modules:
-- degree-of-freedom manager, which enables the use of an arbitrary
number of simulation, control, and design fields based on finite
element discretizations, on 1D, 2D and 3D meshes;
-- finite element assembly loops and data structures that enable the
development of a variety of multiphysics components, built on
Intrepid for local finite element computations and Tpetra for
parallel linear algebra data structures;
-- interface between the physics module and the SimOpt programming
interface.
- Infrastructure:
- OptimizationProblem class unifies Algorithm::run interface.
- StochasticProblem allows for the construction of a general
stochastic objective function based on input parameters.
- Generalized CVaRVector to RiskVector. This allows for a very general
treatment of risk-averse optimization problems.
- Risk measure factory.
- Default solve implementation for EqualityConstraint_SimOpt.
- BoundConstraint capability for Interior Point problems with and
without Equality Constraints.
Tpetra
- Better CUDA testing
We added more nightly test builds with CUDA enabled (for running on
NVIDIA GPUs). The builds test various combinations of CUDA with
different compiler versions and host thread parallelism options
(OpenMP, Pthreads, serial). CUDA + GCC 4.7.2 is currently the
best-tested option, but we're using these tests to improve support for
other options.
- CrsMatrix, MultiVector, Vector: Added 'atomic' option to sumInto
The sumIntoLocalValues method in Tpetra::CrsMatrix, and the
sumIntoLocalValue and sumIntoGlobalValue methods in
Tpetra::MultiVector and Tpetra::Vector, now take an optional bool
'atomic' argument. If true, the methods use Kokkos::atomic_add
(atomic +=); if false, they use (non-atomic) += as before.
This lets different threads call the methods concurrently on the same
entry/ies of the matrix, multivector, or vector. To support this, I
also modified CrsMatrix::sumIntoGlobalValues so that it does not
change Teuchos::RCP reference counts, thus making it thread safe.
The default value of 'atomic' depends on the class' execution space.
If the execution space is Kokkos::Serial (no threads), atomic is false
by default; else, it is true by default. This ensures that existing
MPI-only codes do not need to pay the (small integer factor) overhead
of atomic updates, while making sumInto always correct by default when
using thread parallelism.
If you know that different threads will never access the same entries
concurrently, you should set atomic=false for best performance.
- Block(Multi)Vector: Add "offset view" constructors (Bug 6450)
Tpetra::Experimental::{BlockMultiVector, BlockVector} now have two
"offset view" constructors. They behave analogously to the offsetView
and offsetViewNonConst methods of Tpetra::MultiVector.
The constructors view an existing BlockMultiVector with a different
mesh Map, and an optional local row offset from which to start the
view on each process. The offset is a mesh offset (it gets multiplied
by the block size internally in order to find the point offset). The
two constructors differ only in that one lets you supply the new point
Map, while the other computes it for you.
This fixes Bug 6450 (which was a feature request).
Zoltan
- Minor code cleanup and bug fixes.
- New Zoltan_Get_Fn interface returning pointers to callback functions.
See zoltan/src/include/zoltan.h for details.
- Closest stand-alone Zoltan release is v3.83.
http://www.cs.sandia.gov/Zoltan
Zoltan2
- New interface to graph partitioning third-party library PuLP (Partitioning
using Label Propagation). PuLP is currently single-node, multi-threaded
with OpenMP. Work for the next release will include extension to
MPI+OpenMP.
- Improved handling of TPL data types, especially in the Zoltan interface.
- Interface from MatrixAdapter to Zoltan hypergraph algorithms implemented.
- Consistent handling of Tpetra explicitly instantiated types; in particular,
enabled builds without GlobalOrdinal=int and without Epetra.
- PartitioningSolutionQuality class is being refactored and renamed
EvaluatePartition; work will continue to next release.
###############################################################################
# #
# 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