2013:groups:tools:dlha
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
2013:groups:tools:dlha [2013/06/18 16:56] balazs.csaba |
2013:groups:tools:dlha [2013/06/20 17:24] (current) 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. |
| + | * Testing DLHA between at least two codes is essential before the final report is completed. | ||
| ==== 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 34: | Line 34: | ||
| ==== 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 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 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 ==== | ||
| * 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.1371567371.txt.gz · Last modified: 2013/06/18 16:56 by balazs.csaba
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Public Domain
