90 likes | 199 Views
Report from Metadata Working Group. ILDG8 QCDml1.3 solved all known issues, except “action normalization” ILDG9 Normalization issue Namespace Future work action notation issue more actions gauge fixed configurations documentation. ILDG9 (Dec.01,2006)
E N D
Report from Metadata Working Group • ILDG8 • QCDml1.3 solved all known issues, except “action normalization” • ILDG9 • Normalization issue • Namespace • Future work • action notation issue • more actions • gauge fixed configurations • documentation ILDG9 (Dec.01,2006) T. Yoshie for MDWG CCS,Tsukuba
plaq. rect. sixLink 3d chair iwasakiRG DBW2 treeLevelSymanzik LuescherWeisz tpLuescherWeisz Normalization issue consider sixLinkGluonAction two major coupling normalizations
two possibilities (at ILDG8) • choose one normalization for one action • user-side search engine does not have to take care of normalization conversion • groups which use different normalizations have to convert normalization before submission • allow various normalizations using a <normalisation> tag • coupling values in the ensemble XML agree with those in the literature • one has to convert normalization to find all equivalent ensembles • an issue of ILDG design strategy • asked ILDG board for decision • strategy of “normalisation tag” is chosen • MDWG is asked to decide on normalisation tags and give a recommendation
cs_sum_to_one c0_is_one Normalization issue: Proposal • use <normalisation> tag only for sixLinkGluonAction • it not used for other actions, before the need arises • Currently allowed values of the tag • <normalisation> tag is placed after <beta> • recommendation cs_sum_to_one iwasakiRG, DBW2, treelevelSymanzik LuescherWeisz c0_is_one tpLuescherWeisz
Namespace • new schema is not backward-compatible • how to treat namespaces • if we follow ILDG7 conclusion (see the last slide) ,we assign a new namespace • XML IDs with sixLinkActions belong to the ensemble1.4 • if we want to avoid rewriting other XML IDs.... • multiple namespaces in ILDG MDCs • others belong to the old namespace ensemble1.3 • whether we accept multiple namespaces depends on • strategy, middleware support • mismatch of version numbers for ensemble and config. • configuration schema is not changed. Config XML IDs (can) belong to the current namespace • causes no technical problem, someone may feel unpleasant http://www.lqcd.org/ildg/QCDml/ensemble1.4 http://www.lqcd.org/ildg/QCDml/config1.3
problem occurs whenever non-backward-compatible change is made • rule has to be established • my personal opinion • rewrite all ensemble XML IDs (rewriting namespace and schemaLocation is an easy task) • allow mismatch of version numbers between ensemble and configuration • enables us to avoid complexity of middleware implementation • other possibility to avoid multiple namespaces • keep namespace (ensemble1.3) unchanged • ambiguity in version control • need opinion specifically from middleware working group
Future work • action notation issue • for wilson/clover actions, we currently employ a hopping parameter notation i.e. field normalisation is • some groups prefer to use mass m • this isnot just a difference in the meaning of a coefficient, but a different parameter set (m vs. ) • I hope we come to conclusions soon • if community recognizes that both notations are standard, we may follow a strategy we have taken for the normalization issue
a request to markup a complicated action • anisotropic clover fermion with stout smearing of the links in the fermion operator • the Morningstar-Peardon type gauge action (plaquette + rectangular in spatial direction) + adjoint term in spatial direction • design strategy discussions are necessary • Anisotropy in gauge/fermion actions • Link smearing in gauge/fermion actions • gauge fixed configurations • once discussed in May 2004, but postponed • documentation • minimal documents embedded in XML schema as annotation • human readable documents are necessary to describe details, e.g. normalization recommendation ....
QCDml1.2.0 release major/minor version COPY from ILDG7 MDWG report QCDml1.2.0 • modification from the old version is minor • the new one is not compatible with the previous QCDml1.1 • compatible: if IDs written based on the old schema are still valid under the new one. • strategy to name and treat new QCDml schema • if not-compatible, count-up major/minor version number • if compatible, count-up release number. All releases (with the same version number) belongs to the same name space, e.g. QCDml1.2.x has targetNamespace="http://www.lqcd.org/ildg/QCDml/ensemble1.2"