Skip to content

(draft) Feature: Time Quantity#397

Draft
jplauzie wants to merge 3 commits intomumax:devfrom
jplauzie:Time_Quantity
Draft

(draft) Feature: Time Quantity#397
jplauzie wants to merge 3 commits intomumax:devfrom
jplauzie:Time_Quantity

Conversation

@jplauzie
Copy link
Copy Markdown
Contributor

Hi,

This is a first stab at adding the time varying custom Quantities functionality I mentioned in #384. It's split into 3 PRs for easier review, but they're intended to be used together. Sorry for not lumping it in with the other changes, I expected this to take longer. This should be the last PR for a bit on mumax3, I know I've dumped a lot on you all at once. 😅 As always, feel free to decline/request changes/take your time reviewing etc.

Combined with CustomQuantities #384 , this should allow a user to build Quantities that are both spatially and time dependent. Currently, mumax3 is limited to separable functions f(x,y,z) * g(t). This should allow for functions that can't be separated like e.g. a Gaussian wave packet e^((x-v*t)^2/ (2 * sigma)). This PR adds 2 things:

  1. A wrapper that promotes the Time variable into a Quantity. This Quantity automatically updates as the Time changes. I actually found two different implementations: One uses the existing NewVectorField/NewScalarField functions, and one uses a little struct wrapper similar to CustomQuantities. As far as I can tell, they're essentially equivalent - Do you have a preference?

  2. For convenience, there are 2 new functions ScalarFuncQ and VectorFuncQ. This allows the user to give a function input (e.g. "VectorFuncQ(sin(t), 0, cos(t))"). This is mostly redundant with the other functionality in these PRs, so I'm not sure if it's worth including. The 2 potential benefits:

  • You can do something like 0.1sin(wt) in one shot and it saves you some kernel calls instead of having to do something like Mul(Const(0.1), Qsin( Mul(w,t))). In testing, it does seem to be noticeably faster than the equivalent individual kernel calls, but takes a hit if you add it to the table (because then it pulls the data back off the GPU). With the table overhead it was ~equivalent speed wise.
  • Strictly speaking, just doing t is a valid function of g(t), so maybe 1) should just be a subset of this instead of being it's own Quantity?

Included is a test file. To compare, I tested it against mumax's built in B_ext.add(), comparing sin(kx-wt) to the (using trig identities, sin(kx-wt)=sin(kx)cos(wt)-cos(kx)sin(wt) ) separable version. It seems to match well. The test file requires Custom Quantities, this Time Quantity, and the unary math kernels in the 2nd PR to run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant