AmberDrsReleaseNotesInPrep < Jmmc/Software

---+ This topic aims to collect each changes commited in the beta version in provision of the future [[AmberDrsReleaseNotes][release]]. It mainly concerns the "core" of =amdlib=, i.e., the C code library and all the =amdlibXXX= shell commands and their numerous options. Note that while the namesake =amdlib= Yorick interface, which presents simpler options and add visualization tools, should be preferred over the shell commands for the general user, reading these notes can be enlightening.

If you are interested by the beta release, please contact the [[http://www.jmmc.fr/support][jmmc user support]] to get access to the download page.

 

---+ <span class="red">V3.0.4</span>
This release mainly concerns the "core" of =amdlib=, i.e., the C code library and all the =amdlibXXX= shell commands and their numerous options. Note that while the namesake =amdlib= Yorick interface, which presents simpler options and add visualization tools, should be preferred over the shell commands for the general user, reading these notes can be enlightening.

   1 added option ="-w <delta_lambda>"= to =amdlibComputeP2vm=. This option permits to pass a new value for the spectral resolution, in *nanometers*. This should be used in conjunction with the =-S= option to correct the wavelengths of AMBER. Based on repeated measurements, AMBER not only suffers from a *bad repositioning of the grating turret* but also of a *false spectral dispersion formula*. The former produces the global shift of the spectrum, which is not corrected at time of observation but can be measured afterwards on known atmospheric absorption lines for example. This global shift is cured by the =-S= option where one can shift the wavelengths accordingly. In addition, the "-w" option permits to give a better spectral dispersion value for the 2 gratings. I have found that in Medium Resolution from H to K band, a constant value per pixel of *0.6858 nm* gives perfect results. *For all Low Resolution observations, do not panic, the shift is done automatically and a correct wavelength table is applied*.
   1 All the history of commands is now stored in the !HISTORY keywords of the !P2VM and !OI-FITS files.
   1 Added a new command, =amdlibP2vm2Oidata=. This command uses the !P2VM calibration files as if they were normal observation files and produces an !OI-FITS. This give insights on the signature of the !P2VM in all the other observations. There is no closure data since the !P2VM does not calibrate the closure.
   1 Slightly changed the noise formula estimate for closures.
   1 Documented all the options of =amdlibComputeOiData=.
   1 Added Keyword =NULLVALS= in OI-FITS headers (gives the blanking value used by amdlib at the time of data reduction). 
   1 Photometry is now also computed on the Interferometric Channel and gives another two columns ="INTERF_SPECTRUM"= and ="INTERF_SPECTRUM_ERROR"= in the =AMBER_DATA= table of our OI-FITS. (This Photometry is the one that should be used when checking the spectral calibration.)

<br>Here comes a new amdlib version aimed at speedup!:
   1 the reduced Chi2 of the fringe fit is kept and stored in the raw visibilities OI-FITS files (table =AMBER_DATA=, column =FRINGE_CHI2=). To be complete, we should add in a next release the possibility to select visibilities according to this chi2 in =amdlibPerform[Frame]Selection=.
   1 contrary to a well enforced useage, tagged values are no more blanked when it is possible. I should have set up a switch to permit this, but it would have been too complicated.  So only the flags will really tell if a value is deemed wrong or not, which is what the OI-FITS norm expects, in fact.
   1 The =amdlibComputeOiData= program has now a fast (switch =-Z0=) and a fussy (switch =-Z2=) mode. The "fussy" mode is the same as before: inversion of the full covariance matrix previous to complex coherent flux extraction, iteration on piston fit until high precision is reached. The fast mode considers that the covariance matrix is diagonal and the piston is evaluated with less precision. For most cases (especially when the S/N is not bad), the fast mode is enough. And it is fast, especially since the matrix routines have been optimized also. The =-Z1= switch is reserved for an intermediate, "clever" mode based on S/N, that I have not developed yet.
   1 The full =O3= optimization with inlining etc is set by default in the =Makefile=. Moreover, the really slow parts of code have been parallelized with =OpenMp pragma=. The speed of =amdlibComputeOiData= (which is the only program really time-consuming in amdlib) scales now roughly with the number of cores, and is now limited by the =cfitsio= reading and writing of files. With =gcc= and modern computers this should be transparent, but one has to test it on several platforms.
   1 All these changes have been reported in the =Yorick= interface. To set the speed switch to fast, use =amdlibSetPreference,"fastMode",0=.
<br> Package changes:
   1 rlterm is not delivered anylonger with the amdlib packages. Please install rlwrap or rlterm on your system by yourself following the instructions present in the [[http://www.jmmc.fr/doc/index.php?search=JMMC-MAN-2720-0002][installation guide]]

<br> Additionnally, this version closes two "tickets" we had:
   1 Ticket 93: the VISDATA AND VISERR columns in OI_VIS (which are not OI-FITS compliant but ESO compliant) now store the Complex Coherent Fluxes & error (not the complex visibilities). One may use these values (on the RAW OI-FITS obviously) to add, combine and average the coherent fluxes as he/she likes.
   1 Ticket 92: In case of selection averaging (=amdlibPerformFrameSelection=), the phase closure is retained as soon as two baselines are OK (in older versions (amdlib2 and amdlib3.0.1, etc) the phase closure would be deemed valid if the 3 baselines were retained by the selection criterium, giving really too few values for something which is essentially robust).


  Note: There was a naming convention problem concerning beta packages V3.1b1 to V3.1b4 . Some have been distributed (between jully 2010 and March 2011) and correspond to some previous versions of the V3.0.2. Impacted Users have been warned and wrong numbered tags have been removed from the source code repository. Apologize for inconvenience -- Guillaume
This topic: Jmmc/Software > JmmcAmberDrs > AmberDrsReleaseNotes > AmberDrsReleaseNotesInPrep
Topic revision: r36 - 2012-06-15 - GuillaumeMella