Feature/regionwise gammaLL #315
Conversation
remove 'submarine' definition of gamma0. Gamma0 was defined here and used in zhangli.cu, instead of the user-definable gammaLL. This was a bug, that causes a wrong calculation of the Zhang-Li torque in the cases that the user changes gammaLL.
added function ScaleGamma, which is used to implement the region-wise gamma factor.
changed the zhangli to use the user-defined gammaLL and not the constant gamma0. This was a bug, that causes a wrong calculation of the Zhang-Li torque in the cases that the user changes gammaLL.
changed the zhangli to use the user-defined gammaLL and not the constant gamma0. This was a bug, that causes a wrong calculation of the Zhang-Li torque in the cases that the user changes gammaLL.
Changed the temperature field calculation to take into account the region-wise factor of gamma.
Changed the temperature field calculation to take into account the region-wise factor of gamma.
added support for a regionwise factor for the parameter gammaLL. The total torque is now multiplied by this factor ('GFactor')
added support for a regionwise factor for the parameter gammaLL. The total torque is now multiplied by this factor ('GFactor')
added support for a regionwise factor for the parameter gammaLL. The total torque is now multiplied by this factor ('GFactor')
changed the zhangli to use the user-defined gammaLL and not the constant gamma0. This was a bug, that causes a wrong calculation of the Zhang-Li torque in the cases that the user changes gammaLL.
|
That problem, I think, occurs because you haven’t recompiled the cuda files. Run “make realclean” and then “make” to force the recompilation of the cuda kernels. I hope that solves it!
J.
… On 31 Aug 2023, at 06:14, dzly1019 ***@***.***> wrote:
Please help me. After modifying the source code according to your method, it prompts two errors.
1../../cuda/lltorque.go:28:2: undefined: k_scalegamma_async
2../../cuda/temperature.go:16:25: too many arguments in call to k_settemperature2_async
../../cuda/zhangli.go:14:27: too many arguments in call to k_addzhanglitorque2_async
—
Reply to this email directly, view it on GitHub <#315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACI3WSGT3Y7MJOR2GYD7M4LXYAFSLANCNFSM6AAAAAARWKXNXY>.
You are receiving this because you authored the thread.
|
I have solved the problem, thank you very much! |
|
Thank you for your effort. For me, the test The erroneous output for me is: |
| @@ -4,7 +4,8 @@ | |||
| #include "stencil.h" | |||
| #include <stdint.h> | |||
|
|
|||
| #define PREFACTOR ((MUB) / (2 * QE * GAMMA0)) | |||
| // #define PREFACTOR ((MUB) / (2 * QE * GAMMA0)) | |||
| #define PREFACTOR ((HBAR) / (2 * QE)) | |||
There was a problem hiding this comment.
Is this new calculation of PREFACTOR correct?
The only place where PREFACTOR is used is a bit further in this file, where it is now divided by g. As far as I understand it, g should be 1 by default, so should PREFACTOR then not stay the same?
The previous factor MUB/GAMMA0 == 5.27082077425405e-35 but the new factor HBAR == 1.05457173e-34.
There was a problem hiding this comment.
Hi Jonathan,
I think you're right... The only place where this PREFACTOR is used is on line ~41, which is changed
(-) float b = invMs * PREFACTOR / (1.0f + xi*xi);
(+) float b = invMs * PREFACTOR / (g*(1.0f + xi*xi));
So, the new value of PREFACTOR should be the old one times the default value of g (which is 1.), and not twice its value.
I think the problem came about because initially (and in the code I use) I defined g as the physical Landé g-factor (=2.00 by default) and removed the parameter GammaLL. In this case, the new PREFACTOR should indeed be twice the old value. This definition makes much more sense, as g would be the physical well-known g-factor, but breaks the backwards compatibility in scripts that use the parameter GammaLL. I think I might have mixed the files when uploading this change, and I'm surprised it wasn't caught in the validation tests...
~~ João
This commit implements a regionwise gyromagnetic factor (gammaLL). For backwards-compatibility reasons, this is done with an additional user-accessible parameter, GFactor (default value 1.0). The material's gyromagnetic factor is then the product of the global parameter gammaLL and the region-wise parameter GFactor.
Additionally, a bug was corrected in the calculation of the Zhang-Li torque. Previously, cuda/zhangli.cu used a hard-wired value of gamma (defined in cuda/constants.h), which leads to a wrong calculation in simulations where the user changes the value of GammaLL.
Further improvements
It would perhaps be more elegant to leave only a single parameter user accessible (the region-wise one). But GammaLL is used internally by Mumax3 to normalise the timestep, and so a global parameter with a value of the order of 1.76e11 is required, even if it could be hidden from the user. The solution could be to set gammaLL to mu_B/hbar=0.879e11 and use GFactor as the Landé g-factor (default value 2.0), but this would not be backwards compatible.
Modifications