You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When helping someone in the mumax forums, it seems there's been a slight change in behavior in how exchange works at the boundary between a ferromagnetic and nonmagnetic region, for mumax3.10. If you run the attached script1 ( script1.txt ), it ends with a state that looks like:
This seems to be because the user set Aex to a nonzero value, despite setting Msat to 0. If you set Aex in region 1 to 0, it gives the appropriate result (attached as script 2 script2.txt ). Similarly, if you also set m in region 1 to uniform(0,0,0) (attached script 3 script3.txt ) it also gives the correct result:
This can be fixed in other ways, such as using setgeom, or defining a second region for the other half and using ext_interexchange to set it to 0. (I did mess around with things like the seed, and it is repeatable, so I don't believe this is an issue with math being not deterministic or anything)
However, this is different from previous versions. In previous mumax versions (i tested with 3.9.3), setting M_sat to 0 as script1 does is sufficient to get the appropriate behavior. This is likely due to the change from a harmonic mean at the boundaries, to an arithmetic mean (from #236) or when exchange was set to use 1/msat per cell here 6303d01)?
I'm not sure if this would qualify as a 'bug', or need changing, but since it does technically change behavior from older mumax versions, so I figured it was worth documenting somewhere (since previous forum posts say that setting MSat to 0 was sufficient. This was true for 3.9.3, but is no longer the case). This probably doesn't come up often much, and it's fine as long as the user knows to zero out Aex and m for the nonmagnetic region.
It is a bit curious that anything happens at all, given that Eqn 9 from "Design and verification of mumax3" is not well defined when one material has an Msat of 0, though.
Best regards,
Josh L.
The text was updated successfully, but these errors were encountered:
Hi,
When helping someone in the mumax forums, it seems there's been a slight change in behavior in how exchange works at the boundary between a ferromagnetic and nonmagnetic region, for mumax3.10. If you run the attached script1 ( script1.txt ), it ends with a state that looks like:
This seems to be because the user set Aex to a nonzero value, despite setting Msat to 0. If you set Aex in region 1 to 0, it gives the appropriate result (attached as script 2 script2.txt ). Similarly, if you also set m in region 1 to uniform(0,0,0) (attached script 3 script3.txt ) it also gives the correct result:
This can be fixed in other ways, such as using setgeom, or defining a second region for the other half and using ext_interexchange to set it to 0. (I did mess around with things like the seed, and it is repeatable, so I don't believe this is an issue with math being not deterministic or anything)
However, this is different from previous versions. In previous mumax versions (i tested with 3.9.3), setting M_sat to 0 as script1 does is sufficient to get the appropriate behavior. This is likely due to the change from a harmonic mean at the boundaries, to an arithmetic mean (from #236) or when exchange was set to use 1/msat per cell here 6303d01)?
I'm not sure if this would qualify as a 'bug', or need changing, but since it does technically change behavior from older mumax versions, so I figured it was worth documenting somewhere (since previous forum posts say that setting MSat to 0 was sufficient. This was true for 3.9.3, but is no longer the case). This probably doesn't come up often much, and it's fine as long as the user knows to zero out Aex and m for the nonmagnetic region.
It is a bit curious that anything happens at all, given that Eqn 9 from "Design and verification of mumax3" is not well defined when one material has an Msat of 0, though.
Best regards,
Josh L.
The text was updated successfully, but these errors were encountered: