This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
2013:groups:tools:dlha [2013/06/18 16:17] balazs.csaba |
2013:groups:tools:dlha [2013/06/20 15:36] balazs.csaba |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== DLHA ====== | ====== DLHA ====== | ||
===== Dark matter Les Houches Accord ===== | ===== Dark matter Les Houches Accord ===== | ||
+ | |||
+ | DLHA is a set of conventions the authors of dark matter calculators agreed upon. These conventions regard the input/output of various information to/from these calculators. | ||
==== People involved ==== | ==== People involved ==== | ||
- | Alexandre, Andreas, Ben, Benj, Björn, Csaba, Fawzi, Geneviève, Nazila, Sasha, Sezen, Pietro, ... | + | * Present at Les Houches: Alexandre, 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 11: | Line 14: | ||
==== Main goals (for the end of 2013) ==== | ==== Main goals (for the end of 2013) ==== | ||
- | * 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. |
==== 1st discussion ==== | ==== 1st discussion ==== | ||
- | DLHA is a set of conventions the authors of dark matter calculators agreed upon. These conventions regard the input/output of various information to/from these calculators. | ||
- | |||
- | The main aim at LH13 is to start implementing DLHA in dark matter calculators. What do we need to do to before (or in parallel with) that? | ||
- | |||
* The general problem of fully interfacing arbitrary dark matter calculators is way too complicated, so we should try to simplify the problem by focusing on existing calculations in the existing codes and just create a DLHA to interface those first. | * The general problem of fully interfacing arbitrary dark matter calculators is way too complicated, so we should try to simplify the problem by focusing on existing calculations in the existing codes and just create a DLHA to interface those first. | ||
* As long as we agree about the blocks defined in the LH11 proceedings, we could try to implement those as a first (and simplest) step to see how things go. | * As long as we agree about the blocks defined in the LH11 proceedings, we could try to implement those as a first (and simplest) step to see how things go. | ||
- | * We should clarify the role and aim of the functions. (One interpretation is that functions should mediate information that is more complex than just a set of independent numerical values.) | + | * We should clarify the role and aim of the functions. Functions were introduced to mediate information that is more complex than just a set of independent numerical values. However as it is there are various roles for functions. They |
- | * We should finalize the function format (SLHA+ has a preferred function format) | + | * define function inputs (such as a dark matter spatial distribution) in an abstract, pre-agreed way: |
+ | * ''FUNCTION rho_g type=P args=2 | DLHA rho_g 5 | END_FUNCTION'' | ||
+ | * allow the user direct access to existing methods within the codes: | ||
+ | * ''FUNCTION <name> type=<type> args=<# of args> | libName=<name of compiled library> | funcName=<name of function in library> | END_FUNCTION'' | ||
+ | * allow the injection of external methods into the codes: | ||
+ | * ''FUNCTION rho_g type=C args=2 | #include<math.h> | ...c-code here... | END_FUNCTION'' | ||
+ | * We should finalize the function format (SLHA+ has a preferred function format). | ||
* We should, possibly, decide on a the reader/writer issue (the extension of SLHA+ was proposed as a possible universal I/O DLHA routine). | * We should, possibly, decide on a the reader/writer issue (the extension of SLHA+ was proposed as a possible universal I/O DLHA routine). | ||
* We should make sure that the content of the blocks are fully defined. | * We should make sure that the content of the blocks are fully defined. | ||
- | * We need a platform to communicate with DLHA authors who aren't at LH (email, wiki, video conference?); a face-to-face meeting following LH was also suggested | + | * We need a platform to communicate with DLHA authors who aren't at LH (email, wiki, video conference?); a face-to-face meeting following LH was also suggested. |
==== 2nd discussion ==== | ==== 2nd discussion ==== | ||
- | |||
* Blocks should only contain numerical info where the entries are independent from each other. (This is how SLHA works.) | * Blocks should only contain numerical info where the entries are independent from each other. (This is how SLHA works.) | ||
* A separate TABLE object should be defined as a specific I/O format for functions. | * A separate TABLE object should be defined as a specific I/O format for functions. | ||
- | * In the function definitions we have to fix the content of the tables | + | * In the function definitions we have to fix the content of the tables. |
- | * The table header will 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. | ||
+ | * Parameters should be moved out of functions. | ||
- | ==== Things to do ==== | + | ==== 3rd discussion ==== |
+ | * micrOmegas includes an SLHA reader/writer which could be generalized for DLHA. | ||
+ | * A stand-alone version is published in [[http://arxiv.org/abs/arXiv:1008.0181|arXiv:1008.0181]]. | ||
+ | * 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'' | ||
+ | * 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 abundance, direct or indirect detection calculations, for example.) Then the authors of the codes could distribute libraries (for Linux) from which these methods could be called directly based on DLHA. | ||
+ | |||
+ | ==== 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. | ||
* ... | * ... |