Alexandre, Andreas, Ben, Benj, Björn, Csaba, Fawzi, Geneviève, Nazila, Sasha, Sezen, Pietro, …

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

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

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