[Isocops] [Isocdev] Killex code change

DeMajistre, Bob Bob.DeMajistre at jhuapl.edu
Fri Jun 25 10:36:27 EDT 2010


Nothing like an illustration. If you look at the flux_hs file for orbit 79 ( o0079-hd60.hide-trp-flux_hs.txt ), for ESA  2 you’ll see
(note that I’ve copied the headers at the to so you know what the columns are).

 #file      ra       dec   energy        flux    variance expos(s) counts
#
 0001  +41.597   -0.360 0.634083 2.53869e+02 1.08567e+04 135.0550   22.0
 0001  +47.956   -0.363 0.626198 1.87338e+02 1.30056e+04 136.3770   16.0
 0001  +54.356   -0.365 0.619281 1.49282e+02 3.45591e+03 136.0940   23.0
 0001  +60.790   -0.366 0.613407 2.78165e+02 9.21066e+03 135.0830   21.0
 0001  +67.255   -0.368 0.608642 2.23073e+02 1.02949e+04 135.0010   20.0

These are the directions, energies and fluxes in the heliosphere system, shifted from a 6 degree grid in the spacecraft frame. Again, flux_calculate takes this data and puts it on a regular grid in angle and energy. Right now, we only need to worry about the angular regrid. The code first sets out a 2 degree grid starting at 1d (1,3,5,7,9 ...) and then for each grid point calculates the distance weighted average of all the measured points within ogrid_delta. So when ogrid_delta=3, the output corresponding to the above input is

 0001  +41.000   -0.360 0.634083 2.53869e+02 1.08567e+04 135.0550   22.0   1
 0001  +43.000   -0.360 0.634083 2.53869e+02 1.08567e+04 135.0550   22.0   1
 0001  +45.000   -0.363 0.626198 1.87338e+02 1.30056e+04 136.3770   16.0   1
 0001  +47.000   -0.363 0.626198 1.87338e+02 1.30056e+04 136.3770   16.0   1
 0001  +49.000   -0.363 0.626198 1.87338e+02 1.30056e+04 136.3770   16.0   1
 0001  +53.000   -0.365 0.619281 1.49282e+02 3.45591e+03 136.0940   23.0   1
 0001  +55.000   -0.365 0.619281 1.49282e+02 3.45591e+03 136.0940   23.0   1
 0001  +57.000   -0.365 0.619281 1.49282e+02 3.45591e+03 136.0940   23.0   1

The final number here is the number of input points that have been used to generate each record. Look, for example at the record for 43.000, it’s basically a copy of the input record at 41.597.  This is the only point that lies within 3 degrees of 43. The important thing to note is that THERE IS NO RECORD at 51 degrees. Setting ogrid_delta=3.5 gives

 0001  +41.000   -0.360 0.634083 2.53869e+02 1.08567e+04 135.0550   22.0   1
 0001  +43.000   -0.360 0.634083 2.53869e+02 1.08567e+04 135.0550   22.0   1
 0001  +45.000   -0.361 0.630266 2.21659e+02 1.18631e+04 135.7160   19.0   2
 0001  +47.000   -0.363 0.626198 1.87338e+02 1.30056e+04 136.3770   16.0   1
 0001  +49.000   -0.363 0.626198 1.87338e+02 1.30056e+04 136.3770   16.0   1
 0001  +51.000   -0.364 0.620830 1.57802e+02 4.18957e+03 136.2355   19.5   2
 0001  +53.000   -0.365 0.619281 1.49282e+02 3.45591e+03 136.0940   23.0   1
 0001  +55.000   -0.365 0.619281 1.49282e+02 3.45591e+03 136.0940   23.0   1
 0001  +57.000   -0.365 0.619281 1.49282e+02 3.45591e+03 136.0940   23.0   1

Which eliminates the hole. In addition, you’ll see that the points at 45 and 51 degrees are now the average of 2 input points instead of just copies of a single point.

After this, the energy regridding comes through and sets out a 6 degree grid, and then takes all the points within monoe_delta (default is 3d) to do the energy gridding. With ogrid_delta=3, the hole at 51 degrees introduces a hole in the energy grid, so when killex is set, the final cg record looks like

 0001  +45.000   -0.124 0.710000 1.57143e+02 5.35023e+03 135.0550   16.0   6
 0001  +51.000   -0.124 0.710000 0.00000e+00 0.00000e+00 136.0940   23.0   5
 0001  +57.000   -0.124 0.710000 1.17198e+02 1.43525e+03 136.0940   17.0   5

The flux is zeroed because no ESA 2 point went into the calculation. If killex were not set, the flux at 51d would be extrapolated from ESAs 3 and 4. Setting ogrid_delta to 3.5, the final record is

 0001  +45.000   -0.124 0.710000 1.79473e+02 4.78719e+03 135.0550   19.0   6
 0001  +51.000   -0.124 0.710000 1.49654e+02 2.22923e+03 136.0940   19.5   6
 0001  +57.000   -0.124 0.710000 1.17198e+02 1.43525e+03 135.5885   17.0   6

