On 10/18/2012 John reset all the UCSD CCMC passwords (on kona, and ono4, and wolf4 - bjackson@kona.ccmc.gsfc.nasa.gov) to:
95a$3UzVC+M6

Sandro suggests using wolf4 to compile and run current analyses since our original system we used to do this (ono4) is about to be retired.

On 10/22/2012 I was able to ssh into bjackson@kona.ccmc.gsfc.nasa.gov from soft@cass188.ucsd.edu (bender). From there I ssh'ed into into 
bjackson@wolf4.ccmc.gsfc.nasa.gov and made two directories ipstd20n_in-situ, and smei-tom. From those directories on wolf4 I was able to 
copy files via sftp directly into the wolf4 bjackson/ipstd20n_in-situ and into bjackson/smei-tom from their respective directories on 
bjackson@cass188.ucsd.edu at bjackson/soft/for/development/ipstd20n_in-situ and bjackson/soft/for/development/smei-tom

On 10/22/2012 I was able to compile a version of smeiipstd0n_intel3 on wolf4 using a modified Makefile and the fortran 77 PGI compiler on 
that machine. 

On 10/22/2012 I downloaded the current smei points files to a subdirectory to smei-tom/base on wolf4, and the nagoya yearly and daily 
files to smei-tom/nagoya/yearly and smei-tom/nagoya/daily respectively on wolf4

On 10/22/2012 I was able to compile a version of ipstd_20n_inp_mag on wolf4 using a modified Makefile and the fortran 77 compiler 
on that machine. The compiler needs the libcfitsio.a programs compiled in 'C' to work, but these added to the compile list do allow 
the program to compile. 

On 10/22/2012 the ipstd_20n_inp_mag_intel program got to Number of g-level time values and bombed in Time2YMD with an invalid month error. 
The compilation of the smeiipstd0n_intel3 programs bombs with the same error.

On 10/23/2012 with John's help I was able to get past the invalid month error ipstd_20n_inp_mag_intel by changing the call to the 
pgi compiler in the subroutine compiler.f and recompiling the ipstd_20n_inp_mag_intel program on wolf4 as:

subroutine compiler(f77id)
character	f77id*(*)
f77id = '_x86_64_Linux_pgi_10.6'
return
end

On 10/23/2012 the same fix applied to get_compiler.f in the smeiipstd0n_intel3 program on wolf4 as:

subroutine get_compiler(f77id)
character	f77id*(*)
f77id = '_x86_64_Linux_pgi_10.6'
return
end

The only thing required for the Linux machine is the _86_64 above, and the rest Paul used as an identifier. You can find out this compiler 
on any Linux machine by typing uname --all On wolf4 this provides a line
Linux wolf4.ccmc.gsfc.nasa.gov 2.6.18-194.11.4.el5 #1 SMP Tue Sep 21 05:04_09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

On 10/23/2012 the program runs with 
./ipstd_20n_inp_mag_intel nagoya=nagoya.[4],/home2/bjackson/dat/nagoya/yearly/ nso_noaa=nso_ktpk[4]_[3].fts,/home2/bjackson/dat/nso 
ace=acesw_[4].hravg,home2/bjackson/da
To work, the in-situ ace level zero data need to be placed in a directory off bjackson/da/, and the other files required by the 
program need to be placed in the directories as needed.

On 10/23/2012 I reckon the in-situ read subroutines could be fixed to all read the files with a wildcard ???? placed in the proper 
place defined by the main program. Another way is as on bender, by defining the location where the in-situ data are found on login
by defining a location $DAT. In this case:
./ipstd_20n_inp_mag_intel nagoya=nagoya,,yearly/ nso_noaa=nso_ktpk[4]_[3].fts,$DAT/nso ace=acesw_[4].hravg,$DAT/insitu/acesw_????.hravg 
should work, but it does not. To do this one needs to define the $DAT path in a .-rc shell script that usually runs on login.
in .-rc place
export DAT=/home2/bjackson/dat/

or else type the export directly. 
Once done the following works:
./ipstd_20n_inp_mag_intel nagoya=nagoya.[4],$DAT/nagoya/yearly/ nso_noaa=nso_ktpk[4]_[3].fts,$DAT/nso
 ace=acesw_[4].hravg,/home2/bjackson/da/acesw_????.hravg

On 10/23/2012 the only way I can get the above to work successfully is to make sure the path for the in-situ data is exactly 
the correct length, and ace=acesw_[4].hravg,home2/bjackson/da  At least this works. Also works is: 
ace=/home2/bjackson/da/acesw_[4].hravg Gurr!

On 10/23/2010 John mentions that export EPHEM="/path/to/ephem" in order for 
./smeiipstd0n_intel smei=base/*.* nagoya=nagoya.[4],$DAT/nagoya/yearly/
to work from the smei-tom directory on wolf4

On 10/24/2010 John mentions to:

export EPHEM="/raidwolf4/bjackson/data"
export DAT="raidwolf4/bjackson/data"

on logging in to wolf4. 

On 10/24/2010, I placed all the latest points files into a directory /home2/bjackson/data/base/. This works to run: 

./smeiipstd0n_pgi3 smei=/home2/bjackson/data/base/*.* nagoya=nagoya.[4],/home2/bjackson/dat/nagoya/yearly/

on a subdirectory /home2/bjackson/smei-tom/test/ on wolf4. The default program for CR2099 completed sucessfully.

On 10/25/2010, I typed uname --all on the Korean computer ucsd@set.iptime.org (password ucsd123$, port 9898) this provides a line
Linux ENLILserver 2.6.32-71.e16 #1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux