MAVEN NGIMS IDL Request Log

Instrument Contacts:MAG: Gina DiBraccio, Jared EspleyLPW: Chris Fowler (Christopher.Fowler@lasp.colorado.edu),

Laila Andersson (Laila.Andersson@lasp.colorado.edu)

STATIC (2015-11-22)

From Gina DiBraccio:I've written a quick IDL program (static_ion_densities.pro) with tplot commands that you can use to pull out the densities of specific ions. I have already per-formed this myself for H+, O+, O2+ so you should be all set. Feel free to play with the mass intervals, but I pretty much used the same numbers that our Berkeley colleagues have used for each ion species. You can either run the pro-gram from IDL or in the command line. I've added a few comments throughout to explain what is being done, but I believe most of it is pretty straight forward. One word of warning: be sure to set the correct time range before running!

pro static_ion_densities

;----- Calculate ion densities and combine to a single tplot variable

; --- Load static data (be sure to set correct timespan first!)---mvn_sta_l2_loadtt=['15-05-05/17','15-05-05/19']dat2=mvn_sta_get('c6',tt=tt)

;--- change mass intervals for ions of interestget_4dt,'n_4d','mvn_sta_get_c6',mass=[.6,1.5],name='h_density', m_int=1.get_4dt,'n_4d','mvn_sta_get_c6',mass=[12.,24.],name='o_density', m_int=16.get_4dt,'n_4d','mvn_sta_get_c6',mass=[24.,40.],name='o2_density', m_int=32.

; ---change y-axis title for plots and set colors for each ion---options, 'h_density', ytitle='H!U+!N!CN!C(cm!U-3!N)', color=65options, 'o_density', ytitle='O!U+!N!CN!C(cm!U-3!N)', color=207options, 'o2_density', ytitle='O!D2!U+!N!CN!C(cm!U-3!N)', color=150

; --- get the data structure for each ion and combine into single tplot variableget_data, 'h_density', data=h_dataget_data, 'o_density', data=o_dataget_data, 'o2_density', data=o2_datastore_data, 'ion_density', data={x:h_data.x, y:[[h_data.y], [o_data.y], [o2_data.y]]},$ dlim={ytitle:'Ion!CN!C(cm!U-3!N)',labels:['H!U+!N','O!U+!N','O!D2!U+!N'],colors:[65,207,150],thick:2}options,'ion_density','labflag',-1 ;turn flag on so that the legend for each ion color is shown

tplot, 'ion_density'end

From Micah Johnson:I'm trying to select time periods that line up with the NGIMS runs, and I'm unclear how the tt array is being interpreted. In your code you use a string, but in the mvn_sta_get code it seems to expect a number.  I'm not seeing where the trans-lation from string date into a number occurs. I'm pretty new to IDL, but it doesn't seem that the tt array contents have much effect. If I use the timespan command and leave the tt variable at your values, the timespan I ask for is what appears in the plot.

I'm a little confused about the purpose of the tt array.  It seems like it should be the range of the plot, but it isn't in my testing. Can you provide any insight?

