lupoa / grid Goto Github PK

In Grid/tensors/Tensor_Ta.h, ProjectOnGroup should probably be a template. We need to figure out the consequences and find a nice, least intrusive way to separate out the implementation from the interface. We should keep an eye on how such change affects other parts of the code.

We should check if Grid/qcd/representations/spfundamental.h and Grid/qcd/representations/sp_two_index.h can be unified with their SU(N) counterparts and, if so, do this. Potentially some templating again?

As the title says...

Take HiRep's version of projecting onto algebra for Sp(2N).

As the title says...

Just a quick idea: We've started to consistently use Sp everywhere. We should probably rename the configure option accordingly.

The template instantiations in Grid/qcd/action/fermion/instantiation/SpWilson* completely duplicate the structure in Grid/qcd/action/fermion/instantiation/Wilson* except for the #define IMPLEMENTATION ... line in */impl.h. This is streamlined for the procedure in scripts/filelist and might be justified in that respect. We should compare with the other instantiations in that folder and check if the impact on the build scripts is justifiable in favour of a reduction of code duplication.

In the end, we should again go over all the (almost) purely typedef files and see which typedefs are needed.

Commit 88bdd434 could be compiled (once the typo in configure.ac had been fixed). The current commit 8c80f1c fails with undefined symbols like __T0 and __T1. I'll try and collect some more detail and update once I have it.

Might be possible though it is not that likely. Potentially, at least some functionality is duplicated and we can extract that as free functions or the like? Assess if such introduced coupling is advantageous in the long run.

The resolution of my --shm error was that I was parallelising the wrong axes, i.e., I was doing --mpi=1.1.2.2 instead of --mpi=2.2.1.1. While that seems stupid in hindsight, I somehow still thought that this could be a good idea at that time. So, I feel that we should guard against others running into this by, e.g., adding something to the documentation or README or tracking down the error message and adding a hint that it might be a problem of parallelisation.

Should we only include Sp2N-specific headers if --enable-symplectic is set?

Questions to consider here:

• Is there a significant compile time overhead?
• Is there a measurable run time overhead?
• Are there other benefits of one or the other (readability/maintability/...)?

We should strive for maximal consistency about the use of N_colour and N_sp in the interfaces, particularly when given as a (template) argument for instantiations / initialisation. I suspect that exposing N_colour = 2 N_sp as the interface will save us a bit of trouble for the unification with SU(N).

Update documentation. @LupoA, fill in the details, please.

We discussed if implementing the adjoint representation alongside the fundamental is advantageous even if we don't use it ourselves.

Pros:

• Unified user interface
• Symmetric user interface

Cons:

• Might not get enough attention from us and end up in a bad state which might be worse than not having it
• Is additional workload

This probably becomes easier, if not trivial, if we manage a good unification via templating in other parts of the code. Has low priority for now.

Similar to #5.

Some commit removed them. Find that and revert (and check that it didn't do anything else... which it shouldn't if I was a good boy and did single-concern commits...)

This is true for the most recent commit in #22 but seems to go back way earlier (maybe not even on us). Is that expected?

After we fixed the overall structure, we should come back to the few lines of code that will have actually changed and review refactoring steps on them.

There seems to be an issue with this. Ed can fill in the details here...

Lattice's operator= is not __device__, so ProjectOnGeneralGroup needs to return instead of modify in place.