Trace creation of propagator

[smangham]

We need to identify where the propagator is created.
ks_spectrum/lattice.h is where the lattice sites are defined, and these then use hisq (Highly Improved Staggered Quarks) to generate the fermion matrix, then inverts it. We need to find the step before the inversion. I should try making a more specific property call graph, using the function call graph I've generated, to figure out where it comes from.

Likely to involve:

• ks_spectrum/lattice.h
• generic_ks/hisq.h` ???
• includes/generic_ks_includes.h
• lo_prop_ks.c

[smangham]

Starting with main() in ks_spectrum/control.c:

• Includes ks_spectrum_includes.h
• control.c:72-74: Declares ks_prop_fields source, quark and prop .
  • prop is size MAX_PROP - relevant for future?
  • Initialises all to NULL
• control.c:75: Declares int prop_nc of size MAX_PROP
  • Relevant for the future?
• control.c:340: Declares ks_prop_fields tmp_source and tmp_src_qs of size MAX_PROP, and loops over the propagators
  • control.c:357: prop[i] is set to create_ksp_field
  • control.c:379: solve_ksprop is passed prop + i0, where i0 comes from param.begin_prop
    • Probably a memory offset for start of propagator array + propagator start offset?
    • param is not defined in control, control doesn't explicitly set it - it must be buried somewhere.
  • control.c:400: 'Complete the quark propagators by applying the sink operators to either the raw propagator or by building on an existing quark propagator'
    • control.c:500: Creates quark[j] using create_ksp_field again, then applies ksp_sink_op to it
    • control.c:511: Creates quark[j] using create_ksp_field again, then applies scalar_mult_add_ksprop_field to it
• control.c:562: 'Compute the meson propagators'
• control.c:609: Calls spectrum_ks on the quarks.
• • TODO: Explore more? Check with Bipasha about this one.
• control.c:633: 'Compute the baryon propagators'
• control.c:687: Calls spectrum_ks_baryon on the quarks.
• • TODO: Explore more? Check with Bipasha about this one.

So reminder to self: The propagator we're interested in is based on the fermions (1/2 integer spin).

• Quarks are fermions (1/2 integer spin),
• Mesons are not (2 quarks)
• Baryons are (3 quarks)
  So the fermionic propagators are the quark and baryon ones.

So the possible propagator points are:

• 'Raw propagator': Defined prop, and initialised in create_ksp_field
  • Probably what we want.
• 'Solved propagator': Defined prop, solved in solve_ksprop
  • Probably the solved propagator.
• 'Completed propagator': Defined quark, solved by ksp_sink_op, modified by scalar_mult_add_ksprop_field
  • Probably the correlator.

[smangham]

So:

• We actually want the meson propagator
  • control.c:609 passes the meson propagator info to ks_spectrum
  • Within ks_spectrum there should be an equivalent to spectrum_ks_baryon_init/create_hadron_prop that will be meson-based
  • Whatever matrix gets inverted in that should be the source terms we want.

[smangham]

As a reminder:

• Fermions: 1/2 integer spin, so all base particles (quark, electron e.t.c.) and some of the combined particles.

• Hadrons are made up of quarks

  • Some are Fermions (odd spin - odd number) -> These are Baryons
  • Some are Bosons (even spin - even number) -> These are Mesons

• We want the Meson propagator

• ks_spectrum/control.c:609 - spectrum_ks(quark[iq0], naik_index0, quark[iq1], naik_index1, i);

  "Tie together to generate hadron spectrum"

  • Uses quark[iq0], naik_index0, quark[iq1], naik_index1, i

• ks_spectrum/control.c:687 - spectrum_ks_baryon -

  "Tie together to generate hadron spectrum"

  • Uses quark[iq0], quark[iq1], quark[iq2], i

• ks_spectrum/spectrum_ks.c:1170 - spectrum_ks

  • 1177 - Calls spectrum_ks_init
  • 1182/1192 - Calls spectrum_ks_diag_meson or spectrum_ks_offdiag_meson
    • These both call accum_gen_meson
  • 1185/1195 - Calls spectrum_ks_print_diag
  • 1200 - Calls spectrum_ks_cleanup

• spectrum_ks.c:454 - spectrum_ks_init(int pair)

  • 460 - Calls create_hadron_prop, but only if params.do_meson_spect is on for the pair
    • This is also called in the spectrum_ks_baryon_init function.
    • Assigns to pmes_prop - is this a propagator, then? Of the fermions that will contribue to a meson?
  • 463 - Calls create_num_corr_occur
  • 466 - Calls create_corr_table

• spectrum_ks.c: 38 - create_hadron_prop(int ncor, int ntime)

  • Allocates an array of pointers to an array of complex numbers, ncor outer size, ntime inner.
  • Zeroes it.
  • So something else fills this.
  • Looking for references to pmes_prop, it looks like spectrum_ks_offdiag_meson just forwards to it to spectrum_ks_offdiag_gen_meson, and the same for spectrum_ks_diag_gen_meson.

• spectrum_ks.c:1150 - spectrum_ks_cleanup

  • Uses destroy_hadron_prop to wipe that, destroy_corr_table, and destroy_num_corr_occur.

• spectrum_ks.c:420 - create_num_corr_occur(int pair)

  "Counts the number of contributions to a given meson correlator for normalization purposes"

  • So not it

• spectrum_ks.c:358 - create_corr_table(int pair)

  "Create a table of correlators for the current pair. The table
  consists of a list of unique sink spin-taste indices, and a list of
  the correlator indices for each spin-taste assignment"

  • This doesn't sound lattice-y?
  • Implies the correlators have already been computed

• spectrum_ks.c:513 - spectrum_ks_diag_gen_meson

  • pmes_prop argument now renamed to mp (unhelpful!)
  • It calls accum_gen_meson, with mp as the first parameter.
  • Same with some extra checks in spectrum_ks_offdiag_gen_mesons.

[smangham]

OK, let's go from the other direction. The lattice struct is site; lattice.h declares an array of them called lattice.

The site type is used in generic_ks/cppacs_help[0-5].c which appears to be a function for processing the sites in a vectorised way.

So, uses of lattice:

• cpaccs_help0 e.t.c. again, looks like red-black array stuff
• And a lot of macro substitutions in generic and generic_ks through F_OFFSET.

Looks like F_OFFSET and F_PT are pointers to a field, where 'field' is the name of the field (macros.h:45). Neither of those are used directly in the files in ks_spectrum. At what point do the calls from spectrum_ks start hitting functions that use the lattice indirectly?

• spectrum_ks.c:503 - accum_gen_meson

  • Contains calls to external functions ks_meson_cont_mom and get_fm_links
  • get_fm_links call doesn't pass any arguments beyond fn_links, declared in lattice.h. This is

    Storage for definition of the quark action

    • fermion_links_hisq_milc.c:350 - get_fm_links
      • ...just wraps get_milc_hisq_links_fn
  • ks_meson_cont_mom is passed the mp variable

• ks_meson_mom.c:160 - ks_meson_cont_mom

  • mp is now prop
  • This appears to tie the sink terms and propagators together!

[smangham]

So, we can print out pmes_prop before spectrum_ks_cleanup(pair).

What's in the spectrum_ks_print_diag function and offdiag equivalent? They do extract the meson propagators for each pair to report on. They print the start and end one.

How do we trigger this?