[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] SolidTides Performance



Hi Hank,

Welcome to Orekit.

On Wed 23 Oct 2013 10:16:35 PM EDT, Hank Grabowski wrote:
>
> I'm a bit new to the Orekit development community but have been using
> it in varying capacities for a couple of years. I noticed the
> comment, "As this is a force model used within a numerical propagator
> and numerical propagators are not thead-safe (and will almost
> certainly never be), it is not a big deal to remove it." Is there a
> particular design reason why these will never be thread safe or is
> that an artifact of other higher priority items preempting that
> development. If the latter, would you be interested in an outside
> developer attempting to accomplish this and contribute it back?
>

I was interested in this a while ago so I looked in to it breifly. It
looks like thread safe propagators would require significant changes to
the underlying integrator and interpolator in Commons-Math. Luc know all
the details so he can better answer the question.

We are always appreciative of contributions. :) Before spending a lot of
effort on it you may want to consider if a thread safe builder would
satisfy your use case. In my application I've been sharing
NumericalPropagatorBuilder between threads and then just creating a new
instance for each propagation. This just duplicates the propagator state
(which is necessary) and shares the data hungry force models between
threads. I think all the force models are currently thread safe, but
that needs confirmation.

Best Regards,
Evan

>
>
> On Wed, Oct 23, 2013 at 10:38 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr
> <mailto:luc.maisonobe@c-s.fr>> wrote:
>
> Evan Ward <evan.ward@nrl.navy.mil <mailto:evan.ward@nrl.navy.mil>>
> a écrit :
>
> Hi,
>
>
> Hi Evan,
>
>
>
> I noticed 7dd5403 made a big improvement (2x!) in performance of
> SolidTides.
>
>
> You are always really fast to notice this sort of things!
>
>
> Since the class was also made thread safe I quickly checked
> its performance with multiple threads using it at the same
> time. For
> evaluating the tides field in SolidTidesTest 100000 times I
> got these
> results:
>
> single thread 1.3 s
> many threads 72 s
>
>
> Thanks for checking. This is odd, and should be improved.
>
>
>
> I think the big slow down with many threads comes from the
> layer of
> caching and locking implemented in TidesField. If concurrent
> performance
> is important for SolidTides then one solution is to eliminate
> contention
> for that cache by letting the user handle it explicitly.
>
>
> I am not really sure concurrency is really important for solid
> tides. Having them becoming thread safe was a side effect of
> setting up the cache. If it is too costly, we can remove it. As
> this is a force model used within a numerical propagator and
> numerical propagators are not thead-safe (and will almost
> certainly never be), it is not a big deal to remove it.
>
>
> Something like:
>
> interface HarmonicsProvider {
>
> Harmonics onDate(AbsoluteDate date);
>
> }
>
> interface Harmonics {
>
> double getSnm(int n, int m);
> double getCnm(int n, int m);
>
> }
>
> Constant Providers could return the same immutable Harmonics
> each time,
> while time dependent providers could return a new object with the
> precomputed coefficients for that date. Its use would look like:
>
> HarmonicsProvider provider = ...;
> //precompute coefficients for given date
> Harmonics harmonics = provider.onDate(date);
> //use in evaluation loop
> double cnm = harmonics.getCnm(m,n);
>
> Explicit in these interfaces is the assumption that if the
> user wants
> one coefficient on a particular date then the user will want all
> coefficients on that date. TidesField would still have to use
> a TSC for
> the interpolation points, but no caching/locking would be
> needed for the
> evaluation points.
>
> What do you think? I'm open to other ideas too. :)
>
>
> I like this a lot! It is an elegant and simple solution. I am
> ashamed not to have thought about it before. Thanks a lot.
>
> Do you want to give it a try yourself or should I do it?
>
> The current implementation of solid tides is usable and got some
> validation, but it is not completely finished yet. It needs some
> polishing and adding a few effects. Did you have the opportunity
> to chek it against some other reference results yet?
>
> best regards,
> Luc
>
>
> Best Regards,
> Evan
>
>
>
>
>
> ------------------------------__------------------------------__----
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
>
>
> -- 
> Hank Grabowski
> Chief Technology Officer
>
> 10440 Little Patuxent Parkway, Suite 600
>
> Columbia, MD 21044____
>
> (410) 715-0005 Office____
>
> (410) 715-0008 Fax____
>
> (301) 525-6219 Mobile____
>
> hank@applieddefense.com <mailto:hank@applieddefense.com>____
>
> www.AppliedDefense.com <http://www.applieddefense.com/>