From Gina:A few suggestions to try... (I haven't run this code for a few months so I'm trying to remember what I've done exactly...)

The tt string can be converted to unix time by running:time=time_double(tt)(fyi, to convert the other way you can use the function "time_string")

If you are setting the timespan separately then you shouldn't have to set tt. If set-ting timespan produces the results you want, I would ignore setting tt because from what I've learned, 'timespan' seems to rule the time intervals in tplot.

Finally, according to the code, it looks like if no timespan or tt is set then you will prompted to click on your time series plot to set the start/stop times.

In general, tplot does some really weird things and can act like a black box at times. If you are still having trouble let me know and I'll dive into my old code a lit-tle further.

Note to self: Generation of first batch of STATIC HDF5 files completed after this.

STATIC (2016-02-22) S/C Potential

Mehdi to McFadden:We have been running full ion orbit days with NGIMS for few months so we can get more comparison with STATIC.I would like us to assess so we can decide whether we keep them or whether we resume our normal ion/neutral cadence.

You have the STATIC and S/C data and I have the NGIMS data. If you send me the STATIC data along with S/C potential, I can do that analysis, or I can send

you the NGIS data for those data and your merge it with the STATIC data ?How do you suggest we proceed.

McFadden to Mehdi:I've been working on this non-stop since the PSG - and hopefully I'm finished with the code today. After the PSG, while looking closely at the two different s/c potential estimation methods, I started worrying that the lack of long stretches of overlap indicated problems with one of the methods. I eventually tracked it down to ignoring ion suppression- which is now included - but had almost no impact on the result for subtle rea-sons - but now I have better agreement in overlapping period. After fixing that bug, validity testing revealed other periods where my assump-tions broke down for short periods and the code required tweaks to make it work properly. This morning I woke up with a solution to one bug- when s/c charges to high value, static sees scattered, trapped O2+ at energies below s/c potential which must be ignored in the potential calculation - which I just coded. However, further testing revealed another short period when assump-tions broke down - which I also just fixed. A I expect to be testing all day today. Unless a major bug appears, I expect to check in the code for comprehensive processing this week - the code is good enough.

Once checked in, I can send you the routine if you want something immediately - it can be run as part of your batch processing - and it will generate a tplot struc-ture from which you can extract your potentials. In regions where the routine fails, the potential is set to zero.

One thing to keep in mind - the routine will not work during static cleaning mode orbits - I don't measure low energies on these orbits. Hopefully these new data can be used to tune the lpw s/c potential code to make it work.

Continued…Nearly all the STATIC data has been reprocessed to include s/c potential esti-mated from STATIC data alone.

You can load STATIC data are loaded and the tplot variables generated with the following lines

mvn_sta_l2_loadmvn_sta_l2_tplot

then the s/c potential will be stored in the tplot variable

mvn_sta_c6_scpot

If you run the following lines

timespan,'2016-02-21',1loadct2,43cols=get_colors()mvn_sta_l2_loadmvn_sta_l2_tplotstore_data,'mvn_sta_c0_E_pot',data=$['mvn_sta_c0_P1A_E','mvn_sta_c6_neg_scpot']ylim,'mvn_sta_c0_E_pot',.3,30,1tplot,['mvn_sta_c6_scpot','mvn_sta_c0_E_pot']

you should get a plot of potential and an ion spectra with the potential overlaid in red.

Micah to Mehdi:OK, so I can start a run tonight to regenerate all the STATIC HDF files.Using McFadden's commands, I see alot of tplot variables.Should I just add mvn_sta_c6_scpot to the output?  Are there others you might need? mvn_sta_c6_neg_scpot?

Mehdi to Micah:I think mvn_sta_c6_scpot is the only one we are after.

Micah to Mehdi:I've added a new column that you should be able to read with:

scpotx = h5read('sta18926.h5', '/scpot/X')scpoty = h5read('sta18926.h5', '/scpot/Y')

MAG (2015-11-17) Problems with timespan command

Micah to Jared:I'm trying to run some code you gave me to get MAG data in a form Mehdi can use. He says that he wants "measured  Bx, By and Bz and the induced field (B, By and Bz)."

I'm pretty sure this code does some part of that, but I'm getting errors.  I pick a particular timespan, corresponding to one of our runs:

timespan, '2015-09-18 11:31:42', 0.0724537634

Then, I run the routine I pulled out and restructured a little.

;+; FILENAME: hdfgen_magloader.PRO;

; PURPOSE: MAG Loader into Tplot;-

pro hdfgen_magloader

;load the spice kernels, we will be doing some rotationsmk = mvn_spice_kernels(/all, /load)

;make a lower case stringmagCadenLow = 'full'

;Grab orbit datamaven_orbit_tplot, /load, result=result, /current

;----------------PROCESS MAG DATA-----------------------------------------------;

;load data in MSO coordinatesmvn_mag_load, level+magCaden, spice_frame='MAVEN_MSO'

;split the vectorsplit_vec, 'mvn_B_'+magCadenLow+'_MAVEN_MSO'options, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_x', ytitle='B!Dx!N [nT]'options, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_y', ytitle='B!Dy!N [nT]'options, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_z', ytitle='B!Dz!N [nT]'

;calculate the total fieldget_data, 'mvn_B_'+magCadenLow+'_MAVEN_MSO', data=data, alim=alim, dlim=dlimbmag = sqrt(data.y[*,0]^2.0+data.y[*,1]^2.0+data.y[*,2]^2.0)dataMag = {x:data.x, y:bmag}store_data, 'mvn_B_mso_mag', data=dataMag, dlim=dlimoptions, 'mvn_B_mso_mag', ytitle='|B| [nT]'

;load or run model model if deisredmvn_model_bcrust_load, morschhauser=1

;limit crustal model to alt<4400 km;.compile mvn_mag_modelLowAlt.promvn_mag_modelLowAlt, modelName='mvn_mod_bcrust_mso', maxalt=1000. ;calculate the total fieldget_data, 'mvn_mod_bcrust_mso', data=data, alim=alim, dlim=dlimbMagModel = sqrt(data.y[*,0]^2.0+data.y[*,1]^2.0+data.y[*,2]^2.0)dataModel = {x:data.x, y:bMagModel} store_data, 'mvn_B_model_mso', data=dataModel, dlim=dlimoptions, 'mvn_B_model_mso', ytitle = '|B| Morschhauser'modelOut = interpol(dataModel.y, dataModel.x, dataMag.x)store_data, 'mvn_B_mso_mag', data={x:dataMag.x, y:[[dataMag.y], [modelOut]]}options, 'mvn_B_mso_mag', ytitle='|B| [nT]' ;split vector to componentssplit_vec, 'mvn_mod_bcrust_mso'options, 'mvn_mod_bcrust_mso_x', ytitle='B!Dx!N Mors. [nT]', color=235options, 'mvn_mod_bcrust_mso_y', ytitle='B!Dy!N Mors. [nT]', color=235

options, 'mvn_mod_bcrust_mso_z', ytitle='B!Dz!N Mors. [nT]', color=235 ;Combine MAG data in MSO coordinates and Morschhauser Results in MSOget_data, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_x', data=fullget_data, 'mvn_mod_bcrust_mso_x', data=modelmodelOut = interpol(model.y, model.x, full.x)store_data, 'mvn_B_mso_x', data = {x:full.x, y:[[full.y],[modelOut]]}options, 'mvn_B_mso_x', ytitle='B!Dx_MSO!N [nT]' get_data, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_y', data=fullget_data, 'mvn_mod_bcrust_mso_y', data=modelmodelOut = interpol(model.y, model.x, full.x)store_data, 'mvn_B_mso_y', data = {x:full.x, y:[[full.y],[modelOut]]}options, 'mvn_B_mso_y', ytitle='B!Dy_MSO!N [nT]' get_data, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_z', data=fullget_data, 'mvn_mod_bcrust_mso_z', data=modelmodelOut = interpol(model.y, model.x, full.x)store_data, 'mvn_B_mso_z', data = {x:full.x, y:[[full.y],[modelOut]]}options, 'mvn_B_mso_z', ytitle='B!Dz_MSO!N [nT]'

;----------------- END MAG---------------------------------------------;---------------- START S/C POSITION-----------------------------------

;save s/c position in MSO coordinates as new tplot variablesstore_data, 'mvn_pos_mso', data={x:result.t, y:[[result.x],[result.y],[result.z]], $ labels:['X_Rm', 'Y_Rm', 'Z_Rm']}

;split the vectorsplit_vec, 'mvn_pos_mso'options, 'mvn_pos_mso_x', ytitle='X_mso [R!Dm!N]'options, 'mvn_pos_mso_y', ytitle='Y_mso [R!Dm!N]'options, 'mvn_pos_mso_z', ytitle='Z_mso [R!Dm!N]'

;save s/c positionsstore_data, 'mvn_pos_pc_lon', data={x:result.t, y:result.lon, labels:['Lon']}store_data, 'mvn_pos_pc_lat', data={x:result.t, y:result.lat, labels:['Lat']}

end

It fails in the call to maven_orbit_tplot.

The line is: torb = dblarr(norb-3L)

The log says:Creating tplot variable: 3 sheathCreating tplot variable: 4 pileupCreating tplot variable: 5 wakeCreating tplot variable: 6 windCreating tplot variable: 7 ionoCreating tplot variable: 8 alt2Multi- tplot variable: 8 alt2 :  alt sheath pileup wake wind iono

% Array dimensions must be greater than 0.% Execution halted at: MAVEN_ORBIT_TPLOT  499 /Users/mjohnso6/mav/idl/maven_sw_20151116/maven_sw/projects/maven/maven_orbit_tplot/maven_or-bit_tplot.pro%                      HDFGEN_MAGLOADER   16 /Users/mjohnso6/mav/gse/Apps/hdfgen/hdfgen_magloader.pro%                      $MAIN$          

From Jared:Yeah, sorry. maven_orbit_tplot isn't my code -- I just use it. Maybe load the full day first so maven_orbit_tplot is happy and then use timespan to reduce the interval?

Micah to Mehdi:[The MAG team have…] kind of washed their hands of the maven_orbit_tplot code, written by Dave Mitchell (I think).  That is the problem code that basically crashes when given anything smaller than a day.

Jared suggested an option where I call that code with a day-long timespan, and then reset the timespan to the shorter NGIMS-aligned time period before calling their mag loader.  This causes no error, but the resulting tplot variables are a day long.  I assume it is not using timespan at all, but rather looking for the actual data from maven_orbit_tplot.

The simple fact of the matter is that all this IDL code was written for the purpose of generating day-long data files.  The API allows for shorter time to be input, but we are the first to really exercise that capability.  It's a crap shoot.  STATIC code happens to work with that input and the MAG code does not.  LPW has a similar behavior.

This is not a simple little bug. There are assumptions in this code that prevent it from working the way we want it to.  It would require some reengineering on the part of the MAG team, and I'm sure we can't just force them to do that.

My assessment stands that if you want NGIMS-aligned data files, I will have to split them myself and it's not a simple task. On the upside, whatever scheme I implement will apply to the other instruments that have the same day-length file assumption baked in.  I might be able to get you something by the end of next week.

Mehdi to Micah:I think that it is worth the investment to write some code that restrict the extracted data to the TID timespan before writing the hd5 files. It is cleaner and applicable to the rest of the instruments.

MAG (2015-11-20) Loading full vs 1sec resolution

Micah to Jacob Gruesbeck:The MAG code I have makes data with what appears to be 0.1 sec time resolu-tion. Is there an easy way to tell tplot to only keep 1 sec time resolution?

From Jacob:By default the loader will download the full resolution (32 Hz) data.Berkeley does produce a 1 second product. To get 1 second resolution datayou can use:

mvn_mag_load, ‘L2_1Sec’

This should be enough to get you 1 sec data, but they don’t always producethis product at the greatest cadence, so if the time period you want isn’tavailable, you can produce it by running these commands

;example for running 2015-01-01

Timespan, ‘2015-01-01’, 1    ;or whatever timespan you wantget_timespan, trange0

path = ‘maven/data/sci/mag/l2/sav/$RES/YYYYY/MM/mvn_mag_l2_pl_$RES_YYYYMMD-D.sav’;This is the normal Tplot path structure it’s downloader uses, importantto keep exactly $RES and YYYYY, MM, and YYYYYMMDD the next code matchesthese patterns and fills in as appropriate

mvn_save_reduce_timeres, path, trange=trange0, resstr=’1sec’, verbose=1;this produce a 1sec resolution save file in the usual tplot sav directorystructure, so you can then run the below

mvn_mag_load, ‘L2_1Sec’

Hope you don’t need to use the above and you can just download the datayou want. Let me know if you run into any problems.

Micah to Jacob:I tried replacing 'full' with '1Sec' in this code (from Jared, I think):

mvn_mag_load, level+magCaden, spice_frame='MAVEN_MSO'

;split the vectorsplit_vec, 'mvn_B_'+magCadenLow+'_MAVEN_MSO'options, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_x', ytitle='B!Dx!N [nT]'options, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_y', ytitle='B!Dy!N [nT]'options, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_z', ytitle='B!Dz!N [nT]'

;calculate the total fieldget_data, 'mvn_B_'+magCadenLow+'_MAVEN_MSO', data=data, alim=alim, dlim=dlimbmag = sqrt(data.y[*,0]^2.0+data.y[*,1]^2.0+data.y[*,2]^2.0)

But it fails.  It seems that split_vec doesn't have enough info to do its work with the 1sec data.

% Compiled module: SPLIT_VEC.Variable  has no dataNo TPLOT names found that match: mvn_B_1Sec_MAVEN_MSO_xNo TPLOT names found that match: mvn_B_1Sec_MAVEN_MSO_yNo TPLOT names found that match: mvn_B_1Sec_MAVEN_MSO_z% Expression must be a structure in this context: DATA.

Do you know of any way to get this to work or do I need to run with full resolution and then pare it down at the end?

From Jacob:I think I may see the problem. I’m not as familiar with Jared’s code, butI do see two problems with the copied snippet.

First, you set magCaden to ‘1Sec’ to download the data, but usemagCadenLow to build the string in the split_vec command.

You may have set magCadenLow=magCaden or something of that sort, but theother problem is a more annoying part of Tplot. The mvn_mag_load functionis not case sensitive. So, ‘1Sec’ will load just as ‘1sec’ or ‘1SEC’. ButTplot commands are case sensitive when calling the string for the tplotvariable names, in split_vec for example. The mvn_mag_load creates a tplotvariable name of ‘mvn_B_1sec_MAVEN_MSO’. In your code it’s looking for‘mvn_B_1Sec_MAVEN_MSO’ which it can¹t find. I tried the following code andit was able to get the 1 second data, split into components, and computethe magnitude without any problems.

timespan, '2015-01-01', 1mk = mvn_spice_kernels(/all, /load)

;*****Here comes the biggest changemagCadenLow = '1sec'level='L2_'    mvn_mag_load, level+magCadenLow, spice_frame='MAVEN_MSOsplit_vec, 'mvn_B_'+magCadenLow+'_MAVEN_MSO

options, 'mvn_B_'+magCadenLow+'_MAVEN_MSO_x', ytitle='B!Dx!N [nT]'

get_data, 'mvn_B_'+magCadenLow+'_MAVEN_MSO', data=data, alim=alim,dlim=dlimbmag = sqrt(data.y[*,0]^2.0+data.y[*,1]^2.0+data.y[*,2]^2.0)

Micah to Jacob:Thanks, it works! I would not have guessed that it was a case problem.

By the way…I have several .pro files in a directory that I put in my IDL path.  In general, when I call a routine from there is auto-compiles and runs. However, mvn_mag_model-LowAlt.pro seems to require manual compilation in the IDE before its routine is defined.  Now that I'm trying to automate it in the command line IDL, this is caus-ing me fits. Any idea why this might happen?

Is there a way to force a compilation from the command line?

From Jacob:I actually have the exact same problem with that file myself. I’m stilltrying to figure out why it won’t auto compile like the others to make thefix. However, you can compile from the command line. Use the command

IDL> .compile mvn_mag_modelLowAlt.pro

Micah to Jacob:I'm looking at the output of the MAG code, in particular, the following tplot vari-ables:mvn_B_1sec_MAVEN_MSO   mvn_B_1sec_MAVEN_MSO_x mvn_B_1sec_MAVEN_MSO_y mvn_B_1sec_MAVEN_MSO_z mvn_B_model_mso            mvn_mod_bcrust_mso_x   mvn_mod_bcrust_mso_y   mvn_mod_bcrust_mso_z   

Is there a reason that all the times for the mvn_B_1sec_MAVEN_MSO* variables end with .5, while the crustal field model time values are on the second?

From Jacob:So, I just finished speaking with Jared to confirm my suspicions aboutthis. I don’t think there is any real reason, other than the code thatdoes the mag resampling and the crustal field model were written byseparate people at Berkeley. Generally, to get the crustal field on thesame time step as the mag data we interpolate the crustal field modeldataset.

Below is a sample code showing how we do this, for the x-component in thiscase:

;;;;get_data, 'mvn_B_'+strlowcase(magCaden[cadenChoice])+'_MAVEN_MSO_x',data=full   get_data, 'mvn_mod_bcrust_mso_x', data=model   modelOut = interpol(model.y, model.x, full.x)store_data, ‘mvn_mod_bcrust_mso_x’, data={x:full.x, y:modelOut}

;;;;

Micah to Jacob:Looking at plots of data of the 1sec and full resolutions and zooming in, my guess is that the 1sec resolution is binning the original data and the 0.5 times are the centers of the bin.  This level of detail is unlikely to matter for Mehdi's pur-poses, I just dug down a little deep since I'm using new tools and want to check if they are doing what I expect.

LPW (2016-01-11)

Mehdi to Micah:The files they dump in the SDC are lagging of what is tplot, so I rather get them from there too. And I like splitting them by TID too. When you are ready, let's sit down and plot one pass on my computer and on tplot and see what variables are relevant.

Micah to Mehdi:I don't have any more up-to-date data than the L2's.  Those only go to Nov-30-2015 right now.

Unless there is some other command you can get from LPW...

Right now I'm just using:mvn_lpw_cdf_read, '2015-11-31'

Mehdi to Laila:I have sent two LPW products to SDCThe data are from 2014 oct2014 nov2014 dec2015 feb2015 mar2015 apr 

I hope to get the following data later today to SDC2015 jan2015 may2015 jun If you use tplot routines you can use the attached routine where the two density products are merged.I do not know how fast the data reach to SSL so you can access the data, hopefully just 1-2 hours. Use the data with a flag value above 50 and ignore data where Vsc is less than –8 V (this is applied in the crib sheet)Also use the uncertainty in the data (dv and dy). 

pro crib_lpw_density_final,st

mvn_lpw_cdf_read, st, vars=[ 'lpnt', 'wn']

;----------- ; make the individual tplot variables of nt include only the valid points get_data,'mvn_lpw_w_n_l2',data=dat_wn get_data,'mvn_lpw_lp_n_t_l2',data=dat_nt

flag=50 nn_wn=where(dat_wn.flag GT flag)

nn_nt=where(dat_nt.flag GT flag and dat_nt.y[*,2] GT -8) store_data,'mvn_lpw_lp_mod_ne', data={x:dat_nt.x[nn_nt],y:dat_nt.y[nn_nt,0],flag:dat_nt.flag[nn_nt]} options,'mvn_lpw_lp_mod_ne',yrange=[10,2e5] options,'mvn_lpw_lp_mod_ne',ylog=1 options,'mvn_lpw_lp_mod_ne',ystyle=1 options,'mvn_lpw_lp_mod_ne',color=4 options,'mvn_lpw_lp_mod_ne',psym=-4

nn_nt=where(dat_nt.flag GT flag and dat_nt.y[*,2] GT -8) store_data,'mvn_lpw_lp_mod_te', data={x:dat_nt.x[nn_nt],y:dat_nt.y[nn_nt,1],flag:dat_nt.flag[nn_nt]} options,'mvn_lpw_lp_mod_te',ylog=1 options,'mvn_lpw_lp_mod_te',ystyle=1 options,'mvn_lpw_lp_mod_te',color=0 options,'mvn_lpw_lp_mod_te',psym=-4

nn_nt=where(dat_nt.flag GT flag) store_data,'mvn_lpw_lp_mod_vs', data={x:dat_nt.x[nn_nt],y:dat_nt.y[nn_nt,2],flag:dat_nt.flag[nn_nt]} options,'mvn_lpw_lp_mod_vs',ylog=0 options,'mvn_lpw_lp_mod_vs',ystyle=1 options,'mvn_lpw_lp_mod_vs',color=0 options,'mvn_lpw_lp_mod_vs',psym=-4

store_data,'mvn_lpw_lp_mod_ne_flag', data={x:dat_nt.x[nn_nt],y:dat_nt.flag[nn_nt]} options,'mvn_lpw_lp_mod_ne_flag',psym=-4

;-------------------------

; find the wn points that is valid and not close to a IV valid measurement

get_data,'mvn_lpw_lp_mod_ne',data=dat_nt t0=time_double(st)

wny=dat_wn.y[0] ; need to get the others too dy dv flag wnt=dat_wn.x[0] wnf=dat_wn.flag[0] ; identify wn that has flag GT 50 and is at least 5 seconds away from a nt value for i=1,n_elements(dat_wn.x)-1 do begin if dat_wn.flag[i] GT flag then begin tmp=min(abs(dat_wn.x[i]-dat_nt.x),qq) if tmp GT 5 then begin wny=[wny,dat_wn.y[i]] wnt=[wnt,dat_wn.x[i]] wnf=[wnf,dat_wn.flag[i]] endif endif endfor

;-------------------- ;---------- ;merge the density points that is valid and create the mvn_lpw_ne_l2_valid variable net=[wnt,dat_nt.x] ney=[wny,dat_nt.y] nef=[wnf,dat_nt.flag] tmp=sort(net) net=net(tmp) ney=ney(tmp) nef=nef(tmp)

store_data,'mvn_lpw_ne_l2_valid',data={x:net,y:ney} options,'mvn_lpw_ne_l2_valid',color=6 options,'mvn_lpw_ne_l2_valid',psym=1 options,'mvn_lpw_ne_l2_valid',ylog=1 options,'mvn_lpw_ne_l2_valid',yrange=[1,5e5]

;-------------------

!p.charsize=2. tplot,['mvn_lpw_ne_l2_valid','*mod_*te','*mod_*vs']

end

Mehdi to Micah:Very urgent request. LPW put out their data on SDC and apparently they are using a new version of cdf that matlab does not seem to like, so my code do not work an d I cannot read their file to do a cross calibration.Can you see if you can access their data with tplot and if you can export their file to hd5. The project is expecting us to report on whether we can now do a cross calibration with LPW or not.

Laila attached an idel file dedicated to LPW. Let me know if you can make sense of all this.

Micah to Mehdi:The crib_lpw_density_final.pro file in this forwarded email produces tplot vari-ables that are a little strange.  I ran into trouble immediately trying to fulfill your request to give you TID-split mvn_lpw_w_n_l2.  The times are out of order and there's lots of NaN values, so I assumed that the 'mod' version of the tplot vari-ables output by the 'crib' script were really what you needed.  Then I looked at mvn_lpw_lp_mod_te and it doesn't seem any better.  I've attached an archive of files with dumped csvs for 2015-08-31.  Maybe you can make heads or tails of it.  The files are named with the tplot names, so you can ask Laila or whomever.

Chris Fowler to Mehdi:

;Crib Mehdi and Micah outlining LPW L2 data products.;;This crib makes use of the LPW IDL routines stored in the Berkeley SVN, for use with the IDL tplot software.;;-

;Set timerange:timespan, '2015-03-03', 1. ;date, and number of days to run for. More exaxt times and fraction days can be given ;timespan, '2015-03-03/12:23:01', 1.3 ;Load data:mvn_lpw_load_l2, ['lpnt', 'wn'] ;get LP data and waves data.

;Get data from a tplot structure:;There are multiple keywords you can set:;data: contains the actual numbers;dlimit: contains calibration information;limit: contains plotting information used by tplot (axis titles, units, etc)get_data, 'mvn_lpw_w_n_l2', data=data1, dlimit=dl1, limit=ll1

;Look at what you have:help, data1 ;shows you the data structure

help, dl1 ;shows you the calibration information

help, ll1 ;shows you the plotting information

;DLIMIT: I'm not sure every PFP instrument uses the dlimit keyword to store calibra-tion information like LPW does, so this information;may only be available for LPW data.;Hopefully most of the fields are somewhat self explanatory, but the desciptive ones follow this format:;dl1.x_catdesc ;these both (should) tell you what data.x contains, for example (PDS requires these two fields that are very similar in content).

;dl1.x_var_notes

;For 'wn', data.dy contains the upper uncertainty on density, and data.dv contains the lower uncertainty. This means to plot the error bars, you need to do:;data.y - the data;data.y + data.dy - the upper data value / error bar;data.y - data.dv - the lower data value / error bar

;I believe this format is the same for all LPW data products, but I would double check each one just to check. Ne, Te and Vsc should have errors of roughly +- <25% in general.

mvn_lpw_w_n_l2mvn_lpw_lp_ne_l2mvn_lpw_lp_sc_l2mvn_lpw_lp_Te_l2flag whole number 0-100 decimal 1-2, use anything 50 and more

Micah to Meredith:The crib sheet that I was given is attached in this thread.

It distills down to me running the following IDL commands, which you can refer-ence when talking to Chris Fowler.

mvn_lpw_load_l2, ['wn'], /noTPLOTmvn_lpw_load_l2, ['lpnt'], /noTPLOT

Then I dump the contents of the tplot variables, unchanged, into an HDF file.LPW (2016-04-06) wave data missing

Micah to Mehdi:I generated and committed the TID-split LPW data.  It only goes up to TID 18147. It seems that the LPW data isn't available after early December 2015.

Mehdi to Micah:I looked at the SDC website and they have LPW cdf data up to 03 March 2016.I will check with Chris to see why we cannot get those through TPLOT.

Micah to Mehdi:Here's the response I get when asking for more recent data:

IDL> timespan, '2015-12-30', 1Time range set from 2015-12-30/00:00:00 to 2015-12-31/00:00:00IDL> mvn_lpw_load_l2, ['lpnt', 'wn']No files found matching: maven/data/sci/lpw/l2/2015/12/mvn_lpw_l2_wn_20151230_v??_r??.cdf

mvn_lpw_cdf_read: ### No cdf files found matching input, variables, and levels:

2015-12-30wnl2

No Data stored yet!No files found matching: maven/data/sci/lpw/l2/2015/12/mvn_lpw_l2_wn_20151231_v??_r??.cdf

mvn_lpw_cdf_read: ### No cdf files found matching input, variables, and levels: 2015-12-31wnl2

No Data stored yet!### WARNING ### : mvn_lpw_load_l2 - No data found!IDL>

From Mehdi:It seems that we are able to get the 'lpnt' but not the 'wn' data past mid Dec.

From Chris Fowler:That’s correct - we no longer make waves measurements after ~Dec 2015.This was to avoid having to switch a relay, which was slowly degrading.So, with no waves, we get no waves densities after Dec 2015.

LPW (2016-03-31) High cadence data

Mehdi to Laila:Can you send me, or let me know where I can find the high cadence spacecraft potential (higher cadence than 4) for orbit #2431 (Dec 30 2015) and orbit #2437 (Dec 31 2015).We talked during the PSG that LPW can get those potential at a much higher cadence.I need those two orbits to test whether I can correct for LPW potential sweeps.

Laila to Mehdi:See if this works: mvn_lpw_load, '2016-03-25',filetype='L0', tplot_var='all',/notatlaspget_data,'mvn_lpw_swp1_V2',data=datass=128for i=0,n_elements(data.x)-1,ss do $  data.y[i:i+ss-1]=data.y[i:i+ss-1]-mean(data.y[i+ss/2:i+ss-1])  store_data,'mvn_lpw_swp1_V2_ac',data=data  tplot,'mvn_lpw_swp1_V2*' The first ~2 points can be zero out of the instrument, I need to check the first and the last points a little better, but each swee/data packet is 128 points long. This variable 'mvn_lpw_swp1_V2_ac' will give you the AC change due to the LP sweep (I remove ny DC signal).This is just for Boom 1, which is the only one used after mid dec. For boom 2 the variable is called 'mvn_lpw_swp2_V1'

Micah to Mehdi:I generated the LPW files and they are 60MB each, so I committed them to SVN under tplothdf/lpw

SWIA (2015-11-19)

Mehdi to Jasper:I have been toying around today trying to figure out how I can get the V X B.Do you have an IDL piece of code that extract that from SWIA and MAG data ?

Jasper to Mehdi:If you have two tplot variables loaded for MAG data and velocity in appropriate coordi-nates, you can do the following: tinterpol_mxn,'vdata','bdata'    to interpolate the velocity data to the time-base of the MAG data

tcrossp,'bdata','vdata'   to calclulate B x V (= -V x B) The bulk velocity 'mvn_swim_velocity_mso' should be one of the default variables that you get if you load all the SWIA data - it's already in MSO and ready to go. As long as you are in the solar wind or sheath this should usually be reasonable (it won't be good if there are a lot of heavy ions).  For the MAG data, you may need to rotate their vectors into MSO first depending on where you are getting the data from.

