Fmm harmonic compression

[rpep]

Pulls in new FMM perf. improvements, should be substantially faster. Also had fixed a sign bug so it'll be more accurate too.

[davidcortesortuno]

Looks great to me. I cannot provide precise feedback as there are lots of technical details for this massive source code. Tests look fine, which are an advantage when adding/improving new features with AI. Can you provide:

• Benchmark testing speeds against normal FFT demag?
• Documentation in docs (AI generated is fine, quite clever, you can follow the NEBM docs which were updated recently; I'd even pass your paper or so, so the machine summarizes what the code is doing)

I can try to add some of them if you need to

[davidcortesortuno]

CI failure: two bugs in fmmgen, the first hiding the second

The build fails at

fatal error: /tmp/fidimag_regen/operators.h: No such file or directory

Both causes are in fmmgen/writer.py, not in
anything hand-written here, so the fix belongs upstream and then the operators
get regenerated.

1. The include names the path the header was written to

fidimag/atomistic/fmmlib/operators.cpp:1 on this branch:

#include "/tmp/fidimag_regen/operators.h"

operators.h is committed right beside it, and master has the correct
#include "operators.h". This is the only absolute path anywhere in the
branch's build inputs.

writer.py emits #include "{name}.{hext}", and name also decides where
the files are written:

f = open(f"{src_dir.rstrip('/')}/{name}.{fext}", "w")
...
f.write(f'#include "{name}.{hext}"\n')

So generating with name='/tmp/fidimag_regen/operators' — the natural way to
put the output somewhere — writes the files correctly and poisons the include.

2. What that was hiding: __restrict at call sites

Fix the include and it gets as far as the compiler, then fails with 396
errors across 198 call sites:

void S2M(double x, double y, double z, double * __restrict S, double * __restrict M, int order) {
switch (order) {
  case 2:
    S2M_2(x, y, z, __restrict S, __restrict M);   // not valid C++

__restrict is a declaration qualifier and cannot appear at a call site. The
dispatch is built by deleting type keywords from the declaration to turn it
into a call:

replaced_code = (
    func.replace(f"_{start}", f"_{i}")
    .replace("* ", "")        # "double * __restrict S" -> "double __restrict S"
    .replace("double ", "")   #                        -> "__restrict S"
    .replace("float ", "")
    .replace("void ", "")
)

__restrict is not in that list, so it survives. master's generated file has
zero occurrences of the pattern, because its signatures do not carry
__restrict and the string-munging happened to work.

Suggested fix

Take the last identifier of each parameter rather than deleting keywords, and
emit the basename in the include:

def _call_arguments(declaration):
    """The argument names of a C declaration, ready to be called with.

    >>> _call_arguments('void f(double x, double * __restrict M)')
    'x, M'
    """
    inside = declaration[declaration.index("(") + 1:declaration.rindex(")")]
    names = [re.split(r"[\s*]+", p.strip())[-1]
             for p in inside.split(",") if p.strip()]
    return ", ".join(names)

        called = func.split("(")[0].split()[-1]
        arguments = _call_arguments(func)
        for i in range(start, order):
            code += "  case {}:\n".format(i)
            code += "    {}({});\n    break;\n".format(
                called.replace(f"_{start}", f"_{i}"), arguments)

-    f.write(f'#include "{name}.{hext}"\n')
+    f.write(f'#include "{os.path.basename(name)}.{hext}"\n')

Verified

Regenerated with this branch's own options as recorded in operators.h
(compress=True, source_order=1, atomic=True, language='c++'), at order 4 so
it is quick, deliberately passing a directory as name to reproduce the
original bug:

line 1 of operators.cpp:   #include "operators.h"
__restrict at call sites:  0
dispatch:                  S2M_2(x, y, z, S, M);
g++ -fsyntax-only -fopenmp: compiles cleanly

I have not pushed anything to fmmgen or to this branch. Once the generator is
fixed, regenerating at order 13 should be all this PR needs — worth running in
the background, the cost climbs steeply with order.