ipsd2020 nagoya=nagoya,/home/bjackson/dat/nagoya/yearly Revisions: On the week of 11/13/00 I began modifyfing both mkvmaptdN.for and MKDMAPTDN.for using the mk_ipsd2020NN. 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. On 3/15/01 I compiled the ipsd2020.for program with latitude values equal to 10 and ran the program on rotation 1965 with script compka2020script to check for a better convergence than with the old version of the program. The program works better and while the answers are almost the same in this version as in the test version of the program, inputs 15, .55, .25, .30 for 1965 for the old program give 0.840 and 0.230 and 0.844 and 0.230 there is an ever so slight difference On 3/19/01 I copied the test version of the ipsd2020.for program over as the official version of ipsd2020.for, and am running scripts with it as tests. To do this I needed to modify the ips2020inputm.f program in two places. This version of ipsd2020.for has better inputs and outputs for files read from the disk. On 4/2/01 a new include file was used for MAPRADIAL.H This new map radial is far more simple and uses equal intervals up form the source surface. No longer is level 10, 1 AU anymore, though. Paul claims this works better in his IDL programs. It does change the correlations a lot so that the original 15, .55, .25, .30 for 1965 gives 0.646 and 0.344 now. On 4/3/01 I replaced the CopyVtoVDN and CopyDtoDVN subroutines if nTG .eq. nTV and XCbegG(1,1) .eq. XCbeV(1,1) with a simple call to ArrR4Copy(nLngLatnTG,*,*) replacement. This allows the tomography to run faster and, in addition, the velocity and density tomography is more independent for the two 3D matricies, velocity and density. I am now running scripts to see if I can recover the same inputs as before. The above did not work too well because the Copy programs actually smooth over time significantly, and I couldn't get back the original results. I settled on placing fixes in the writes to the EA files and to the t3d files. On 4/10/01 MKDMAPTDN.for was modified 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). On 4/10/01 mkvmaptdN.for was also modified 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). This changes things so that now I need to again re-run the script to get the best fit to the CR1965. On 4/18/01 or thereabouts, I added two versions of Paul's write3d_info.for subroutine to the main ips2020.for program. On 4/23/01 I added Paul's adjustjdcar.for subroutine to the ipsd2020 program. This may change things a little, and since the scripts are still running, I plan to wait to find a better value for the parameters. On 1/18/02 I changed the variable 25.38 in subroutine MKTimesvd and both EXTRACTD's to 27.275. On 5/20/02 I began the process of making the ipsd2020 program accept a three-component xcshift parameter that includes latitude as well as time shifts. This involves modifications to the main program ipsd2020.f and mkshiftdn.f mkpostd.f extractd.f extractd3d.f write3d_infotd.f write3d_infod3d.f mkveltd_check.f get4Dval.f To do this a value of Rconst needs to be added to the parameter outputs of mktimesvd. This constant is then added to the inputs of mkshiftdn.f extractd.f 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 This is done to incorporate the new projected values of latitude that are already handled correctly in these routines. On 5/21/02 the version of the program that was transferred to CASS185 is the same as the version on both the /transfer and TIPSd2020 subdirectories with the exception that the transfer version does not do magnetic fields while the programs that Paul and Tamsen install are undergoing change. The version of the program on CASS183 in the main directory however, does deal with magnetic fields in the old way. Both the CASS183 and CASS185 versions give identical EA and E3 files using default parameters. The timing of the spike for the Bastille-day CME is late in the model compared to the in-situ response. Something funny happened, though, when the program was transferred, because the source numbers and the output values changed considerably and gave somewhat different answers in both the transferred and non-transferred version when it was run. On 5/22/02 I tried the sim_MOD routine in the ipsd2020 program to see if this makes a difference in the location/position of the peak for the Bastille-day CME. This run did not work. On 5/23/02 I discovered that I had inadvertently placed the new latitude shift in Get4Dval as a projected rather than a line of sight variable. There is no difference in current analyses, but will be in the future. This has now been changed in both the transfer and regular versions. I also checked to be sure that all the Get4Dval calls have time first in the calling seguence, since this is out of sequence from the index values. They all do. On 5/23/02 I tried the sim_MOD routine in the ipsd2020 program to see if this makes a difference in the location/position of the peak for the Bastille-day CME. To do this I have had to modify the mkshiftdn.f routine to include nCar, JDCar, NCoff and FALLOFF in the subroutine calling sequence. This change is not in the transfer version. On 5/23/02 I discovered an error in Get4Dval. It did not work with the Get4dval(3,....) set. This now corrected, I hope. On 5/24/02 I found that the sim_MOD routine would not work because arrays were not dimensioned properly in sim_Mod and shift_MOD. I fixed these now so that sim_MOD works. However, on 5/28/02 I found that the answers given by sim_MOD with default parameters using ipsd2020 did not work to give good answers even though the routine seems to work in ipshtd77. On 5/29/02 I discovered the problem with write3d_infotd3D.f. The bottom density map array written to disk that was copied into the file to be output was being multiplied by a file that was set to near bad values. This gave a write error to disk for a non-standard file. This is now fixed. The dummy values of VM and DM that are written in the subroutine need only have two dimension, and this has now been fixed in the main program and subroutine. On about 7/1/02 I replaced the fillmapols Xmid value entry because it was incorrect and I also placed fillmapols in the nv3f file prepare analysis. On about 7/11/2002 I changed mktimesvd.f so that the times begin about half a rotation earlier than they did prior to this date. I believe these changes are currently transferred to the cass185 computer version of the ipsdt program (10/31/02). On 8/16/02 I changed FillmapOLS so that it is now more automatic and so it has two modes. The first mode is as before to stich together the non-bad points at the point in the sphere the furthermost from Earth. As far as I can tell, the early version worked OK. The second mode limits the regions of the maps at the most distant longitudes from Earth so that these regions do not become too great (or small) in either density or velocity according to some limit. There is also a limit set on the angular distance that this effect can influence - now set at 135 degrees from the Earth. After several runs where there were problems with the program, on 8/17/02, I think I fixed this so that the program now works. On 10/30/02 I copied ipsdt.f to the transfer directory and recompiled it on that directory. The version of mkshiftn.f on this directory does not have several inputs that are present in the parent directory (see my note on 5/23/02) The recompiled version of ipsdt.f now (10/31/02) runs and has the same numbers of sources as the ipsd2020 version on the cass183 computer. There are differences still unaccounted for at the zeroth iteration time step for the first the g-convergence. The program runs to iteration completion (10/31/02). Late 10/31/02 I got the ipshdt program down from CASS185 and got oit to run and give the exact same iterative valuse as the ipsd2020 program I have on CASS183. The probelm was with fillmapols.f that had not been updated on the transfer subdirectory on CASS183. The ipsdt.f program now dies at the end, I expect from the updates in the extract routine. The IDL program on CASS183 does not now produce correct answers from the EA file generated using the current version of ipshdt. This is because the answers in the EA file are entirely different from what they should be, including negative velocities. I expect I have incorrect versions of the EXTRACT routines in the CASS183 library so that they now give bad answers in the EA files. Since I need to speak to Paul to fix this, I better wait til he comes in. On 6/2/03 I made a subdirectory TIPSd2020new so that I could take the latest version of my ipsd2020 and modify time in it to reflect real times and not rotations. On 6/2/03 the main problem in the program is that time is currently confused with rotation, and this is continued in the use of the include files. What is needed for the time-dependent tomography is to make time just that - probably in days from some beginning start time day several days prior to the main observation (as is currently done in terms of a solar rotation). The only time that rotation should come in is in mkshift where the rotation rate at a specific time needs to be used to get back to the surface map location at a given time. In this instance the actual rotation rate should be used for each time in order to correctly account for the variation of the solar rotation rate at any given time of the year. The files that contain these include routines in TIPSd2020new are: File : copyvtovdn.f *** File : extractd3d.f *** File : extractd.f *** File : fillmaptn.f *** File : get3dtval.f *** File : get4dval.f *** File : mkpostd.f *** File : mkshiftdn.f *** File : mkshiftdnn.f File : write3d_infotd3d.f On 6/3/03 I modified mkpostd.f so that it now calls ECLIPTIC_HELIOGRAPHIC8 and is now supposed to use the time of the LOS in DOY and fraction. The DOY is not yet input in double precision, but now it can be, and the time interval from the beginning should be OK as single precision to time precisions of about a minute. On 6/4/03 I modified mktimesvd.f to a version mktimes.f so that now the values needed for the above routines are available. I also modified the version of mkshiftdn.f to now not use ReConst and to use the now OK version of the dXCL and dXCT. There is now no RconstG or ReconstV. This changes the inputs to mkshiftdn.f By 6/5/03 I had gotten all the above to compile using the newest values of real*8 in time in Doy8, and it compiles and runs. On 9/4/03 I modified extractd.f so that it now correctly outputs doy8 and hour. On 9/5/03 I found that the mkshiftn.f routine did not handle the longitude shifts correctly in this version of the time dependent tomography. I thus implemented shifts in longitude in the corotating frame such that longitde shifts in terms of Carrington rotation are used that reflect the slow-fast variation of the Sun below the Earth and whatever given time of the year is chosen for the analysis. This bug most probably was present in the tomography since I implemented the three-element xcshift parameter shift matrix on 5/20/02. On 9/8/03 the program now runs and extractd.f produces an EA file from the data. The EA files still do not correlate well with the real data, so maybe there is yet another error in the shift matrix. On 9/9/03 in thinking over the problem I have come to the conclusion that the time of the observation sets the location on the Sun for the outward material flow and that the rotation of the Sun for the material observed at that time is simply the inertial speed of 25.38 days. Thus the location of that material on the solar surface is simply determined by the inertial speed. Thus, the version of the program before 1/18/02 was more correct and since that time the program has been in error. This is in keeping with the problem I found where before that time the program seemed more stable. I checked the shift matrix, and now both the flight time for the material and the shift in longitude are exactly the same as should be the case for radially outward-flowing material. On 9/9/03 something is still not right in that Nagoya noons are at 3 UT and this is now where the time intervals begin and end. However, the xcint intervals that should begin and end at local midnight now also seem to begin and end at local noon, and this is not correct. On 9/10/03 I tink I have proved to myself that the problem on 9/9/-3 did not exist. I then began work on the bomb in the first write3d_info.f routine and in the early afternoon found the bug - the calling list had an extra comma. This fixed, I then got another problem in write3d_info3d.f fixed and then another bug in extract3d.f fixed and finally the program runs through and gives reasonable answers with the default inputs. On 9/10/03 the default inputs are: begin ht -15 G-level space = 13.0 velocity space = 13.0 G-level temporal = 0.7 velocity temporal = 0.7 G-level power d = 0.65 G-level power v = 0.65 radial g fall gd = 0.15 radial g fall vd = 0.15 For the above ulimited 1964.6 gives EA - -0.231 -0.040, E3 - -0.260 0.062.. The limited gives EA - 0.036, 0.029, E3 - -0.016, 0.124 Back on 4/2/01 after changes in mapradial were made the values 15, .55, .25, .30 for 1965 gave 0.646 and 0.344. I'll now try these same parameters again. For the these ulimited 1964.6 gives EA - -0.164 -0.027, E3 - -0.233 0.061.. The limited gives EA - 0.122, 0.058, E3 - -0,057, 0.007 On 9/16/03 I got the script running again in order to determine the extent to which the settable parameters (filters, etc.) changed the analysis. The program is now very stable to changing filter parameters. However, the correlations never seem to be very good or at least never seem to give large peaks in the model, and in particular the large peak on 7/15/03 in the ACE data is not reproduced well in either the velocity or density models. On 9/16/03 I note that the way of determining vratio and dratio in mkshiftdn.f is different from the way it was done back in 03/20/01 in the IPSd1010 subroutine mkshiftd.f The way back then was to use the ratio between levels and accumulate this rather than using the current scheme of using the shift to the base level as is done now. On 9/18/03 I first tried the most recent version of the tomography program with the newest (cass185, I hope) IPS sources. I finally won! The tomography program now gives back the peak in the 1965 rotation that was present back in 4/2/01! Not only that, the peak is present in the model no matter whether the source surface is at 15 Rs or 1 Rs and no matter where the rotation begins - some differences are present when runs are made. The EA files give nearly the same correlations as do the E3 files interpolated from the 4D matrix in this case with only minor differences when 3 intermediate steps in the model are interpolated. On 9/19/03 I got the scripts running and was able to determine the best parameters - not much different from the ones found back in 4/2/01. The parameters 15, 0.75, 0.30 and 0.25 give EA correlations from the limited time series of 0.610 and 0.793 for rotation 1964.6 The density peak in the model does not go as high as the ACE data and is displaced somewhat right of the ACE peak. The velocity correlation reproduces the two velocity peaks and the dip between the events almost as in the best previlou correlations. The default parameters now work to provide the above results. Fidgiting the parameters to 15 0.75 0.25, 0.30 gives a larger density model peak with a slightly better density correlation for EA of 0.801, but a lower velocity correlation of 0.419. On 9/22/03 the results using scripts on CR 2003 (the May 29, 2003 CME) show that the parameters 16, 0.75, 0.30, and 0.25 fit best with 10-day limited E3 correlations of 0.253 and 0.551. The parameters 15, 0.75 0.30, and 0.25 (as above) give correlations of 0.088 and 0.481 The density peaks associated with the event are reproduced, but the dip between peaks is not as pronounced as it should be and the peaks are not as high as they should be. In this case, setting the parameters to 15, 0.75, 0.25 and 0.30 does not help increase the peak heights much, and does not make the correlations better. Although both ACE and model velocities are high (around 600 km/s), the low velocity correlation during the 10-day time interval comes from a peak observed in the ACE data that is not reproduced in the model. ** Thus the conclusion that I reach is that the parameters 15, 0.75, 0.30 and 0.25 are adequate values to use and that both Kenichi's technique and Tokumaru's (that was used to determine the 1964.6 correlation using that data set) give approximately the same result. Thus, I have now given Tamsen the task of placing the time-dependent magnetic field analysis into the new version of the program and checking to make sure the correlations work the smae on CASS183. On 10/1/03 with Paul's help, I discovered the problem that did not allow the wso files to be printed out. The problem was an incorrect bbwrite library file. With these files printed out correctly we placed the new version of the time dependent tomography on the Web on 10/2/03. On 10/6/03 we found the files on the Web were not updating correctly and the problem was being caused by mktimes not working correctly. The xctbeg and xctend times were being set as if they were divided by 48 rather than by 47 in the TIMECOORDINATES.H include file. xctbeg and xctend are now changed so that the beginning and end times in days are now given correctly. Mktimes was changed and checked. I am currently checking to see that the version of the program on CASS185 works the same as on cass183.