-
Notifications
You must be signed in to change notification settings - Fork 38
/
Copy pathNEWS
243 lines (195 loc) · 11.8 KB
/
NEWS
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
This file lists the most important updates in Agama (in reverse chronological order);
breaking changes in API are listed at the end.
June 2024:
Added a Hermite method for orbit integration;
implemented computation of projected potential, acceleration and its derivatives;
added checks for unknown or irrelevant density/potential/DF parameters.
May 2024:
Implemented analytic convolution of 1d interpolators and determination of their
roots and extrema.
April 2024:
Implemented computation of DF derivatives w.r.t. actions
March 2024:
Implemented computation of orbit derivatives w.r.t. initial conditions
(variational equation).
Developed a plugin (or, rather, patch) for N-body codes Arepo and Gadget4
that allows them to use an external potential provided by Agama in the simulation.
February 2024:
Improved flexibility of transformations between position/velocity and action/angle
spaces, allowing one to explicitly choose which quantities need to be computed;
redesigned ActionMapperTorus to create multiple tori on demand and cache them.
October 2023:
Redesigned the parallelization strategy in the Python interface, making it more robust
when involving (nested) calls to user-defined Python callback functions
March 2023:
Added an option for representing the result of orbit integration as an interpolator
(class agama.Orbit in Python).
June 2022:
Added a general framework for time-dependent density/potential modifiers
(shift, tilt, rotation, modulation in amplitude).
September 2021:
Enable compilation on Windows with MSVC (using the same setup.py script).
April 2021:
Generalized GalaxyModel methods to arbitrary orientations (with some changes in API),
switched to Cartesian coordinates and optimized computation costs (1.5-2x speedup).
Added an option for constructing DensitySphericalHarmonic or DensityAzimuthalHarmonic
interpolators for arbitrary input density profiles in the Python interface.
February 2021:
Allow user-defined potential functions in the Python interface;
add wrappers for potentials from Galpy and Gala to be used in Agama and vice versa.
November 2020:
Added a concept of SelectionFunction to the GalaxyModel class (C++ and Python).
September 2020:
Allow to integrate orbits backward in time.
July 2020:
Added an extra time argument for the density and potential interfaces, and modified the orbit
integration routine to use a time-dependent potential. Also modified storage format for
potential expansion coefficients.
April 2020:
Optimized computation of DF moments for the case of a composite DF, when output is requested for
each DF component separately.
March 2020:
Added Python routines for celestial coordinate transformations, which perform some of the tasks
provided by the astropy.coordinates framework (the routines in Agama are less general but faster).
January 2020:
The Monte Carlo code Raga is extended to multiple species and provided as part of AMUSE interface.
December 2019:
Observationally-driven Schwarzschild modelling framework is published under the name Forstand;
added examples and documentation.
May 2019:
Significant speedup in quadratic optimization (part of Schwarzschild modelling framework).
March 2019:
Added anisotropic spherical DFs constructed via the Cuddeford-Osipkov-Merritt inversion technique.
May 2018:
Added axisymmetric Jeans models.
Winter 2018:
General cleanup, script for automatic installation, publicly announced together with the code paper.
Autumn 2017:
Added and improved action-based DFs (QuasiSpherical, QuasiIsothermal, Exponential);
improved the multidimensional sampling routine.
Summer 2017:
Augmented the Schwarzschild module with the observational kinematic constraints in the form of LOSVDs.
May 2017:
The core functionality of SMILE - construction of Schwarzschild orbit-superposition models
for the given density and potential (without any observational constraints) - is ported into Agama.
The top-level workflow is implemented in Python, while the computationally heavy parts -- in C++.
April 2017:
Further development of the PhaseFlow code: multiple components, more accurate finite-element solver.
January 2017:
Ported the stellar-dynamical Monte Carlo code Raga (which, in turn, was based on SMILE) into
Agama framework.
November 2016:
Added a first version of the PhaseFlow Fokker-Planck code.
October 2016:
Added reference documentation.
Summer 2016:
Extended Python interface, added Fortran, NEMO and AMUSE interfaces.
November 2015:
Added the framework for iterative construction of self-consistent models specified by action-based DFs.
September 2015:
First public announcement at the Gaia Challenge workshop.
By this time, the Agama library already has a Python interface and a number of tests/example programs.
Summer 2015:
Various parts of SMILE are ported into Agama: potentials, orbit integration routines, splines.
June 2015:
The Agama C++ library is born by reimplementing several earlier routines for action computation
written by James Binney and Jason Sanders (now known as the TACT toolbox).
Pre-2015:
The predecessor of Agama was the SMILE code for orbit analysis and Schwarzschild modelling.
It contained many of the aspects that later were incorporated into Agama:
an extensive collection of potentials (including earlier implementations of Multipole and CylSpline),
orbit integration and analysis routines (frequency analysis, Lyapunov exponents, frequency maps),
construction of orbit-superposition models, a graphical interface based on Qt, Python and NEMO interfaces.
Some of this functionality is not yet ported to Agama.
-----------
API Changes
October 2024:
[C++] redesigned the treatment of symmetry in potential expansions: now it can be specified
in the constructors independently from the symmetry of the input density/potential model.
[Python] composite Density or Potential objects can be created by adding instances of these
classes (syntactic sugar; equivalent by calling their constructors with several arguments).
Removed the possibility of providing a tuple of objects to the density/potential constructor,
now need to unpack it into elements.
Creation of a composite Density or Potential from objects that are themselves composites
"flattens" the result (i.e. unpacks the sub-components and combines them into one top-level
composite object).
June 2024:
[C++,Python] replaced projectedForce by a more general routine/method projectedEval, which
computes any combination of projected potential, acceleration and its derivatives.
March 2024:
[C++] Extended the integration of variational equation, previously used for the estimation
of the Lyapunov exponent, to the case of all six deviation vectors, providing the derivatives
of the orbit w.r.t. initial conditions; replaced RuntimeLyapunov by RuntimeVariational.
[Python] added the option for computing derivatives in the orbit() routine.
February 2024:
[C++,Python]
Redesigned the ActionFinder interface, allowing one to request any combination of
action/angle/frequency, and skip computation of unneeded quantities.
The interface remains mostly backward-compatible, but actionAngles() has been removed.
[C++]
Created the factory for action finders/mappers, choosing the optimal implementation
depending on the potential (Isochrone / generic spherical / axisymmetric).
Redesigned ActionMapperTorus to maintain multiple instances of Torus objects, one for each
unique triplet of actions; these are created on demand and cached. It is still not thread-safe.
[Python]
ActionFinder and ActionMapper use the optimal implementation depending on the potential.
Changed the ActionMapper interface, now its constructor only needs the potential,
whereas the call method takes the combination of actions and angles for one or more points.
If the potential is an Isochrone or a generic spherical one, it will use more efficient
underlying implementations, enabling parallel computations. Otherwise (for an axisymmetric
potential) it still uses Torus, but creates and caches new instances of Torus on-the-fly
for each unique input triplet of actions, rather than fixing actions at the construction.
March 2023:
[C++] redesigned the workflow for on-the-fly symmetrization of density and potential models,
introducing new wrapper classes Sphericalized/Axisymmetrized<BaseDensity/BasePotential>,
which replace the earlier Density/PotentialWrapper. The latter assumed that the potential is
spherical or axisymmetric, while the new classes perform angular averaging on demand
(at the time of evaluation) in contexts such as computation of Lcirc(E), Rperi/apo(E,L),
construction of QuasiSpherical DFs, etc., which were previously restricted to spherical or
axisymmetric models and are now performed on sphericalized/axisymmetrized versions of input
density and potential models (of course, the results are only approximate in the case that the
input models lacked the required symmetry, but this is usually the physically sensible outcome).
This is a simpler and non-tunable alternative to the construction of proper expansion classes
such as Multipole; the latter take some time to create but are more efficient to evaluate.
[Python] user-defined density/potential functions now have *no* default symmetry, triggering
an error in any more-or-less complex operation such as computation of total mass or construction
of expansions - one needs to specify the symmetry explicitly. The rationale is that these
operations are significantly more efficient in typical cases of triaxial or axisymmetric models,
but may not assume any symmetry (other than None) by default, otherwise the result would be
incorrect; therefore, users should provide this information explicitly.
[C++,Python] added the argument "fixOrder" for density and potential expansions constructed from
other input profiles (i.e., not from N-body snapshots).
June 2022:
[C++] redesigned the potential_factory routines to deal with general modifiers,
with some changes in the types of input density/potential objects passed to
createDensity/Potential routines (smart pointers instead of references)
May 2021:
[C++] interface for orbit integration is redesigned to decouple the internal representation
from the input/output, which is now always served in Cartesian coordinates
April 2021:
[C++, Python] interface for computing DF moments has been reorganized to deal with arbitrary
orientations and unified the treatment of projection along the line of sight.
Now the moments (intrinsic or projected) are computed in Cartesian coordinates;
projectedMoments has been removed (incorporated into moments);
vdf (velocity distribution, intrinsic or projected) also switched to Cartesian coordinates;
projectedDF extensively redesigned and its functionality extended to work with different
combinations of measurement uncertainties in each of the three velocity components.
Renamed surfaceDensity to projectedDensity for consistency with projectedForce and projectedDF.
July 2020:
[C++] modified the format for storing potential expansion coefficients to unify it with
the INI files containing all other potential parameters. Hence the routines
createPotential("filename.ini") and readPotential("file.coefs") have both been superseded
with readPotential("filename.ini"). No changes in the Python interface.
April 2020:
[C++, Python] interface for computing DF moments has been modified to provide an option
for treating all components of a composite DF separately.
January 2020:
[C++] interface for dealing with spherical isotropic models and relaxation coefficients
changed to accommodate the possibility of working with a spectrum of stellar masses.
[C++] orbit integration, in particular integrateTraj(), can optionally store the orbit
at every timestep, not just at regular intervals of time as before. Accordingly,
the type of returned array changed to also contain timestamps for each point.
[C++] interface for N-body snapshot input/output has been cleaned up.
March 2019:
[C++, Python] QuasiIsotropic DF renamed to QuasiSpherical, because it can now represent
anisotropic spherical systems.