Re: [Orekit Developers] SolidTides Performance

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Evan Ward <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.