[Kstars-devel] [SoC] Memory limits for extended catalogs

[James Bowlin]

On Fri June 27 2008, Akarsh Simha wrote:
> >     6 * ceiling( MSpT / stars_per_block)
>
> Mesh level is fine. Do we still need MSpT, considering that we are
> not doing double buffering? I can't see how the total number of SBs
> will ever exceed 6 * ceil( MSpT / stars_per_block ).

The total number of StarBlocks can vastly exceed that limit if the star
density is set high enough.  If there is no limit on the star density
then when fully zoomed out, someone could use up enough StarBlocks to 
hold more than half of the entire catalog.

> > From this we can figure out the proper star density setting.  For
> > example, if the brightest dynamic star is mag m_0, and we have
> > agreed to not make more than N_blocks StarBlocks then we know that
> > the maglim can't be greater than m_0 when there are more than
> > N_blocks trixel visible.
>
> Ok. You're planning to change the memory usage slider that currently
> uses arbitrary units to use StarBlocks.

I took a quick look at the code.  It is not at all clear to me what the
Options::memUsage() is actually doing in the StarComponent code.  ISTM
that the star density control (currently called magLimitDrawStarZoomOut)
already provides an uncalibrated way for users to control the memory
usage.

> > But maybe this is getting too complicated and we should instead
> > just put a simple limit on the star density.  Still, the reasoning
> > above could help us come up with a formula relating the star
> > density setting to the maximum number of StarBlocks needed.
>
> Would it be worth the while to derive this relationship numerically?
> I'm satisfied with the arbitrary memory units that we use now, but I
> wouldn't mind adding more sense to that.

I'm willing to let this aspect of the memory control slide for now.
But if I increase the star density to the max, I can easily use 195 Meg 
for star storage according to the "B" key printout.  ISTM that we would 
want to allow users to impose a limit on the maximum star density so 
they don't end up needlessly chewing up 200M.  

IMO, by default we shouldn't let users go all the way up to these high 
densities.  There should be some sort of safety they have to unlatch in 
order to get the really high star densities.  The simplest way to do 
this is to put an adjustable limit on the maximum star density and 
maybe that's all we need to do for now.  

The problem with only doing that is that there is no simple way for
users to translate the limit on star density to how much memory will
be required.

The sticking point is the formula that relates the number of visible 
trixels to the size of the aperture.  I've already sent you a formula 
that gives the maximum on the number of trixels for a given aperture 
size.  The problem is that the maximum is much larger than the average 
because there is a lot of variation in the size of the trixels.   The
maximum number of trixels can be three times the average!  If we want to 
give the users a rough rule of thumb, the *average* number of trixels 
for a given aperture size might be more useful than the maximum.

There is also the further complication that the density of stars varies
so the amount of storage needed for a fixed aperture size will also 
vary.

I could try to work out the formulas if you want.  But it might be 
better to determine the formulas experimentally by recording in a log 
file the following:

  aperture size, number of trixels, mag limit, star blocks used

for every draw cycle, then make some scatter plots using this data
to determine what the actual relationships are.

Here are the formulas for working out the average number of trixels
for a given aperture:

                 Mesh size:  M
   Total Number of trixels:  T = 8 * 4^M
    Average area of trixel:  A_avg = 4 * pi / T

You can then use the area of an aperture to get a rough estimate of the 
number of trixels that will be are needed to cover that aperture.  If 
we are zoomed in and can use this simple formula for the area of an 
aperture of radius R:

   area = pi * R^2

then the area of the covering trixels will be between:

   pi * R^2 < area_of_trixels < pi * ( R + L_max)^2

where L_max is the maximum length of a side of a trixel and is equal to:

  L_max = pi^2 / (4 * 2^M) 

The inequality above is true because all of the covering trixels will 
fit within a circle of radius (R + L_max).


-- 
Peace, James