Health Articles

Sait.oat.ts.astro.it

Mem. S.A.It. Suppl. Vol. 8, 64 Two platform independent versions of ATLAS12 Institut f¨ur Astronomie, Universit¨at Wien, T¨urkenschanzstraße 17, 1180 Vienna, Austriae-mail: [email protected] Abstract. ATLAS12 makes use of some non-standard features of the VAX/VMS compiler,
which is highly appreciable if one uses a VMS workstation, but causes problems of portabil-
ity that make it difficult to compile ATLAS12 on various non-VMS operating systems. This
article describes the modifications to ATLAS12 that became necessary in order to get this
code running with the open source GNU compiler (g77), which is easily available on most
Linux/Unix based systems (including Mac OS X). We also present our parallel and modu-
larised Ada95 version of ATLAS12 and give an overview of CAMAS, our new magnetic
stellar atmosphere code.
Key words. Methods: numerical – Stars: atmospheres – Stars: magnetic fields
it is an opacity sampling code, which is in-dispensable in order to allow for peculiar This contribution describes the modifications abundances in individual stars. Furthermore that were necessary in order to convert ATLAS12 is the de facto standard stellar atmo- ATLAS12 into a essentially platform indepen- sphere program and contains well tested opac- dent code. We will not discuss the usage of ity routines. On account of this ATLAS12 is ATLAS12 and the underlying physics, since considered a good starting point and compari- they are well described in the publications of son for our opacities and models.
In order to adapt the ATLAS12 code to ber of articles in this volume. Here we focus fit our needs some known problems had to be on our changes to the original version of the overcome: (a) The equation of state incorpo- ATLAS12 code. Finally salient features of our rated in ATLAS does not allow for depth de- ATLAS related magnetic stellar atmosphere pendent abundances. (b) The depth and fre- code CAMAS are shortly discussed.
quency resolutions are limited by the fixed ar-ray lengths and the pretabulated matrix used by 1.1. ATLAS12: advantages & the radiation transport subroutine (JOSH). (c) ATLAS12 reads the line data from binary files.
The data files distributed with ATLAS are big ATLAS12 was chosen as a non-magnetic com- files, which can cause problems, since parison to our new magnetic atmosphere code most of the PCs using Intel or AMD proces- CAMAS for several reasons: most importantly, 1 The endianness describes where the most signif- icant bit is located. Big end first is called big endian, Send offprint requests to: K. M. Bischof e.g. the values of the 4-byte big endian integers in K. M. Bischof: ATLAS12, platform independent sors are little endian, and the big endian switch – floating point and variable precision in the file I/O command is not working in the [0. → 0.d0] current version of the g77 compiler. (File I/O If this precision is not explicitly defined, will be discussed in detail in the next section).
the g77 compiler may use any precision Evidently, in the absence of a VMS and the code may yield different results FORTRAN compiler, the platform dependence from the VAX/VMS FORTRAN version.
was the problem that had to be solved first. In a Thus the precision of all floating point lit- further step, ATLAS12 was successfully ported erals has been defined.
to Ada95, an object oriented parallel language.
– declaration and initialisation of all variables[replace "IMPLICIT REAL*8" statement] 2. FORTRAN77 version
The "IMPLICIT REAL*8" statementcauses a compilation problem. It was It is becoming more and more common to therefore removed. We also decided to replace old VMS workstations with systems explicitly initialise the variables that need running under Linux or Mac OS. Faced with to be set to zero, because the defaults for the same portability problems as e.g. the "-finit-local-zero" switch of the g77 we chose to abandon VAX/VMS- compiler may be different on different ma- specific FORTRAN commands and to estab- chines. The declaration and initialisation of lish a FORTRAN77 version that can be com- all variables also made the modularisation piled using the free GNU FORTRAN com- of the code and consequently the porting piler (g77), since this is the most easily avail- to Ada95 feasible.
able compiler for Linux/Unix based systems – "dummy arrays" and data types (including Mac OS X). Therefore we consider [var(1) → var(*), Real*8 → Double this version useful for astronomers having no Precision, . .] access to (proprietary) VAX/VMS compatible The VAX/VMS FORTRAN syntax for FORTRAN compilers.
the declaration of "dummy arrays" causes Our platform independent g77 version of compiler errors or warnings and was there- ATLAS12 can be downloaded from our home- fore replaced. The data types Real*4 and Real*8 are deprecated - consequently both data types were replaced with "DoublePrecision" for variables that do not appearin common-blocks.
2.1. Distinctions between VAX/VMS- – addressing two-dimensional arrays [NNN(1) → NNN(1,1) ] Due to the absence of the additional functional- A two-dimensional array cannot be ad- ity provided by the VAX/VMS compiler these dressed like a one-dimensional array in non-standard features have to be emulated by standard FORTRAN77. In contrast to g77 adding the corresponding commands directly FORTRAN, where one needs two indices into the code. Most changes concern the defi- to address a two-dimensional array, it is nition and the handling of the variables. Some possible in VAX/VMS FORTRAN to ad- additional portability problems were caused by dress such arrays using only one index.
the use of functions provided by the underlying Since ATLAS12 makes use of this short- operating system (e.g.,"ABORT").
hand, these array-references had to bechanged.
The most important modifications that – values of variables in subroutines were necessary in order to port the code to g77 ["SAVE var"] There are two ways of memory allocation:static allocation, which is the VAX/VMS the ATLAS12 data files are computed by "1st byte *224 + 2nd byte * 216 + 3rd byte * 28 + 4th byte" default and allows subprograms to retain K. M. Bischof: ATLAS12, platform independent Fig. 1. The results of 25 iterations on a 10 000 K main sequence model with solar abundances. This plotshows the small differences in the flux error (upper panel) and in the flux derivatives (lower panel) betweenthe model computed with the VMS compiler and with the Linux g77 compiler after 25 iterations. Thedashed lines indicate the respective convergence limits. It can be seen that the differences do not precludeconvergence; being very small they can be interpreted as due to different floating point representations onthe two machines.
variable values, and stack allocation, which endianness is not recognised by the g77 is the g77 default and does not retain val- compiler, and so these files are now read ues of variables defined in subprograms un- byte by byte on little endian machines, after less they are declared using the "SAVE" which a byte-reordering routine is applied.
command. Since ATLAS12 was originally Tests of the read routines showed that out written for a VMS workstation it assumes of approx. 9 million selected lines from that subroutines are able to retain the val- highlines.dat and lowlines.dat only 3 lines ues of all their "private" variables until the were selected differently by the Linux next call. When translating the code to the and VAX/VMS codes when computing a g77 FORTRAN version we checked which 10 000 K main sequence star model. This variables are reused after the function-call negligible discrepancy most probably re- and retained only the values of these vari- sults from the different floating point rep- ables because saving all variables was con- resentations of the machines.
sidered a waste of memory.
– replace system dependent calls – different I/O-format and file-format [ABORT → EXIT(0)] [reorder bytes after reading] Some statements in ATLAS12, mainly the The binary files distributed by R. L. Kurucz routines that help the user to compute the contain big endian encoded integers. The runtime, and the exit statements, contain read option that allows the selection of the K. M. Bischof: ATLAS12, platform independent Fig. 2. The results of 25 iterations on a 10 000 K main sequence model with peculiar abundances (C, N,O: −1 dex; Cr, Fe, Ni: +1 dex). This plot shows that the differences in the flux error (upper panel) and inthe flux derivatives (lower panel) also remain small if the abundances are changed in the ATLAS9 startingmodel. (In Fig. no changes to the starting model were made.) VAX/VMS system calls. These had to be workstation and the g77 FORTRAN code run- replaced by their Unix/Linux equivalents.
ning on a Debian Linux PC.
– GOTO cannot jump into if-block with The resulting models computed on these different platforms were compared. In Fig. In the subroutine PFGROUND it may oc- and Fig. the results after 25 iterations on a cur that a GOTO statement leads into converged ATLAS9 10 000 K main sequence an if-block with unmet condition. The model with (a) solar abundances and (b) pe- VAX/VMS compiler allows this action culiar abundances (C, N, O: −1 dex; Cr, Fe, whereas the g77 compiler refuses to Ni: +1 dex) are shown. There are no visible compile this construct. Therefore minor differences between any of the output models.
changes to the program structure proved The only variables where small differences can be seen are the flux error and the flux deriva-tive. These differences are of the order of a fewparts per thousand, which is about the order of magnitude one would expect from different (VAX/VMS compared to g77) floating-point representations and different nu-merical precision. Since the convergence cri- In order to test whether the porting was suc- teria (marked with dashed lines in the figures) cessful a comparison was made between the are one part per thousand in flux error and 0.1 VAX/VMS code running on a DEC VMS in flux derivative, it is obvious that these differ- K. M. Bischof: ATLAS12, platform independent same time it becomes fairly easy to test the ef-fects that occur if one replaces the subroutinesused in ATLAS12 with the ones used in ourcodes. In the present case an example for thesereplaceable parts is the solver for the radia-tion transport (JOSH) which was replaced by aFeautrier solver. An example for the insertionof packages is the Ng acceleration.
3.1. Feautrier solver If one intends to calculate models with dif-ferent numbers of depth points, it can beconsidered a serious drawback of the JOSH Fig. 3. Structure of our version of ATLAS12. The routine that the grid resolution cannot be location of the newly included / replaced packages specified at runtime. This radiation transport with standard interfaces mentioned in is in- solver interpolates the values from the opti- dicated. JOSH and Feautrier are radiation transport cal depth scale of the model onto a fixed set routines, Ng is an iteration acceleration routine.
of depth points where the integration matri-ces used in this method (see )are pretabulated. Therefore we replaced this ences may safely be ignored. Fig. as well as routine with the non-magnetic Feautrier solver Fig. display these negligible differences.
). This solver allows for achange of the grid-resolution without recompi- 3. Parallel Ada95 version
lation, whereas the JOSH routine would neednew hard-coded integration matrices.
For reasons explained in detail in Due to the different numerical errors and different grid resolutions these solvers yield ing line synthesis code COSSAM slightly discrepant results.
and radiative diffusion codeCARAT are written inAda95. In order to include the Kurucz opacity 3.2. Ng acceleration routines into our codes, the whole of ATLAS12 The implementation of the iteration scheme was ported to this programming language.
proposed ) accelerates the conver- Ada95 is an object oriented language gence of our models by 10 to 50 %.
which encourages modularisation and facili- This scheme uses the results of four (or tates the parallelisation of the code. As all more) iterations of a function f (. ., f modern computing languages, Ada95 allows one to determine the needed array-sizes at run- n−1, fn) to construct a new function ¯ closer to the converged function (see ).
time and is therefore able to minimise the The iteration process can be written as: memory requirements and to handle any num-ber of frequencies (up to the limits imposed by A fn−1 = fn the hardware used).
The modularisation of our Ada95 version where f (x) represents a real function and A a of ATLAS12 is a big advantage since establish- (non)linear operator. If A can be assumed to be ing interfaces for all subroutines ("encapsu- linear (or at least a linear approximation to A lation") simplifies the exchange and insertion exists) it is possible to calculate the optimum of subroutines into existing codes. This new values of the weighting constants c1, c2, . .
program architecture provides reusable pack- The application of the operator A to the func- ages (e.g. the continuum package) and at the tions on the right hand side of can be K. M. Bischof: ATLAS12, platform independent CAMAS with(out) Ng = ∆0 + c1(∆1 − ∆0) + c2(∆2 − ∆0)+ . .
0 := fn − fn−1. The best weights c1, c2, . .
can be found by using the condition that the effect of the operator A on the new function ¯f has to be minimised. This can be written as kA ¯f − ¯fk2 → min.
Eq. yields the following system of equa- tions if the derivatives with respect to the weights c1, c2, . . are calculated: Fig. 4. Application of the Ng-acceleration. The be- ∆0(∆1 − ∆0)dx = c1 (∆1 − ∆0)(∆1 − ∆0)dx haviour of the flux errors during the iteration pro- cess is shown for a model with Ng-acceleration and a model, were this acceleration was not used. The 1 − ∆0)(∆2 − ∆0)dx sudden declines of the errors are produced by the application of the Ng-acceleration.
∆0(∆2 − ∆0)dx = c1 (∆1 − ∆0)(∆2 − ∆0)dx + c2 (∆2 − ∆0)(∆2 − ∆0)dx The integrals arise from the definition of the in- ner product. This system is solved in the stan- Fig. 5. The Ng acceleration scheme. This scheme dard way (since all differences ∆i are known).
uses the results of four (or more) iterations (. ., f Using the calculated weights c 1, c2, . . the new input function for the next iteration step is cal- n−2, fn−1, fn) to construct a new function ¯ closer to the converged function. A is a linear op- erator that represents or at least approximates theiteration. The differences between two consecutive fn+1 = (1 − c1 − c2 − . .) fn iteration results fn−1 and fn are denoted by ∆0.
+ c1 fn−1 + c2 fn−2 + . .
Test calculations show that the application of computed using Eq. This leads to Eq. the Ng scheme can save up to 50% of the com- putation time. In Fig. one can easily see that f = (1 − c1 − c2 − . .) fn−1 after the usage of the Ng routine there is a dra- + c1 fn−2 + c2 fn−3 + . .
matic decline in the flux errors. If the devia- A ¯f = (1 − c tions of the computed function from the con- 1 − c2 − . .) fn verged function are small, the influence of the 1 fn−1 + c2 fn−2 + . .
nonlinearity of A gets stronger and the applica- The converged function satisfies A f = f .
tion of the Ng routine is no longer able to speed The difference between the not fully converged up the process.
function ¯f and the expected result after ap-plication of the linear operator A ¯f can be ex- 3.3. Parallelisation Porting the code to Ada95 has another ad- A ¯f − ¯f = (1 − c1 − c2 − . .)∆0 + c1∆1 + c2∆2 vantage: with a modularised Ada95 code it is easy to create a thread-parallel version. Since K. M. Bischof: ATLAS12, platform independent opacity calculations over the available CPUsand the addition of the subtotals from the dif-ferent CPUs (indicated by the small box be-low the boxes labelled "CPU1" and "CPU2"in Fig. In a further step the line-selection has also been parallelised. Obviously this results in a Fig. 6. The effect of the parallelisation on the run- runtime distribution very similar to the runtime time distribution. The diagram on the left shows that distribution in the sequential case. The saving a sequential version of ATLAS12 spends most of of total computation time behaves analogously the CPU time on opacity sampling in the frequency to the decrease of integration time described in loop. Parallelisation of this loop saves a consider- the last paragraph.
able amount of wall clock time. Due to the smallsynchronisation overhead the decrease of the run-time depends linearly on the number of processors.
3.4. Examples (VAX/VMS compared to The diagram on the right shows that using a second CPU saves half the wall clock time spent on opacitysampling.
For comparison 25 iterations were carried outon an ATLAS9 10 000 K main sequence modelwith (a) solar abundances and (b) peculiarabundances (C, N, O: −1 dex; Cr, Fe, Ni:+1 dex). In Fig. well as in Fig. can beseen that the differences to the original versionbecome larger, which is most probably due tothe different available data types, but are stillunimportant. The higher numeric precision ofthe data types declared in the Ada95 versionsuggests that the results of the Ada95 code areless subject to rounding errors.
Fig. 7. Program structure of the parallelised version 4. CAMAS - a "magnetic" atmosphere
of ATLAS12. The opacity calculations (and opac- ity integrations) are distributed over the availableCPUs. The summation of the subtotals from the dif- Working on magnetic CP stars one has to com- ferent CPUs is indicated by the small box under the pute the influence of the magnetic field on boxes labelled "CPU1" and "CPU2".
the structure of the atmospheres. Therefore wehave established a new magnetic stellar atmo-sphere code called CAMAS (Codice per le ATLAS12 spends most of the computation Atmosfere Magnetiche Stellari).
time on opacity sampling (see Fig. this part This can be regarded as an ATLAS re- of the program was parallelised. As the calcu- lated code, since it presently makes use of lations of the opacities at different wavelengths the ATLAS12 continuous opacities. The line do not depend on each other, there is very little lists for CAMAS were extracted from VALD synchronisation overhead and the computation (and the line opacity rou- time needed for the integration of the opacities tines were taken from the COSSAM code. The over all frequencies decreases linearly with the chemical equilibrium calculations in CAMAS increase of the number of processors used by are different from ATLAS. CAMAS uses an the program. Figure 7 shows the structure of equation of state with hydrogen chemistry our version ATLAS12 version in Ada95. The (Mihalas 1967). For the temperature correction difference between the parallel version and the procedure a variant of the Lucy Uns¨old method sequential version lies in the distribution of the (Dreizler 2003) is employed.
K. M. Bischof: ATLAS12, platform independent Fig. 8. Comparison of the Ada95 model to the FORTRAN models: results of 25 iterations on a 10 000 Kmain sequence model with solar abundances. (Analogous to Fig. The differences between the Ada95model and the VMS model are larger than the differences between the FORTRAN models. This is probablydue to different data types of higher numeric precision declared in Ada95 and the different mathematicallibraries.
So far the influence of the magnetic field kinds of Linux/Unix based systems (includ- on the atmospheric structure is not fully ing Mac OS X). The Ada95 version also offers taken into account. Magnetic line blanket- some additional functionality. It is platform in- ing is included but Lorentz forces are ne- dependent, split up in modules and runs in par- glected. The Zeeman Feautrier solver for the allel on multi-processor machines. Any limita- polarised radiation transfer equation has been tions as to the maximum number of depth and taken from the CARAT code frequency grid-points and the number of lines the line opacity calcula- that can be treated have been pushed far be- tions are based on Component by Component yond what is possible with the original version.
Sampling. CAMAS is producing converged The incorporation of the continuous opacity models but it still has to be improved by adding routines of ATLAS12 in our new CAMAS some missing physics (e.g. magnetic pressure) code for magnetic atmospheres makes it pos- and to be tested thoroughly.
sible to compare our future models with thoseof R. L. Kurucz.
Our g77 FORTRAN code produces the M. J. Stift and R. L. Kurucz are gratefully acknowl- same models as the original VAX/VMS edged. The VAX/VMS models were computed with FORTRAN code. Therefore it can safely be the help of E. A. Dorfi and his working group. This used for calculating ATLAS12 models on all work has been supported by the Austrian Science K. M. Bischof: ATLAS12, platform independent Fig. 9. Comparison of the Ada95 model to the FORTRAN models: results of 25 iterations on a 10 000 Kmain sequence model with peculiar abundances (C, N, O: −1 dex; Cr, Fe, Ni: +1 dex). One can see that thedifferences between the results of the codes do not get larger than one would expect due to the different datatypes and mathematical libraries.
Fund (FWF), project P16003 "Radiative diffusion Kupka, F. G., Ryabchikova, T. A., Piskunov, in magnetic stellar atmospheres".
N. E., Stempels, H. C., & Weiss, W. W.
2000, Baltic Astronomy, 9, 590 These programs can be downloaded from: Kurucz, R. L. 1970, SAO Special Report, 309, Mihalas, D. 1967, Methods in Computational Ng, K.-C. 1974, J. Chem. Phys., 61, 2680Sbordone, L., MSAIS, 8, 61 Alecian, G., & Stift, M. J. 2002, A&A, 387, Stift, M. J. 1998, Contributions of the Astronomical Observatory Skalnate Pleso, Alecian, G., & Stift, M. J. 2004, A&A, 416, Stift, M. J., & Dubois, P. F. 1998, Computers in Physics, 12, 150 Stift, M. J. 2000, A peculiar Newsletter, 33 Dreizler, S. 2003, ASP Conf. Ser. 288: Stellar Atmosphere Modeling, 288, 69 Wade, G. A., Bagnulo, S., Kochukhov, O., Feautrier, P. 1964, SAO Special Report, 167, Landstreet, J. D., Piskunov, N., & Stift, M. J.
2001, A&A, 374, 265

Source: http://sait.oat.ts.astro.it/MSAIS/8/PDF/64.pdf