I haven’t reproduced the math in detail, but for those looking for “fine spatial structure” in the flux_cg data, the double averaging used by flux_calculate looks like a lot like a triangular smooth (regardless of the selection of ogrid_delta).  Because of this, I believe that the spatial resolution of the monoenergetic maps is somewhat courser than the instrument spatial resolution.

Probably more than you asked for.
Bob

On 6/24/10 10:51 PM, "Nathan Schwadron" <nschwadron at me.com> wrote:

Hi Bob

Can you explain what ogrid_delta is? If so, please send to isoc_dev group. At the moment I am struggling to understand such a difference between ogrod_delta = 3 and 3.5.

Cheers

Nathan

On Jun 24, 2010, at 6:34 PM, DeMajistre, Bob wrote:

I’ve gone through a close look at the results my changes to flux_calculate. I’ve been able to delude myself into believing everything is working with the changes in place. I’ve run all orbits through 79 with the new code and compared it to the old results. Comparisons are in my the monoe subdirectory of my work directory (/usr/local/ibex/work/bdemajistre/monoe).
monoe_change_orbits.ps
monoe_change_skymaps.ps

Here you’ll see three cases, the old stuff, the new stuff with the option “ogrid_delta=3” and “ogrid_delta=3.5”. My recommendation is that for future work, we use the killex option (the one I just implemented and is now the default) with “ogrid_delta=3.5”.  A more detailed description of what is going on here is below.

There will be small changes to the skymaps. In particular, a careful observer my have noticed a horizontal strip in the ESA 2 mono-energetic maps. This is a processing artifact that the new version fixes.

Please let your eyes rest lightly on these results.  I’ll take comments until COB Monday. By then if there is no objection, I will

 1.  commit the changes
 2.  replace the flux_cg.txt files in the id-base/sofest area with the reprocessed data
 3.  change the test sets for flux_calculate

I can also change the default value of ogrid_delta, but I’d like user comments before I do so.
I’ve attached some notes I took while spelunking that might be of use to some of you.

Now, the details. The path through flux_calculate that I’ve monkeyed with reads the flux_hs files, which are fluxes in the heliospheric system (moving WRT to IBEX) where the energies and directions reflect the change in reference frame. The code places these fluxes on a regular grid in both angle and energy.

The angular regridding precedes the energy regridding. The flux_hs files that I have been working with have been generated with the 6 degree cull, so the angular grid points slop around that 6 degree grid. Flux_calculate sets out a 2 degree grid, and then takes a weighted average of all the points within ogrid_delta of each gridpoint. With ogrid_delta=3, there are systematic cases where gridpoints are dropped, i.e., there are places where there is no data within 3 degrees of a given gridpoint. Bumping this up to 3.5 degrees seems to remove these holes for IBEX HI (all bets are off when it comes to LO). HOWEVER, with a 3 degree delta, you almost always have no more than one point on the old grid mapping to the new grid. At 3.5, though, there are some places where there are 2 points averaged together to build a given gridpoint. I don’t think this is a problem, but you should know about it if you’re looking at things carefully.

For the energy gridding, flux_calculate basically loops through each point on the ESA 6 angular grid, and finds all the points at the same angle at the other energies. It then does an interpolation of the old energies to the new energies. The old code, and the current code without killex, doesn’t really care how many points were actually on the old grid, so if data from  an ESA is absent, it would just fill in the hole with an interpolation.  For example, as is the case for orbit 79, if ESA 2 has been cut out by the cull, a flux at ESA 2 energy is extrapolated from the existing energies – this resulted in some pretty long extrapolations and introduces spikes in the data. Under killex, if there is no point with an energy near where your interpolating to, the fluxes and variances are zeroed. Near here is defined as “within the maximum velocity correction for that particular energy”.

In addition, using killex exposed the holes introduced by the ogrid_delta=3 setting. Because of the energy shift, there are systematic places in ESAs 2 and 3 where holes are introduced by ogrid_delta=3.  For example, at NEP=51 degrees, the grid almost all the ESA 2 points are eliminated. In this case, without killex set, a value for ESA 2 energy is manufactured from ESAs 3 and 4, which introduces a visible spike at 51 degrees. With killex set, fluxes (and variances) are zeroed instead. With killex set and ogrid_delta=3.5, the hole doesn’t exist and the spike disappears.

Comments on the change or the results are welcome. Again, unless I hear otherwise, I’ll assume approval at COB on Monday.

Bob

<monoe_nolongex_notes.txt>
Please restrict discussions on this email list to non-ITAR sensitive topics.
_______________________________________________
Isocdev mailing list
Isocdev at lists.sr.unh.edu
http://lists.sr.unh.edu/mailman/listinfo/isocdev

Please restrict discussions on this email list to non-ITAR sensitive topics.
______________________________________________
Isocops mailing list
Isocops at lists.sr.unh.edu
http://lists.sr.unh.edu/mailman/listinfo/isocops


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sr.unh.edu/mailman/private/isocops/attachments/20100625/248a7e7f/attachment.html 
-------------- next part --------------

Please restrict discussions on this email list to non-ITAR sensitive topics.
_______________________________________________
Isocdev mailing list
Isocdev at lists.sr.unh.edu
http://lists.sr.unh.edu/mailman/listinfo/isocdev


More information about the Isocops mailing list