GaugeConfigurations and Origins

[ckoerber]

Two points:

1. Once you invert the Dirac equation, you have to know about the gauge config and the origin vector. Thus it is consistent to tie those informations together.

2. Where do you put this information?

Does a Propagator only know about the general Ensemble or should it now about each individual GaugeConfig. If the propagator only has knowledge about the ensemble, one must tie the gauge config info to the propagator at a later point.

A. Advantage of ensemble knowledge only is that it keeps the physics table small.

B. Advantage of gauge config knowledge is that this is closer to the actual code objects.

What are your opinions?

[evanberkowitz]

I'd say the propagator doesn't even know about the ensemble necessarily. It knows the gauge configuration (by which I mean: some particular configuration in some markov chain), which knows the sea action. The propagator also knows about the RHS and the solver (which knows the valence parameters, and perhaps algorithmic information).

[ckoerber]

After some discussion with @cchang5 we converged on the following compromise:

Propagator

• propagator specific stuff
• gaugeconfig (new table)

GaugeConfig

• gauge config specific stuff (meaning ensemble specific stuff)
• tag

No Ensemble table

1. The tables are consistent (no meta table)
2. The tables are more simple (no meta table)
3. We have a lot of propagator entries (which reflects the real world)
4. At the analysis level, we have to specify what an ensemble is (list of gaugconfig / propagator / ... ids).

[ckoerber]

About Propagators and PropagatorSources

Next discussion point: it seems to be possible to describe any propagator as

Propagator

• gaugeconfig (Table)
• valenceaction (Table)
• source (Table->PropagatorSource)

PropagatorSource

• stuff

where specializations of PropagatorSource are, e.g., Point(PropagatorSource), FeynmanHellmann(PropagatorSource), Sequential(PropagatorSource), Laph(PropagatorSource), ... (which could also point to Propagators).

This basically shifts information from propagators to the Source (we just need one Propagator table).

[erinaldi]

About HISQ propagators (or CLOVER in the future)

• valenceaction should be flexible enough to contain parameters from all kind of fermionic actions.

Maybe a better way to think about this is

• gaugeaction (Table->gaugeconfig)
• fermionaction (Table)

[ckoerber]

Discussion continued in #20.