Missing documentation for everything not Helmholtz

[mipals]

Hello,

I am currently trying to implement a Julia-interface for this library (pretty much a copy-paste of the one for FMM3D). However, the documentation seem to only cover the Helmholtz problem. Is it safe to assume that the Laplace problem is defined similar to the Helmholtz problem, i.e. something like

$$ u(x) = \sum_{j=1}^{N} c_j\log(\|\mathbf{x} -\mathbf{x}_j\|) - v_j\mathbf{d}_j\cdot\nabla \log(\|\mathbf{x} -\mathbf{x}_j\|) \quad ? $$

Furthermore there is also implemented other kernels, but I have no experience working with these. As such I have no idea how their potential might look like and hence have problems implementing a possible interface.

Cheers,
Mikkel

[mrachh]

Dear Mikkel,
Thanks for doing this. Apologies that the documentation is not in place, we'll get that fixed soon.

Regards,
Manas

[mipals]

Hi Manas,

Most of the work were already done by Travis for the 3D version, so most of the credit should go to him 😄

Don't stress too much about getting the documentation in place. I personally only need the Helmholtz interface, but I thought I might as well implement the others while I was at it.

Cheers,
Mikkel

[mipals]

Any update on this?

[mrachh]

Dear Mikel,
Apologies for the delay in this. We've been dealing with some feature upgrades. We hope to have the library up to date on documentation within the month.

[mipals]

Sounds good. I was just asking since somebody mentioned in the registration of the Julia wrapper of FMM3D that the Julia wrapper of FMM2D only contained Helmholtz (the reason here being the lack of documentation).

Anyhow, please let me know when the upgrade is released so that I can upgrade the Julia wrapper. Are some of the feature upgrades important? (In this case I would have to upgrade the binaries)

In addition, if you prefer to have the Julia wrapper directly in this repository (similar to how it is for FMM3D), then I would be happy to transfer it.

[mipals]

Someone just asked for Laplace and Stokes in the 2D wrapper. Is there any update on the documentation? If there it is soon there, I will wait until then. Otherwise I guess I will have to look a bit into the source-code 🧑‍💻

[mrachh]

Hi Mikel, sorry about the delay. I'm in the process of getting those sets of documentation in. I should probably have them by the end of next week. Would an updated math.rst suffice for now?

[mipals]

I could the math.rst a go for now. Never tried that format before, but it should probably be manageable?

[mrachh]

Dear Mikkel,
I have updated the documentation on the math side that lays down all the definitions. I'll add in the documentation for the fortran, python and matlab wrappers soon.

You can find the math documentation at https://fmm2d.readthedocs.io/en/latest/math.html

[mipals]

Hi Manas,

Thanks a lot! Having the math will help a lot!

[mipals]

A short update: I am having a bit of trouble with the cfmm2d functionality. In the documentation it is stated as $\text{log}(|z - \varepsilon_j|)$, but I keep getting imaginary potentials out for charges with 0-imaginary part and no dipoles. My only idea is that it might be $\text{log}(z - e_j)$, but I still do not get the correct value out for my dense test calculation.

Note that the binary currently wrapped is about two years old, so it might also be due to that?

[mrachh]

Yes, that is in fact an artifact from a previous commit. We realized this issue and changed the behavior of cfmm2d to fix this.

[mipals]

Ahh ok. I guess I will have to figure out how to update the binaries. Is there some updates coming soon or would it be a good idea to already update the binaries now?

[mrachh]

I think it might be worthwhile updating the binaries now. We are hoping to add elasticity FMMs in the near future and maybe even update integers to 8 byte integers to be consistent with our other libraries, but both of those things could take a month+

[mipals]

Perfect, I will try to update the binaries.

The way Julia updates them, however, requires a version number. I can see that the documentation still say 1.0.0, which is what the current binaries are called. I might be able to override them, but it would be easier if I could just bump the version to e.g. 1.0.1 or 1.1.0?

[mrachh]

Let's call it version 1.1.0, I've updated that in the docs and will update a release too once I get all the matlab and python wrappers + documentation in place

[mipals]

Sounds good!