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:54] balazs.csaba |
2013:groups:tools:dlha [2013/06/20 14:21] 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, and 50+ more people. | ||
==== 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. 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 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 | ||
- | * define complex inputs (such as a dark matter spatial distribution) in an abstract, pre-agreed way: | + | * 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'' | * ''FUNCTION rho_g type=P args=2 | DLHA rho_g 5 | END_FUNCTION'' | ||
* allow the user direct access to existing methods within the codes: | * allow the user direct access to existing methods within the codes: | ||
Line 28: | Line 27: | ||
* allow the injection of external methods into the codes: | * allow the injection of external methods into the codes: | ||
* ''FUNCTION rho_g type=C args=2 | #include<math.h> | ...c-code here... | END_FUNCTION'' | * ''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 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. | * 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 severely tie the hands of the author(s) of the original code, and it is not feasible. | ||
+ | ==== 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. | ||
* ... | * ... |