Mehdi to Micah:I've looked into this and it looks pretty straightforward.  After I've loaded a day of MAG and SWIA, I calculate -VxB as prescribed, and the tplot variables in memory are:mvn_B_1sec_MAVEN_MSOmvn_B_1sec_MAVEN_MSO_xmvn_B_1sec_MAVEN_MSO_ymvn_B_1sec_MAVEN_MSO_zmvn_B_mso_magmvn_B_model_msomvn_mod_bcrust_mso_xmvn_mod_bcrust_mso_ymvn_mod_bcrust_mso_zmvn_B_mso_xmvn_B_mso_ymvn_B_mso_zmvn_swim_densitymvn_swim_velocitymvn_swim_velocity_msomvn_swim_pressuremvn_swim_temperaturemvn_swim_temperature_msomvn_swim_quality_flagmvn_swim_decom_flagmvn_swim_atten_statemvn_swim_swi_modemvn_swis_en_efluxmvn_swis_decom_flagmvn_swim_velocity_mso_interpmvn_B_1sec_MAVEN_MSO_cross_mvn_swim_velocity_mso_interp

I can either regenerate the MAG data and tack on the -VxB column, named mvn_B_1sec_MAVEN_MSO_cross_mvn_swim_velocity_mso_interp here, or generate a SWIA file for each TID.

