Possible closer collaboration between Mumax3Mod and Amumax

[MathieuMoalic]

Hi there,
I just discovered this repo yesterday. You have done so much, this is quite impressive.
As I want to make my own Amumax fork as feature rich as possible, I was looking at implementing the same modifications as you did, to Amumax.
But this all seems a little bit wastefull on time, seeing as you are porting the frontend from amumax to mumax3Mod and I would be doing something similar but the other way around.
Any thoughts?

[timvgl]

Hi,

Thank you! I can only return the compliment regarding the new UI and the templating scheme—great work!

I’ve been considering integrating all features of amumax into Mumax3Mod (which, by the way, is just a placeholder name—feel free to suggest a better one). One thing to note is that I’m not particularly interested in using Zarr as an output format. Here in Germany, there’s a growing standard around using HDF5. Because of this, Zarr doesn’t align well with our needs. Instead, we’re generating OVF files and converting them into xarray datasets using mumaxXR. Xarray provides the flexibility to store data in various format. I’m exploring the possibility of adding a direct HDF5 storage option, though it’s still just an idea.

Another key consideration for me is ensuring backward compatibility in this repository. The goal is for the code to behave like the original Mumax3 or Mumax3-ME unless new features are explicitly utilized. For instance, while I understand the reasoning behind replacing SetGridSize with Nx, Ny, etc., this change makes it harder to reuse older Mumax scripts. That’s why I aim to preserve the existing structure of the Go code and only expand upon it.

Of course, I’m open to closer collaboration! However, one challenge lies in the structural differences between our versions of Mumax. I’ve retained some folders and structures that you’ve removed, which makes merging features into both repositories simultaneously a bit tricky. Establishing a common standard could help streamline the process and reduce the workload.

Looking forward to hearing your thoughts!

Best regards,
Tim

P.S. Please note that there are some features in this repo that are not well developed. They are very experimental.

[MathieuMoalic]

Interesting remarks!
It good to have external feedback.

• Regarding hdf5, I was actually using it a few years back before I was using zarr. I switch to zarr because in my opinion it is better in everyway except for the fact that it is less commonly used. I broke a lot of the standard mumax when I implemented it a couple years ago. I was the only one using the software back then so it didnt matter.
  I do however plan to implement a modular system where one can choose the saving format, zarr, ovf and hdf5 could just be inplementations of these.
• I added back SetGridSize and other such functions a few days ago actually. I don't quite remember why I removed them in the first place.
• I will eventually try to create some kind of API for input and outputs. The input API kind of already exist as you can control simulations through the /api/endpoints.

As you can imagine this is all very time consuming, especially when working on a 10+ years old code base. I really enjoy working on it though!

[timvgl]

I like the idea of adding more output formats as a modular system upon the normal mumax.
Adding SetGridSize etc in is a good thing - thanks :)
Yeah the idea with the api makes sence. This would make adding code and other output formats more flexible. It would just have to be done carefully in order to make sure that it is not turing into a bottleneck.

Working on mumax is getting easier and easier for me the more I work in it. I also really enjoy it.
I am not sure so far how a closer collaboration could look like in a more formal way. Espacially in the case if new algorithms are developed that would require a paper etc.
In the end three scientific groups would be involved (Poznaniu, Kaiserslautern and Salamanca (a lot of code on this repo has been devoloped during my stay there)).
I would propose that we move this conversation into the private area, to elaborate on that further.