Custom Effects and Parameters

[Rmelikyan]

Hi Dan,

I have a question about designing/implementing custom effects; especially in regards to potentially "shared" parameters.

Section 6.2 (Adding Parameters) says:

You cannot use particle parameter names that are in use by other effects, so search first for the name you are planning to add.

What does this mean for the multiple Speed of Light (C) values that your GR and Radiation forces are using. For example, if I were to add both GR and the Radiation Forces effects to a simulation, would you have to assign the C parameter for each force separately?

I have potentially three overlapping forces which I want to include in my simulations all of which would reference a particles spin period and obliquity. The software development side of me want's to define each of my forces separately so that other users (or even myself) can pick and choose what forces to include etc...

I might find it more convenient to throw the three forces into one function however if it means simplifying the referencing of parameters.

How difficult would it be for separate forces to share particle parameters?

Thanks by the way for the very thoughtful documentation on adding new forces!

Best,

-Robert

[dtamayo]

Hi Robert,

You're most welcome, glad you're finding it helpful! I also talked with Hanno about this, and it's not clear what the best solution is. We ended up concluding that it's probably better to end up with something more flexible even if it's slightly less convenient. I agree there should only be one speed of light in the universe, but sometimes we like to cheat. Here's an artificial example: some codes split up radiation forces into a radiation pressure piece that acts radially, and a Poynting-Robertson drag piece that acts along the particle's velocity. REBOUNDx just adds them both together, but say you implemented separate forces for each. Now we agree there's one speed of light, but sometimes we like to cheat. Often the Poynting-Robertson timescale is so much slower than the other timescales, that you can get away with speeding it up and you run your integrations faster. But how do you do that? The particle has one particle radius. So you could implement a separate beta (radiation/gravitational force ratio) parameter for each effect, or you could set the speed of light to different values for each, with the PR one speeding things up. I think you can find many other examples like this (maybe we want to inflate the radius used to calculate tides, but use a different radius for collisions).

So I think the better approach is to ask the user to set the speed of light (and all its parameters) multiple times for each force if they overlap. With new forces we've started adding a prefix to all parameters with the initials of the force name, e.g. tides_constant_time_lag -> tctl_R, tctl_tau for each of the parameters. Setting the same parameter more than once is only a copy paste and modify, so I don't think it's a big deal, while the flexibility to assign different values for different effects can be quite useful.

I agree with you that it makes more sense for many reasons to implement them as separate effects. I would just duplicate their shared parameters. Hope that helps

[Rmelikyan]

Thanks for the quick and detailed response!

I think I've come to see the (speed of) light of what you're saying and I agree with your argument. I think even as I was developing my question, I was imagining cases where the flexibility could be really useful (otherwise I'm sure you could have easily calculated speed of light for any given G without user input)

Other than the copy and pasting... Seems to be no other downside to keeping each force separate. (the additional memory I'm assuming would be negligible here?) You've convinced me to develop each piece separately.

Wish me luck on these custom effects... I hope they'll prove a valuable contribution to this codebase!

Thanks! -Robert