Closed ckoerber closed 5 years ago
changelog
Action table changes: Split Action -> FermionAction and GaugeAction
Moved quark masses into FermionAction. Tag quark name. In particular, allows same mass to be called different names (light, up, down for example) Quark mass dropped from propagator and gaugeconfig
Moved beta into GaugeAction
Ensemble table changes: Renamed Ensemble -> GaugeConfig Changed Nconfig -> Config to specify specific config number GaugeConfig has children (e.g. Nf211) which FKeys to gaugeaction and fermionactions
Propagator table changes: Propagator now points to gaugeconfig and fermionaction Children of propagators specialize different RHS. (Decided to not make a source table and just specialize in Propagator).
Current table changes: removed flavor from Local(Current). The propagators explicitly contain quark mass info now. moved momentum into current to denote momentum transfer. created Local4D to spatial current (non FT’d) removed momentum from FHPropagator
Hadron table changes: rename to Interpolator moved momentum into children tables. remove momentum from correlation functions (All momentum now defined at interpolating operator and current if in momentum space)
HadronSmear table changes: rename to interpolatorsmear
Todo: Need to think more about Interpolator table. Need to work on non-physics tables.
We settled for the following physics table layout with commit 0b94784e18309080f1ed40374a9aaca79df9d2a3 and following.
Note that the gauge config table now has a config
column so that we will have many gaugeconfigs for a given ensemble
(thus all tables depending on gaugeconfig
will have many entries as well). The ensemble
table groups gaugeconfig
s.
Result of todays table meeting
Below you can find the current form of the physics tables (which is going to change).
models.pdf
Please take a look, ask questions and suggest modifications.
Specifically entries with a question mark or a
/
need suggestions.Proposed changes
Ensemble -> GaugeConfig
Ensemble
table will become aGaugeConfig
table which will carry explicit gauge config ids. Thus we will have more rows in each propagator table because each propagator now knows about the specific id.action
column will now point to newSeaAction
table which carries quark mass informations. For this reason theFlavor211
table will be dropped.Action
FermionAction
mass
-> floatquark
-> strgauge_smear
->GaugeSmear
GlueAction
beta
-> floatname
-> strgauge_smear
->GaugeSmear
SeaAction
fermion_actions
-> List[FermionAction
]glue_action
->GlueAction
m_pi
based on actionsFermionAction
(columns to be determined)Hisq
?MDWF
?Clover
?Propagator
ensemble
togauge_config
and thus have angauge_config.id
mval
stays in propagator and not in actionaction
->FermionAction
Source
table (which propagators point to). This has the reason that it basically just shifts work fromPropagators
toSources
while some sources will not exist as files and also querying becomes more difficult.Current
momentum_{x, y, z}
-> intHadron -> Interpolator?
Hadron
table toInterpolator
n_up
-> intn_down
-> intn_strange
-> intn_charm
-> intn_bottom
-> intn_top
-> intmomentum_{x, y, z}
-> intspin
andspin_z
andparity
because they are not good quantum numbersisospin
andisospin_z
because they are redundant (sincen_{up, down}
)irrep
-> str?irrep_row
-> int?Interpolator
later on into, e.g.,Nucleon
or others.Basic
tableNon-physics tables
According to https://github.com/callat-qcd/lattedb/issues/18#issuecomment-516631851
Job/Task/Data/Status
physics
->PhysicsTable
(likeCorrelator
)machine
->Machine
computation
->Computation
status
-> intMachine
topology
-> str (distribution of lattice among processors)n_cpu
-> intn_gpu
-> inthome
-> strscratch
-> strtape
-> strComputation?
name
-> str (descriptive info)details
-> son/blob/file (infos to uniquely define the computation)The reason for keeping
Computation
simple is that it seems hard to generalize. Also, it seems like that you do not specifically query for specific information -- you might want to backtrace previous runs though. The disadvantage is that the actual jobs must be created externally. E.g., given machine and physics object, generate me the actual job to submit, submit this job, push this job to the DB with status submitted.