I assume there's a better name for the column... cnv_field?

If you pick the option for new SWIA files, what else should be in them besides time and this -VxB value?

Mehdi to Micah:For SWIA in addition to –VxB please addmvn_swim_densitymvn_swim_velocity_msomvn_swim_pressuremvn_swim_temperature_mso

Micah to Mehdi:I've checked in TID-split SWIA data to SVN.

The columns should be pretty straightforward.mvn_swim_velocity_mso = Vx,Vy,Vz-VxB = Ex,Ey,Ezmvn_swim_density = nmvn_swim_pressure = pmvn_swim_temperature_mso = Tx,Ty,Tz

EUV (2015-08-06)

Micah to Paul:I've looked at the IDL code that accesses the EUV data, and it's by far the sim-plest case I've seen.  Basically, it just loads the CDF into the tplot structures for plotting.  There isn't really a need that I see to have IDL as a go-between.  I may be oversimplifying your problem, but I believe you should be able to load the CDFs directly into MATLAB and use them.  In my quick tests, here's what I did:

[data, info] = cdfread('mvn_euv_l2_bands_20150330_v01_r04.cdf', 'CombineRe-cords',true,'ConvertEpochToDatenum',true)

This creates a data structure with 6 "columns."  It appears that they are accessi-ble with this notation: data{1}The info variable holds descriptive metadata. It names six "columns:"data, time_tt2000, time_unix, dfreq, ddata, flag

The complication is that these "columns" can also have another dimension.  For example, the data "column" has three values at each time step.  I think this is where the "meat" of the EUV data is.  For example, I plotted all three of them ver-sus time like this:

plot(data{2},data{1})

if you just want the first value:

plot(data{2},data{1}(:,1))

Disclaimer: I'm not sure if the ConvertEpochToDatenum worked.  It didn't seem like the time_tt2000 column was recognized as a time in MATLAB.