ipsdhtd ucsd=SANIPS,$dat/ucsd/ helios1=a77b4_073_"(4)".hos,$dat/helios1/ helios2=b77b4_073_"(4)".hos,$dat/helios2/ ./ipsdhtd77 ucsd=SANIPS,./ helios1=a77b4_073_"(4)".hos,./ helios2=b77b4_073_"(4)".hos,./ Revisions: On the week of 03/08/01 I began modifying ipsdtestR using mk_ipsdtestR. Stuff before: On about 11/15/00 I discovered an error in the the way scratch arrays were zeroed. I modified the IPSDTDV2020NN.f program to use the above programs with scratch arrays placed in the calling sequence. When I did this I noticed that the scratch arrays originally used were not dimensioned properly for the 2020 program. The scratch arrays zeroed at the beginning of the program were not fully zeroed, and this was an error. When this was done properly,the 2020 program no longer converged with few holes - there were a lot of holes in both velocity and density and the results that I had come to like and agree with were no longer correct. I presume that the increased number of line of sight crossings from non-zeroed arrays were partially responsible for the previous OK results (That always seemed to be consistantly the same for any given Carrington map.) I consequently got the idea to filter the weights and the number of line of sight crossings in both time and space so that these are more consistent for only a few lines of sight in a way similar to the answers. Thus the weights and the numbers of line crossings are now smoothed spatially and temporally with the same filters as the answers. This seems to work wonderfully, and allows the line of sight crossing numbers to be placed lower than before - to as low as 1.5. At 1.5 most of the Carrington map is filled and the program proceeds to convergence (on Carrington Map 1965) pretty well. At 11/16/00, the comparisons with in-situ work almost as well as before, but time will tell. In an additional change on 11/15/00, I modified mkvmaptdN.for and MKDMAPTDN.for to increase the effective number of line of sight crossings by sqrt(1/cos(latitude)) This allows the acceptance of a lower number of line of sight crossings near the poles since the spatial filtering is greater there. This also seems to work. On 11/15/00 I also modified fillmaptN.for and copyvtovdN.for to accept scratch arrays through the calling sequence. IPSDTDV2020NN.f also needs to be modified to accept these subroutines with their new calling sequences. The convergence with the above modifications (11/16/00) seemed pretty ragged until sources were thrown out after which the convergence proceeded in a very stable fashion. The peak in density at 7/15 was absent in the density data, and this may be because of thrown sources. On 11/16/00 I then also smoothed FIXM spatially and temporally in both mkvmaptdN.for and MKDMAPTDN.for. This also converged in a ragged fashon even after the thrown sources and in the end did not write the 3 D arrays I asked - maybe memory was clobbered. The program did converge. however. The in-situ time series was not at all like the model!!! On 11/16/00 I then changed back to earlier convergence scheme where the FIXM is not smoothed. The 3 D arrays still are not being written out. On 11/16/00 I noticed that the mkvmodeltd.for routine was not as on the vax [.ipsd2020.normn}subdirectory, but was an older version. I re-wrote the newer version (which does not need a scratch file) and replaced mkvmodeltd.for with the newer version. I also checked to see that the MKGMODELTDN.for subroutine was unchanged from the vax and I revised it so that it passes two scratch arrays through its calling sequence. The newer version with iterates identically to the old version. There seems to be no change in the write3b status throughout the iterations indicating that nothing gets clobbered during the iterations. On 11/21/00 I fixed the fillwholet.for subroutine so that now there is now a scratch array is passed through its calling sequence so that the above error noticed on 11/16/00 was fixed. Things seem pretty much the same when I do this, and now the t3d files are output. On 11/21/00 I stopped using distributed weights, since the program NOT using distributed weights seems to converge as well as the program version that does use distributed weights. The EA answers are somewhat different, but not much. On 12/5/00 I found an error in the write3dinfotd1N.for subroutine in forecast mode. The subroutine seems to give two 3d files that are incorrectly labeled (and interpolated) because AnewI is wrong. I believe AnewI is wrong because the input N values are wrong in the forecast mode. The problem was in the use of XCintF where there was not an N+1 copy of the XCintGG array into the XCintF one in the main program. In the forecast mode this caused the bomb. However, I see that whatever reason that there was a forecast mode for the write3dinfotd1N.for routine, it does not exist any more. I have therefore eliminated the forecast mode for write3dinfotd1N.for in both the main program and in the subroutine so that now all that is needed is a single call to write3dinfotd1N.for. On 12/7/00 I found an error in the MKTIMESVD.for routine in that the NmidHR value was subtracted from the time to start the beginning day. In the main program, this value was labeled number of hours "before" midnight and was -10 for Nagoya. The main program now reads number of hours "from" midnight and is now -10 as before for Nagoya. UCSD is +8 or +9, as you know, depending on daylight savings time. The MKTIMESVD.for subroutine now adds this value to begin the day at midnight. This has the effect of changing all the extensions of the t3d files, since the temporal intervals now begin at a different time - midnight at Nagoya. If the t3d files are interpolated by 1 in write3dinfo1N.for, this now has the effect of dividing the day into times before midday in Nagoya and after midday in Nagoya. If the files are interpolated by 2 in write3dinfo1N.for, then the t3d files are divided (approximately) into midnight to 8am, 8am to 4pm and 4pm to midnight. The extension values have been checked by PL HE Pandora on the vax. On 12/7/00 I found that the forecast 51874 run, which terminates data at this time, or 12 UT on November 25 (355 sources found), gives the last matrix at 1970.064 (centered at 1970.0825 or 2 UT November 26). The forecast run at 51874.5 (0 UT November 26) (371 sources found) gives the last matrix at 1970.064 as well. Since this does not give even a one day 3d matrix advance forecast, I have now changed the value of NTV and NTG by one more so that the 3d matrix is written to a file for at least one day beyond the current time. On 12/7/00 I found that in the forecast runs there were as many sources used as there were source values within the NLG and NLV increments set by XCintG and XcintV. I fixed this in the main program so that now all the data that is used in the forecast mode comes from times that are less than the Carrington rotation of the Earth at the time given input as the forecast time. The current mk_ipsd2020NN uses the IPSDTDV2020NN.f main program. On 01/30/01 I copied all the programs of the mk_ipsd2020NN compilation over to the for/IPSd2020NN subdirectory so that this program and subroutine is now complete and seperate from the other fortran programs. On 01/30/01 I also began to alter the FIXMODELTDN.for and mkvmodeltd.for subroutines so that they better reproduce in-situ velocities. I have done this by copying all the files to the for/IPSd2020 subdirectory so that this program and subroutine is now complete and seperate from the other fortran programs. I renamed the IPSDTDV2020NN.f program to IPSD2020.for When I ran the program for 1965 in this subdirectory, the results for 16., 16., 0.25, 0.25 and 0.40 for the EA_FILE idl run_compareaceLp run was 0.771 and 0.066 and this is slightly different from before which was 0.688 and 0.058. I don't know why there is this slight difference. On 01/30/01 I began a lot of changes in mkvmodeltd.for in order to get better velocities into the matrix. I think the original (or perhaps the model 01/31/01B) is the correct one for weighting, but I tried a lot of things to see if there could be an improvement in the in-situ comparison. There was not a whole lot of difference when using the things I tried, below. C VPERP = VPERP + VWTij(J,I)*VSN*VELO ! Original C VWT = VWT + VWTij(J,I) C VWTi = VWTi + VWTij(J,I) C VWTij(J,I) = VWTij(J,I)*VSN ! Added B. Jackson 01/30/01 C VWT = VWT + VWTij(J,I) C VPERP = VPERP + VWTij(J,I)*VELO C VWTi = VWTi + VWTij(J,I) C VWTij(J,I) = VWTij(J,I)*VSN ! Old run long ago. C VPERP = VPERP + VWTij(J,I)*VSN*VELO ! 01/31/01A C VWT = VWT + VWTij(J,I)*VSN C VWTi = VWTi + VWTij(J,I)*VSN C VWTij(J,I) = VWTij(J,I)*VSN C VPERP = VPERP + VWTij(J,I)*VSN*VELO ! 01/31/01B Seemed ~best so far C VWT = VWT + VWTij(J,I) C VWTi = VWTi + VWTij(J,I)*VSN*VELO C VWTij(J,I) = VWTij(J,I)*VSN*VELO C VPERP = VPERP + VWTij(J,I)*VSN*VELO ! 02/01/01A C VWT = VWT + VWTij(J,I) C VWTi = VWTi + VWTij(J,I)/VSN C VWTij(J,I) = VWTij(J,I)/VSN C VPERP = VPERP + VWTij(J,I)*VSN*VELO ! 02/01/01B (Original) C VWT = VWT + VWTij(J,I) C VWTi = VWTi + VWTij(J,I) C VWTij(J,I) = VWTij(J,I) C VPERP = VPERP + SQRT(VWTij(J,I))*VSN*VELO ! 02/01/01C C VWT = VWT + SQRT(VWTij(J,I)) C VWTi = VWTi + SQRT(VWTij(J,I))*VSN*VELO C VWTij(J,I) = SQRT(VWTij(J,I))*VSN*VELO VPERP = VPERP + VWTij(J,I)*VSN*VELO ! 01/31/01B Seemed ~best so far VWT = VWT + VWTij(J,I) VWTi = VWTi + VWTij(J,I)*VSN*VELO VWTij(J,I) = VWTij(J,I)*VSN*VELO C VPERP = VPERP + (VWTij(J,I)**2)*VSN*VELO ! 02/02/01A C VWT = VWT + (VWTij(J,I)**2) C VWTi = VWTi + (VWTij(J,I)**2)*VSN*VELO C VWTij(J,I) = (VWTij(J,I)**2)*VSN*VELO VW = VWTij(J,I)*VSN*VELO ! 01/31/01B rewritten VPERP = VPERP + VW VWT = VWT + VWTij(J,I) VWTi = VWTi + VW VWTij(J,I) = VW Thus, I will settle on the version above. All other versions of the program should incoporate this weighting which essentially places all the line of sight variations into the weight. The nominal 16., 16., .65, .65, .25, .25, .4, run of 1965 gives 0.647546 and 0.229140 for the density and velocity correlations for the restricted data set and ACE in-situ measurements around the time of the July 14 CME peak. Other combinations of parameters give higher correlations, but none give the same density values in-situ/model with 16. and .65 as do these. The run of velocity deconvolution alone (2/12/01) does not allow the parameters to be set. This is now fixed in the main program (2/12/01). The version of the program that deconvolves velocity alone (both constant density and that uses mv^2 = constant) bombs in gridsphere with bad VMAP values before any iterations are gotten to. I have now fixed this and also fixed the problem when G-level alone is selected. The problem was in the setup for each initial velocity or density array. On 2/14/01 the velocity mv^2 works. On 2/14/01 the density mv^2 does NOT work to give velocity. Thus, I had better fix the Mk_D2V subroutine. On 2/15/01 I re-did a lot of the program to accomodate the modes that use a constant velocity and density and the mv^2 assumptions plus a write-out of the DMAPHOLE and VMAPHOLE data. These work now and have been checked using the routine to converge on both density and velocity, on velocity using constant density and on velocity using mv^2. The latest runs give the nominal using 16., 16., .65, .65, .25, .25, .4, for 1965 of 0.666897 and 0.417346. I think the "better" correlations may happen because fillwholeT is no longer double, but I am not sure of this. The correlations look considerably different now, too. Thus, to check I redefined using fillwholeT as before, and when I did this the nominal for 1965 looked the same as it has in the past in the iterative phase at least up to iteration 14 or so where the two began to diverge ever so slightly in the percentages, only. The correlations were: 0.647546 and 0.229140 which were identical to before. I thus returned the fillwholeT routines so that the times are no longer double-smoothed and I began a search for more "nominal" parameters. I also got a version of MK_DTV.FOR from the CASS01 fortran files and I renamed it MK_DTVN.for and compiled this version in the IPSd2020 subdirectory. The new version now works for mv^2 = constant for density iterations and gives approximately correct velocities. The new version also works for mv^2 = constant for velocity iterations and gives approximately correct densities. Oh, yes, another innovation is that the mv^2 = constant is now determined for each iteration with no convergence problems as far as I can tell. I now also determine the equatorial density and velocity (subroutines Deneq3.for and Veleq3.for so that the mv^2 = constant is now correctly applied to the other nominal value. In other words, the average speed at the solar equator is used to determine the mv^2 constant to produce density when speed is modeled. Likewise, the average density at the solar equator is used to determine the mv^2 constant when density is modeled. The nominal 16., 16., .65, .65, .25, .25, .4, for 1965 gives 0.666897 and 0.417346. Velocity convergence: Constant density and the nominal for 1965 above gives -0.123838 and 0.0811669 (The density above looks in the correct range, but it just is not constant. This is because the Mkshiftd rountine allows non-constant interactions to build up at height as long as velocities are non-constant.) Also, mv^2 density and the nominal for 1965 gives: -0.0242271 and 0.115706. End eq. vel = 334.436707 Density convergence: Constant velocity and the nominal for 1965 above gives 0.347806 and NaN Also, mv^2 velocity and the nominal for 1965 above gives 0.347806 and 0.318303. End eq. den = ? (Something goes wrong when this last is done in that the t3d file doesn't seem to write out OK. Also, it isn't clear why the correlation with velocity = constant and velocity with density given by mv^2 is does not give a different density correlation. Seems to me that it should.) On 2/16/01 I think I found the error at least in the last problem. The DMAP is not being updated each time the mv^2 is done. DMAP is consistently being held constant. Also VMAP is the same. Latest Revisions for the ipsdtestR program On 03/04/01 I ran the latest test program with spatial resolutions three time normal The test rotation was 1884. The run lasted about 1 day. Other things were running. On 03/08/01 the run ended where times and spatial resolutions were set to 2 times normal. The run lasted a day and a half for rotation 1884. On 03/07/01 I also ran a few tests with the program in 10 degree mode, and I updated the parameter list to make the changed resolution automatic with only a few changes in the parameter input. I also fixed the program so that it can (I hope) run with two different temporal resolutions - one for density and the other for velocity. In addition these new spatial resolutions now allow different line-of sight resolutions commensurate with the new spatial resolutions for either velocity or G-level. I will try this version of ipsdtestR today, 03/08/01. Later - The program runs, but the density fixmodel routine returns a "nan", as do all the other outputs of that subroutine. Somehow, the problem of a "nan" went away in the later compiled versions of the program, and so now on 03/09/01 I have a "working - so far" program using these new resolutions. The 10 deg. version in both V and g-level curently takes: g-level sources: 3851 (CR 1884) V sources: 703 memory 1x resolution in S & T V: 57,388 1x resolution in S & T g: 1x resolution in T V: 360,488 2x resolution in S V: 2x resolution in S & T g: g-level sources: 9265 (CR 1858) V sources: 652 1x resolution in S & T V: 69,756 1x resolution in S & T g: 1x resolution in T V: 388,396 2x resolution in S V: 2x resolution in S & T g: These tests imply that 3 degrees resolution with 6 Megs of sources (200 x 30,000) held in memory will take: 1.2 Gigs of ram per the program 55.6 Gigs of ram for the sources ~150 hr for 0.01 Megs of sources with a 850 MegHz machine At ONE degree resolution with 18 megs of sources (600 x 30,000) held in memory: 11.0 Gigs of ram per the program 678.0 Gigs of ram for the sources ~4000 hr for 0.01 Megs of sources with a 850 MegHz machine On 3/13/01 I began timing experiments. More experiments will continue when the new 1.2 GigHtz and 1.5 Gigs ram machine begins working. On 3/14/01 I wrote a subroutine writeM_Scomp.for that prints out files used to check sources if the user asks. For Cambridge data where no source names are available this program uses the sky location declination and the sky distance from the sun to give a unique source identifier for each 5-degree sky location. On 3/14/01 I also wrote a subroutine iwriteproxymapN.for that is the compliment of ireadproxymapN.for This subroutine writes out maps of the final source surface data to be used in the program as input on the first run of the program in order to help iteration convergence. I also modified ireadproxymapN.for so that now fillmap.for is no longer needed. I also removed a good many other unneeded lines of code that have previousluy been unnecessary. On 3/15/01 I modified the main program so that it no longer needs (but can if wanted) use two shifts on each iteration. The modification uses a shift only after the velocity is determined (a density-based shift) to set up for the density iteration. To do this, the velocity times and settings need to be the same as the density ones, and they are set this way if the user does not remember to set them this way. On 3/15/01, I checked the ipsdtestR.for program with the old version of the ipsd2020 program in the subdirectory IPSd2020 and found that they gave identical answers. I then renamed the IPSDtestR.for program to IPSTD.for and removed the IPSDtest.for program from the IPSdtest directory. On 3/15/01 I found that the two programs did not give identical answers and so I found the error in that the variables in the new program aNdayV and aNdayG were not typed real in the two subroutines MKGMAPTDN.for and mkvmaptdN.for and after these two problems were fixed (in the IPSHTD and IPSd1010 directories as well) the two versions gave identical outputs up until the t3dwrite for CR 1965 in both the new and old version of the program. The answers are still slightly different. The correlation for the limited time series is now 0.850 rather than 0.840. I do not understand this difference, but it is so slight that I plan to ignore it. On 3/19/01 I moved this program over to CASS183. This version of ipsdtestR.for has better inputs and outputs for files. I modified this program and mk_ipsdtestR so that it is now called simply ipsdtest on CASS183. There are now three versions of the ipsdtest program in this subdirectory. They are IPSDtest.for IPSD1010.for and ipsd2020.for and their associated mk_ipsd files, and these should be used to change and test new routines and ideas. ************************************************************************************************** The version of ipshtd on 3/30/01 now seems to work on CASS183. I am testing the two parameters in the current solar wind model that can be controlled specifically by the Helios data to change the model density. These parameters are the Base density and the density falloff with height. The current ipshtd version uses the following mk_ipshtd file: f77 -w -fdollar-ok -ffixed-line-length-none -I$for/h -I$for/h/linux ipshtd.for READVIPSN.for read_hosf.for FIXMODELTDN.for MK_D2VN.for timesmooth.for fillmaptN.for fillmapL.for fillwholet.for MKTIMESVD.for MKDMAPTDN.for MKGMODELTDN.for mkpostd.for mkshiftd.for mkvmaptdN.for mkvmodeltd.for mkvobstd.for get4dval.for get3dtval.for copyvtovdN.for MkDHModeltd.for Mk_Base.for EXTRACTD.for writeM_Scomp.for IREADPROXYMAPN.for iwriteproxymapN.for write3dinfotd1N.for deneq3.for veleq3.for -L$for -lgen -o$myfor/IPSHTD/ipshtd The original working program for ipsdtest was modified beginning on 3/19/01 to use helios photometer data. Several subroutines have been adapted or modified to use helios data, and the current program should incorporate all that the ipsdtest program could do with the IPS data as well as run Thomson scattering data. These subroutines include: ipsdtest.for renamed to ipshtd.for, now incorporates new subroutines: read_hosf.for MkDHModeltd.for Mk_Base.for These new subroutines allow a switch to use Thomson scattering data from Helios in the tomography program. These switches are input by the user, and include new setup calls to extract Helios 1 and Helios 2 photometer time series as well as the ips UCSD, Cambridge, Nagoya or Ooty data. Besides the ability to read the Helios data, the current main program changes from ipsdtest.for includes a section that sorts the Helios 1 and Helios 2 data in chronologic order, and a section that deals with the currently non-working initalization of the density maps if these are not read in from the /dat/proxy/ sub-directory. The iterative part of the program is pretty much as before with a small section added to incorporate the base density in the Thomson scattering data, and a new FALLOFF parameter that decreases the data density derived by the Thomson scattering above and beyond the mkshiftd model. The use of a base density meant that two new map arrays needed to be created in the main program, one DBASE, and another DMAPMB, which is the density map minus the base for use in the Thomson scattering tomography. The psychology behind this program is far simplier than the Vax version since once DMAPMB is produced by the tomography it is immediately added to DBASE to provide DMAP which is manipulated as in the previous versions of the ips tomography programs including ipsdtest.for. That a FALLOFF parameter is used implies that the velocity increases in the solar wind in the region of the Helios observations and between Helios and Earth. This is NOT currently taken into account in the UCSD IPS velocity data modeling. Because the UCSD IPSD data is currently used and 12 days combined to allow UCSD data to be "time-dependent", the calls to copyvtovdN.for in the program now incorporate aNdayV multiplying CONSTV, and aNdayG multiplying CONSTG. This should be incorporated in other programs, especially ipsd1010 as well - whenever there are times combined (aNday constants not equal to 1). At the end of the main program, the call to copyvtovdN.for now uses mode=1 (unlike the mode=2 call in the other versions of the program). This mode currently limits the data combined at the new data temporal cadence to be cut off at times 1.5 intervals from the current time. This should probably be changed in the program copyvtovdN.for so that the cutoff is at times 1.5 intervals from the current time for the input (rather than output) maps. read_hosf.for, which was originally read_hos0.for, now reads the Helios 15 30 and 90 degree data and also outputs the photometer and sector identifiers. These changes took the most work and included help from Paul Hick to adapt the routines read_hosf.for calls to read the vax-produced binary files edited by the vax SHPLT. MkDHModeltd.for is similar to the one used in the vax program, but a lot of work went into figuring the best weights for Thomson scattering. The scheme to make the model brightnesses was not changed, although this was considered and the weights provided by the MkLOSWeights subroutine was not thoroughly researched (yet). The MkLOSWeights subroutine should now include a pwr parameter in its calling sequence in the library that is not used in the Thomson-scattering weights, but only in the IPS weights. The MkDHModeltd.for subroutine is considerably different from the Vax version. Finally settled on so far (3/30/01) is a brightness given by: DTW = DENj*WTS2(J,I) AM = AM + DTW and weights given by: GWTij(J,I) = DTW The above scheme is very simple, and fixes to the initial density are simply linear ratios. The values of DENj are given using a FALLOFF parameter. Other versions of weighting were tried and included: C The way it was: C GWTij(J,I) = WTS2(J,I) C GWTij(J,I) = GWTij(J,I)*cosd(XLAT(J,I)) C DTW = DENj*WTS2(J,I) C DTW = DTW*cosd(XLAT(J,I)) C GWTj = GWTj + GWTij(J,I) C AM = AM + DTW C New DTW = DENj*WTS2(J,I) AM = AM + DTW C GWTij(J,I) = DENjB*DENj*WTS2(J,I) C GWTij(J,I) = DENjB C GWTij(J,I) = DENjB*DENj GWTij(J,I) = DTW WTj = WTj + WTS2(J,I) C if (I.eq.2000) print *, 'I, J, DENj, WTS2(J,I), AM', I, J, DENj, WTS2(J,I), AM end do GM(i) = AM do j=1,NLOS C GWTij(j,i) = GWTij(j,i)/GWTj ! makes every line of sight the same weight (the way it was) C GWTij(j,i) = GWTij(j,i)/WTj/CONSTWT ! make every line of sight weight according to base density ! and relative line of sight weight (session 4)(DENjB*WTS2(J,I)/Wtj) C GWTij(j,i) = GWTij(j,i)/CONSTWT ! base density times the l.o.s. weight at that position ! (session 5) (DENjB*WTS2(J,I)) C GWTij(j,i) = GWTij(j,i)/(CONSTWT*1000.) ! base density times the l.o.s. weight including density ! at that position (session 10) (DENjB*DENj*WTS2(J,I)) C GWTij(j,i) = GWTij(j,i)*AM/(CONSTWT*1000.) ! base density times the total l.o.s. weight including density ! in that direction (session 11) (DENjB*AM) C GWTij(j,i) = GWTij(j,i)/(CONSTWT*1000.) ! base density times the deconvolved density at that position ! (session 12) (DENjB*DENj) GWTij(j,i) = GWTij(j,i) ! the deconvolved density times the L.O.S. weight at that position ! (session 13) (DTW) (because the base density ratio fix is relative to 1) end do end do C C C Mk_Base.for was revised from a version on the vax called MK_VTBTD.FOR. This new version is considerably different from the Vax version and far simplier. Mk_Base.for now (03/30/01) simply divides the original DEN1AU by 3. and uses this as the base density projected to the source surface using the FALLOFF parameter. DEN1AU is a parameter that can be input at the beginning of the main program. No change is currently made in DEN1AU, although this was tried, and the program converged fine. The Mk_Base.for subroutine does output a lot of information though such as the polar and ecliptic density and velocity at both the source surface and 1 AU as well as the base density at both these locations. mkpostd.for in has a new input parameter added which is the time for each line of sight observation in Earth carrington time. This value is the same as the Earth Carrington location in the IPS data, but is different for the Helios data from the Helios Carrington location. mkpostd.for is the same in this respect as the Vax version. The Earth Carrington time for the Helios data is calculated in the main ipshtd.for program immediately after the calls to read_hosf.for as in the Vax program. Should STEREO or some other remote sensing instrument non Earth-based use this program, this change will need to be incorporated for these data. FIXMODELTDN.for was modified to include a new mode parameter that switches to Thomson scattering input. The mode switch in the FIXMODELTDN.for routine now does little but change the printout of the text different from the velocity fix mode. MKDMAPTDN.for was also modified slightly to use a smoothed gridsphere to limit what is and isn't included in the crossed component limit (the gridsphere mode in /IPSHTD/MKDMAPTDN.for is now 3 rather than 4 in the versions of MKDMAPTDN.for in other versions of the main program). mkvmaptdN.for was also modified slightly to use a smoothed gridsphere to limit what is and isn't included in the crossed component limit (the gridsphere mode in /IPSHTD/mkvmaptdN.for is now 3 rather than 4 in the versions of mkvmaptdN.for in other versions of the main program). I am now (3/30/01) running scripts to attempt to determine the best overall values of DEN1AU and FALLOFF to use in the tomography program for different spacecraft and time intervals. I suspect that CMEs decelerate with solar distance while the background solar wind accelerates, and so these two parameters may change depending on the temporal intervals of the fit, and maybe with solar cycle. Also, these will depend on the weighting scheme used. Also, I may want to give more weight to some photometer data - the 90 degree data, for instance. On 4/14/01 I realized that the density fixes should go from ZERO DENSITY. This means that the densities iterated should be the total densities and the ratio of fixes should include the base density. To fix the original program, I removed the DMAPMB densities and instead included the base densities and observed brightnesses into the MkDHModeltdN.for subroutine. The base density brightnesses are now added to the observed brightnesses in the MkDHModeltdN.for subroutine and output from this subroutine to the FixModeltdn.for subroutine. On 4/15/01 I modified this so that now the base density brightnesses for each source are only output from the MkDHModeltdN.for subroutine. I now add the base brightnesses to the observed brightnesses for each source, and I input these brightnesses to the FixModeltdn.for subroutine. This allows the source write routine writeM_Scomp.for to use the model brightnesses to be input with the base brightnesses subtracted from each source in order that these can be compared properly with the observed brightnesses that are gotten from the Thomson scattering. All this assumes the writeM_Scomp.for write routine follows the subtraction which follows the FixModeltdn.for routine which follows the MkDHModeltdN.for subroutine. The above all seems to work and be consistent. It also seems to give answers not unlike the answers that were given using the prior technique. On 4/15/01, I fixed the Mk_Base.for subroutine so that it now outputs proper values. It did not do this following the changes on 4/14/01. The run 4/21/01 to find best parameters for the 10x10 matrix settled on parameters 9.0, 1.0, 8.5, 2.1 for the Helios data and used the default for the velocity for CR 1653 and Helios 2 data. The correlations are 0.859 for density for Helios 2 and 0.744 for UCSD IPS velocity for this rotation. This is considerably better than before for this rotation (Was about 0.762 for the best H2 fit before). The IMP fits still look pretty good, too, and were almost as good as when they were actually fit to EA densities with a higher spatial filter value. Thus, the correction made on 4/14/01 surely helped and worked well. On 4/21/01 I changed the ending of the program so that it now outputs two types of density matrix versions using Paul's new write3d_info routines. and I have run this to make 3 D density matricies to show. For the 1653 rotation: %ipshtd-I-Info, D observations 13667 (Both Helios 1 and 2) %ipshtd-I-Info, V observations 108 (UCSD IPS) On 4.21/01 I also installed more Helios 1 and 2 files into the CASS183 Helios1 and Helios2 directories on soft/dat/ These files will allow me to do tomography at least on the Helios 2 file B79V4_110_0056.hos. To do this I will need to evoke the ipshtd program to work by typing $myfor/IPSHTD/ipshtd ucsd=SANIPS,$dat/ucsd/ helios2=B79V4_110_"(4)".hos,$dat/helios2/ (CR 1681) The rotation is hard-wired into the program currently and needs to be changed from 30 to 56 as: XCbegHOS2 = 56 Also since the Helios 2 data is V-light I should change the parameter before the read program to V light for the helios read routine routine. LT2 = 3 (These two things need to be changed back when the program is run with 1977 data.) On 4/21/01 this version of the program gets: %ipshtd-I-Info, D observations 7539 %ipshtd-I-Info, V observations 151 and seems to converge. Thus I have begun a script for this program to settle on the best parameters for this rotation using a new version of the program named ipshtd79 from ipshdt79.for On 4/21/01 I installed the modifications for ipsd2020.for into the program to output nv3 files. On 4/22/01 I noticed and proved to myself that my installations and these modifications significantly altered the velocity data and somewhat altered the density data as noted by the correlations. It turns out that the velocity data is not very complete and the modifications in the ipsd2020.for program make it more complete and these lower the fit correlations in rotation 1653. They also are incorrect for Helios data since Helios is not at the location of the Earth so that Fillmapols.for can use the time center well. I thus modified the ipshtd.for and ipshtd79 programs to work without the flllmapols call, and have run the program again. The current version for rotation 1653 gives correlations of 0.863 and 0.590 for density and velocity respectively. The convergence for this revised version of the program is of course exactly the same as before, and I confirmed this for the program throughout the run with the same parameter run in temp/ipshtd/H2. On 4/26/01 I modified the write3d_infotd.for subroutine to write3d_infotdh.for so that it works with the ipshtd79.for program. I modified this routine and the ipshtd79.for program so that there is an extra input in the routine that allows a Helios region of interest to be input so that the matrix can be shown properly by the imaging IDL programs. This modification works and seems to work well. There will always be a problem with this when two Helios spacecraft are used to deconvolve the heliosphere since the two spacecraft are not in the same location. There is an even further fix - namely to treat the northern and southern hemispheres differently in the programming before the matrix is output. This will take modifications to several subroutines that are pole and hemisphere specific. The only real subroutine like this though is the fillmapols.for subroutine that deals specifically with the region of interest. You would also need to decide which spacecraft (or Earth) to center on when you output the final density matrix. On 1/4/02 I set up the mk_ipshtd77 program to work on Tamsen's directory. The ipshtd77 program can be compiled using the reqular g77 Fortran compiler by running the make file: ./mk_ipshtd77 The fortran program can be run using the sequence: $myfor/TIPSHTD/ipshtd77 ucsd=SANIPS,$dat/ucsd/ helios1=A77B4_318_"(4)".R08,$HOME/dat/Helios/ helios2=B77B4_318_"(4)".R08,$HOME/dat/Helios/ Use 1661.5 as the rotation number in order to have the period of November 20 - 29, 1977 fully analyzed. Other default parameters are probably OK. On about 2/1/02 Tamsen got her subroutines to provide magnetic field data for the velocity fields provided by the program. On 2/18/02 I modified the main program ipshtd77.for to now give the correct observed brightness to the file gts_1661_18 On 2/20/02 I found that the Helios data sort routine in the main program ipshtd77 was leaving a small portion of the data out of the analysis, and this is now fixed. On 2/26/02 I found that the read_hosf.for program was blanking out the galactic center. I have now disabled this feature in the read_hosf.for subroutine. This adds perhaps 3000 more lines of sight to the tomography for this 1977 analysis. On ~3/22/02 I realized that the EXTRACTD routine was not using the FALLOFF parameter to extract the density from the base map. I fixed this on 4/1/02, and now the fits to the in-situ data at Earth and at Helios are far more consistent. The correlations do not change very much at all for the different time series, and I guess this makes sense, since only the scale of the change is affected (slightly different over the whole time) but not the change itself. Thus, extractd and its subroutine call is different now in this and the ips2020 version of the program. The transfered version of the program gave identical answers on CASS185 when run on CASS185 on 4/3/02. To give this identical answer Paul need to change a double precision rotation parameter back to single precision on CASS185. Since I expect that the parameter is correct in double precision and not in single I expect that the earlier run on 4/2/02 that was close but not identical was the more correct version. On 4/4/02 the transfered version of the program (that previously compiled without errors or warnings) now compiles on CASS185 with a warning about get2dval and get3dval being a duplicate routine. This does not give me a good feeling about the current version of the program on CASS185. On 4/22/02 I began the process of making the ipshtd77 program accept a three-component xcshift parameter that includes latitude as well as time shifts. This involves modifications to the main program ipshtd77.for and mkshiftdn.for mkpostd.for extractd.for write3dinfotd.for mkveltd.for get4Dval.for These were modified and checked and gave the same answers when no modification was in place. On 5/20/02 a value of Rconst was added to the parameter outputs of mktimesvd. This constant is then added to the inputs of mkshiftdn.for extractd.for to make them work in an accurate form. On 5/20/02 I modified mkpostd.for to incorporate the complete latitude change. This also takes a modification in the main program to incorporate this projected latitude. In addition, modifications need to be made to the calls to include this projected latitude (XLAT-->XLproj) Get4dval MkVmodeltd MkGModeltdn MkDHModeltd This is done to incorporate the new projected values of latitude that are already handled correctly in these routines. On this same date I modified the routines write3dinputd.for extractd.for to include the projected values of latitude correctly as well.