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.

Present at Les Houches: Alexandre, Andreas, Ben, Benj, Björn, Csaba, Fawzi, Geneviève, Nazila, Sasha, Sezen, Pietro; Outside of Les Houches: Ben Allanach, Peter Skands, …

• 2011 Les Houches proceedings (DLHa starts on page 9)
• Csaba's DLHA talk in Stockholm (June 2012)
• 2013 DLHA write-up: LaTeX source, PDF

• Elevate the DLH agreement to a DLH Accord,
• Start implementing DLHA in dark matter calculators.

• 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.
• 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 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 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.

• 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.
  • In the function definitions we have to fix the content of the tables.
  • The table header should look like this:
    • TABLE <name> <column> <row>
  • 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.
  • 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.

• micrOmegas includes an SLHA reader/writer which could be generalized for DLHA.
  • A stand-alone version is published in 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.

• The write-up has to be updated to reflect the changes we decide to make at LH13.
• …