differences 4.6 KB
Newer Older
Martin Reinecke's avatar
Martin Reinecke committed
1
2
Significant differences between NIFTy3 and nifty4
=================================================
3

Martin Reinecke's avatar
Martin Reinecke committed
4
1) Field domains in nifty4 are stored in DomainTuple objects, which makes
5
6
7
8
9
   comparisons between domains and computation of axis indices etc. much simpler
   and more efficient.
   No impact on the user ... these objects are generated whenever needed and
   have all necessary functions to make them look like tuples of spaces.

Martin Reinecke's avatar
Martin Reinecke committed
10
2) In nifty4 an operator's domain and target refer to the _full_ domains of
11
12
13
14
15
   the input and output fields read/written by times(), adjoint_times() etc.
   In NIFTy nightly, domain and target only refer to the (sub-)domain on
   which the operator actually acts. This leads to complications like the need
   for the "default_spaces" argument in the operator constructor and the
   "spaces" keywords in all operator calls.
Martin Reinecke's avatar
Martin Reinecke committed
16
   Advantages of the nifty4 approach:
17
18
19
20
21
22
23
24
25
26
27
    - less error-prone and easier to understand; less code overall
    - operators have more knowledge and may tune themselves better
    - difficulties with the design of ComposedOperator (issue 152) resolve
      themselves automatically
   Disadvantages:
    - operators cannot be used as flexibly as before; in a few circumstances
      it will be necessary to create more operator objects than with the current
      approach.
      However, I have not found any such situation in the current code base, so
      it appears to be rare.

Martin Reinecke's avatar
Martin Reinecke committed
28
3) nifty4 uses one of two different "data_object" modules for array
Martin Reinecke's avatar
Martin Reinecke committed
29
30
31
32
33
   storage instead of D2O.
   A "data_object" module consists of a class called "data_object" which
   provides a subset of the numpy.ndarray interface, plus a few additional
   functions for manipulating these data objects.
   If no MPI support is found on the system, or if a computation is run on a
Martin Reinecke's avatar
Martin Reinecke committed
34
   single task, nifty4 automatically loads a minimalistic "data_object"
Martin Reinecke's avatar
Martin Reinecke committed
35
36
37
38
39
   module where the data_object class is simply identical to numpy.ndarray.
   The support functions are mostly trivial as well.
   If MPI is required, another module is loaded, which supports parallel
   array operations; this module is in a working state, but not polished and
   tuned yet.
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

4) Spaces no longer have a weight() method; it has been replaced by
   scalar_dvol() and dvol() methods, which return the scalar volume element,
   if available, or a numpy array with all volume elements for the respective
   space.
   By using scalar_dvol() whenever possible, one can save quite some
   time when computing Field.weight().

5) renamings:
   get_distance_array -> get_k_length_array
   get_unique_distances -> get_unique_k_lengths
   (to be specific which "distances" are meant and to make more clear why this
   only exists for harmonic spaces)
   kindex -> k_lengths
   (because this is not an index)

Martin Reinecke's avatar
Martin Reinecke committed
56
6) In nifty4, PowerSpace is not a harmonic space.
57

Martin Reinecke's avatar
Martin Reinecke committed
58
7) In nifty4, parallel probing should work (needs systematic testing)
59

Martin Reinecke's avatar
Martin Reinecke committed
60
9) Many default arguments have been removed in nifty4, wherever there is no
61
62
63
64
65
66
   sensible default (in my opinion). My personal impression is that this has
   actually made the demos more readable, but I'm sure not everyone will agree
   :)

10) Plotting has been replaced by something very minimalistic but usable.
   Currently supported output formats are PDF and PNG.
Martin Reinecke's avatar
update    
Martin Reinecke committed
67
68
69
70

11) Co-domains are now obtained directly from the corresponding Space
   objects via the method "get_default_codomain()". This is implemented for
   RGSpace, LMSpace, HPSpace and GLSpace.
Martin Reinecke's avatar
Martin Reinecke committed
71
72
73
74

12) Instead of inheriting from "InvertibleOperatorMixin", support for numerical
   inversion is now added via the "InversionEnabler" class, which takes the
   original operator as a constructor argument.
Martin Reinecke's avatar
Martin Reinecke committed
75
76
77
78
79
80
81
82

13) External dependencies are only loaded when they are really needed: e.g.
   pyHealpix is only imported within the spherical harmonic transform functions,
   and pyfftw is only loaded within the RG transforms.
   So there are no mandatory dependencies besides numpy (well, pyfftw is
   more or less always needed).

14) A new approach is used for FFTs along axes that are distributed among
Martin Reinecke's avatar
Martin Reinecke committed
83
   MPI tasks. As a consequence, nifty4 works well with the standard version
Martin Reinecke's avatar
Martin Reinecke committed
84
   of pyfftw and does not need the MPI-enabled fork.
Martin Reinecke's avatar
tweaks    
Martin Reinecke committed
85
86
87

15) Arithmetic functions working on Fields have been moved from
   basic_arithmetics.py to field.py.
Martin Reinecke's avatar
Martin Reinecke committed
88
89
90
91
92
93
94
95

16) Operators can be comined via "*", "+" and "-", resulting in new combined
   operators.

17) Every operator has the properties ".adjoint" and ".inverse", which return
   its adjoint and inverse, respectively.

18) Handling of volume factors has been changed completely.
96
97
98
99
100
101
102
103


Obsolescent functionality:

- DirectSmoothingOperator
- LaplaceOperator(?)
- FFTSmoothingOperator(?)
- most of the probing machinery(?)