Moving simulation window for domain wall motion#161
Conversation
78d0487 to
3e53820
Compare
ilateur
left a comment
There was a problem hiding this comment.
Sorry for the long review, but I hope it's useful and clear.
I have some general concerns as well:
- Edge charge compensation seems fairly important to a moving window. I think it should be within the same update, although not within the same pull request.
- I think there should be an example using the moving window, along with an explanation of the current restrictions (preferably on the website too).
- Don't forget to add the Window class to the documentation, via
docs/api.rstI believe. world.center_domain_wallis now something you call once and it is then permanently enabled right? Should there be a way to disable this again? (It would also need something likeClearPostSteps()from mumax3 then.)
| raise RuntimeError("The moving window functionality only works if exactly 1 magnet exists.") | ||
|
|
||
| magnet = list(self.magnets.values())[0] | ||
| if not np.any(magnet.geometry) or np.any(magnet.regions): |
There was a problem hiding this comment.
I think this if-statement is incorrect. "not any geometry" tests whether or not the geometry is completely empty (which should never be the case). I believe not np.all(magnet.geometry) would be the correct check.
This PR is already in the making 😊 .
Yes.
It seems I keep forgetting this.
Very fair. On it! |
This pull request adds the possibility for a moving simulation window, albeit not very general. The functionality is implemented for
The code base is kept general as to easily extend it to other cases (e.g. 2D skyrmion motion) in later PRs. The (ancient) implementation on the
moving-windowbranch already contains some groundwork for a more general implementation, in the case we or the community would need this in the future.