User Tools

Site Tools


2013:groups:tools:dlha

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
2013:groups:tools:dlha [2013/06/19 16:57]
balazs.csaba
2013:groups:tools:dlha [2013/06/20 17:24] (current)
balazs.csaba
Line 5: Line 5:
  
 ==== People involved ==== ==== People involved ====
-(Present at Les HouchesAlexandre, Andreas, Ben, Benj, Björn, Csaba, Fawzi, Geneviève, Nazila, Sasha, Sezen, Pietro, ​...+  * Present at Les HouchesAlexandre, Andreas, Ben, Benj, Björn, Csaba, Fawzi, Geneviève, Nazila, Sasha, Sezen, Pietro 
 +  * Outside of Les Houches: Ben Allanach, David Cerdeno, Peter Skands& 50+ other people representing various dark matter calculators.
  
 ==== Useful links ==== ==== Useful links ====
Line 15: Line 16:
   * Elevate the DLH agreement to a DLH Accord,   * Elevate the DLH agreement to a DLH Accord,
   * Start implementing DLHA in dark matter calculators.   * Start implementing DLHA in dark matter calculators.
 +    * Testing DLHA between at least two codes is essential before the final report is completed.
  
 ==== 1st discussion ==== ==== 1st discussion ====
Line 37: Line 39:
     * The table header should look like this:      * The table header should look like this: 
       * TABLE <​name>​ <​column>​ <row>       * TABLE <​name>​ <​column>​ <row>
-    * The name will probably be inherited from the function+    * The name will probably be inherited from the function.
     * In some cases, when the table can be given in different parametrizations/​coordinates,​ the name will have to include info about about this.     * In some cases, when the table can be given in different parametrizations/​coordinates,​ the name will have to include info about about this.
     * We should consider the I/O of "​external"​ tables, namely table I/O from/to a separate (non-DLHA) file.     * We should consider the I/O of "​external"​ tables, namely table I/O from/to a separate (non-DLHA) file.
Line 47: Line 49:
   * There'​s a problem with trying to agree upon the I/O of existing functions in existing codes, because this would restrict coding. ​ This problem arises when directly accessing existing methods within existing codes, such as:   * There'​s a problem with trying to agree upon the I/O of existing functions in existing codes, because this would restrict coding. ​ This problem arises when directly accessing existing methods within existing codes, such as:
     * ''​FUNCTION <​name>​ type=<​type>​ args=<# of args> | libName=<​name of compiled library> | funcName=<​name of function in library> | END_FUNCTION''​     * ''​FUNCTION <​name>​ type=<​type>​ args=<# of args> | libName=<​name of compiled library> | funcName=<​name of function in library> | END_FUNCTION''​
-    * Agreement about the I/O of these directly accessed functions could severely ​tie the hands of the author(s) of the original code, and it is not feasible.+    * Agreement about the I/O of these directly accessed functions could tie the hands of the author(s) of the original code
 + 
 +==== 4th discussion ==== 
 +  * A DLHA reader/​writer prototype can be created based on SLHA+. 
 +  * FUNCTION I/O should happen via arrays. 
 +  * We should consider agreeing about the I/O of existing methods in existing calculators. ​ (For abundancedirect or indirect detection calculations,​ for example.) ​ Then the authors of the codes could distribute a pre-compiled Linux library from which these methods could be called directly based on DLHA. 
 +  * We should specify the number of significant figures (16 was suggested) for numerical values.
  
 ==== Things to do ==== ==== Things to do ====
   * The write-up has to be updated to reflect the changes we decide to make at LH13.   * The write-up has to be updated to reflect the changes we decide to make at LH13.
   * ...   * ...
2013/groups/tools/dlha.1371653864.txt.gz · Last modified: 2013/06/19 16:57 by balazs.csaba