mumax3.10β

[godsic]

@barnex @JLeliaert @JeroenMulkers Can we start from releasing the β-version? Attached are the win64 and linux64 builds linked against CUDA 9.1 and supporting Maxwell+ GPUs (Fermis are now deprecated). mumax3.10beta.cuda91.linux64.tar.gz mumax3.10beta.cuda91.win64.zip

[godsic]

I've modified the release draft that @barnex initiated.

[JLeliaert]

There are a few issues left:

CUDA 9.1 expects the very latest drivers, which is not an option for all users. E.g the latest nvidia driver in the ubuntu repo is not sufficient to run mumax and results in the error :"No binary for GPU. Your nvidia driver may be out-of-date" Therefore, I suggest to also include a version linked against CUDA 9.0 in the binary as well, added below. mumax3.10beta.cuda90.linux64.tar.gz

I also suggest to remove the ptx files for cc20 and cc62, because they are no longer supported and not updated by the make file.

I don't see any other remaining problems?

[JeroenMulkers]

Tests fixedlayer.mx3 and std5b.mx3 fail. I think this is due to the changes made in commit 53dbec4. Both tests are related to the Slonczewski STT. Other tests with the Slonczewski STT (such as std5c.mx3) seem to run fine.

I have have practically zero experience with the Slonczewski STT. Could someone with more experience have a look at it?

[godsic]

@JLeliaert Indeed I've used a regular ./make.bash that produces very recent PTXs format. The problem is that old CUDA releases are not compatible with my Fedora, so at the moment cannot easily generate wrappers with ./make-version-specific.bash and need some time to deploy a Centos box that can handle down to CUDA 5.5. Hope your CUDA 9.0 build will cover most of the users. Please edit the release draft ('Releases' tab) and attach your build there.

@JeroenMulkers Indeed STT tests fail, since they test against (incorrect) results obtained with earlier versions of mumax3. Testing against OOMMF is on my list...

There is also a minor bug in Zhang-Li torque as it assumes g = 2 (mumax3 default value), while user can override it to basically any value.

[godsic]

@JLeliaert @JeroenMulkers Could you please go through the changelog and add / expand those things you are responsible for?

[godsic]

@barnex Do you want to advertise the mumax3.10β to the community?

[godsic]

There is also an issue with mumax3-fft that does not build anymore due to the go linker opening too much files at the same time. To some extend this is a golang problem, but from maintanace point of view it would be nice to either (a) split tools to a separate repo and decouple them from mumax3 releases or (b) link mumax3-fft against fftw (e.g., using https://github.com/runningwild/go-fftw) instead of embeding its sources.

[JLeliaert]

This didn't give any problems here.. I included it without problems in the CUDA9.0 binary

[godsic]

@JLeliaert it caused issues on Windows for a while and now, since golang 1.10, on Linux too. Nevertheless, for the release version I can downgrade my golang to 1.9.x and then provide mumax3-fft as well.

[JLeliaert]

golang was an even older version (1.7). I'll upgrade to 1.9 and rebuild

[godsic]

@JLeliaert BTW, Nvidia hosts repos for most popular distributions (see, e.g., https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&target_distro=Ubuntu&target_version=1704&target_type=debnetwork). Those provide cuda and driver updates.

[barnex]

Hi all.

1) I've moved mumax3-fft to https://github.com/mumax/mumax3-fft 2) For the failing STT tests: we could, e.g,. comment them out and mark as TODO, or replace the expected values with what mumax currently outputs, and verify against OOMMF later. In any case, I don't think it's very healthy to have failing tests in a release 3) Ubuntu 18.04 LTS is due today. Please give me a few days to try and build for 18.04, using cuda from the repo. 4) I'm not sure if we should advertise the beta just yet. It feels a bit like an alpha at this moment. We could advertise it as such or call it beta when we have a few more issues sorted out.

Thanks, -Arne;

[barnex]

I've updated my machine to ubuntu 18.04, which ships with nvidia-390 and cuda 9.1. Everything seems to work, including mumax3.10beta.cuda91.linux64.tar.gz. Nice that the driver and cuda toolkit can be taken from the repos.

As far as I'm concerned, we can publish.

[godsic]

@barnex +

[JLeliaert]

Great, that solves my last concern.

[godsic]

I've fixed the fixedlayer.mx3 unit test to address #127, std5b is on the way...

[godsic]

std5b is fixed with 0a27edafe1b57f9eb33a752d17aed705a777a0da

[godsic]

@JLeliaert @JeroenMulkers FYI The results are somewhat card-vendor-dependent, e.g., in my dev box 1080 gets at most 20% speedup, while in cluster nodes it goes up to 55%.

[godsic]

@JeroenMulkers Have you implemented free BC in DMI or shell we upstream https://github.com/fangohr/paper-supplement-standard-problem-dmi/tree/master/sims/MUMAX3/src_files ?

[JeroenMulkers]

The kernel implemented on https://github.com/fangohr/paper-supplement-standard-problem-dmi/tree/master/sims/MUMAX3/src_files was sufficient for a specific case in their paper, but does not assure open BC for the general case. Pull request #195 includes an implementation of open BC which can be used in the general case.

[godsic]

@JeroenMulkers if it is an opt-in future, then I don't see any problems keeping it around. Anyway, @barnex @JeroenMulkers @JeroenMulkers are you OK with publishing beta now? I think we can merge openbc DMI at the final stage then.

[JLeliaert]

Can we wait until tomorrow? @JeroenMulkers is finishing up making the relevant bib information more visible.

[godsic]

@JLeliaert sure, then perhaps I will have some time to look at openbc dmi...

[godsic]

@barnex @JeroenMulkers @JLeliaert For the release, we should agree on which CUDA release should we stick to. For desktop users, I think requiring CUDA 10 is perfectly fine as it could be easily installed/updated these days on all major Linux distros and Windows. I would suggest to go this way for the beta release. Supercomputer users might benefit from additional compatibility, but this is something we can figure out for the final release.

[JLeliaert]

I agree on using CUDA 10 as the main download. On the other hand, I have no problem providing separate binaries using older versions for supercomputer users who require them. Especially since quite a lot has changed since the last release.

[godsic]

@JLeliaert @JeroenMulkers it appears to me openbc needs a bit more love, so I would suggest to proceed with beta release today. I will do Windows and Linux builds linked against CUDA 10. Feel free to contribute CUDA 9.x builds.

[JeroenMulkers]

@godsic The implementation of the open bc is rather trivial, and I do believe that there is not much to test (virtually all tests run fine with open bc). So I think we can safely include the open BC. The only question which remains is not a computational one but a physical one "which BC should be used?". By providing both, we can let the user decide. If you want to look into the open bc in more detail, we can proceed with the release without the open bc.

The gui (and the 'script world') contains a few variables which start with '_', since the implementation of the magnetoelasticity. Is there any situation in which a user should have access to these variables? If not, is it possible to remove these variables from the 'script world'? The GUI is mainly used by inexperienced users which might be confused by these variable fields.

[godsic]

@JeroenMulkers Indeed MEL stuff should not be visible and is not ready from prime time. I've merged it to let some interested parties to start playing with it and figure out if it is implemented as intended.Anyway, fixed in deda0779369059b468b60c5a46923283ca8e44bb

[godsic]

@JeroenMulkers Please add a note regarding openbc to the release draft

[JeroenMulkers]

@godsic Done.

[godsic]

Published. I will write the announcement to the group later today.