Revision 3daaf001d181d18e88937c0623708dd1767f9b9e authored by Balint Joo on 27 March 2017, 19:07:43 UTC, committed by Balint Joo on 27 March 2017, 19:07:43 UTC
including smearing and anisotropy. -- It may or may not give an algorithmic advantage but the solutions are good.
1 parent cda379a
gaugebc.h
// -*- C++ -*-
/*! @file
* @brief Gauge boundary conditions
*/
#ifndef __gaugebc_h__
#define __gaugebc_h__
#include "chromabase.h"
#include "boundcond.h"
namespace Chroma
{
//! Base class for all gauge action boundary conditions
/*! @ingroup gaugebc
*
* NOTE: this class is specifically using LatticeColorMatrix, but
* probably should generalized to a template. The point is that coordinates
* and momenta within HMC are general. The FermAct classes have a param
* type (T,P) = (type of fermion, type of conjugate momenta) the latter
* part used in the deriv stuff. Here, the "zero" could be on any conjugate
* momenta. The modify, however, is usually on the coordinates which
* is often the LatticeColorMatrx. The FermBC has a template param
* for the fermion type that is used in the "modifyF", but is fixed
* for a LatticeColorMatrix in the "modifyU".
*/
template<typename P, typename Q>
class GaugeBC : public BoundCond<P,Q>
{
public:
//! Virtual destructor to help with cleanup;
virtual ~GaugeBC() {}
//! Apply the BC onto the U fields in place
virtual void modify(Q& u) const = 0;
//! Zero some gauge-like field in place on the masked links
virtual void zero(P& ds_u) const = 0;
//! Says if there are fixed links within the lattice
virtual bool nontrivialP() const = 0;
};
}
#endif
Computing file changes ...