FAST Change Log
      ------------------

Version 1.01
8/3/96,NW  - Inserted subroutine list for this sourcecode file
8/6/96,NW  - Changed N60PR array index to an integer index N60
                to compile under Lahey F90 compiler
9/5/96,NW  - Modified routines for IMPLICIT NONE variable declaration
9/5/96,NW  - Commented out unused variables
9/12/96,NW - Modified RTHS to combine and reorder loops
9/16/96,NW - Add command line check for alternate user input file

Version 1.02M
10/10/96,NW - Modified INPUT for combined INP/IPT input file
10/11/96,NW - Modified YAWIN for combined INP/IPT input file
10/17/96,NW - Modified INPUT to pass interpolated values to YAWIN
                 for blade element data
11/08/96,NW - Modified for assignment of airfoil table IDs

Version 1.03M
12/3/96,NW  - Rearranged subroutines in alphabetical order
12/4/96,NW  - Moved Common blocks to include file
12/5/96,NW  - Added glossary for variables in COMMON

Version 1.04M
12/13/96,NW  - Inserted conditional compile blocks for 2 or 3
                 blade simulation
12/16/96,NW  - Removed double input for PCTRL and AILPHI
12/17/96,NW  - Corrected blade/towertop mass assignment for 3 blade
               configuration which caused out-of-bounds array ref.
12/26/96,NW  - Added fast_ad.cfg include file for compile options
12/26/96,NW  - Added sign-on message to subroutine BEGIN
12/26/96,NW  - Added second command line argument for input echo
               to subroutine BEGIN
12/26/96,NW  - Added input echo to subroutine INPUT
01/02/97,NW  - Added run time estimate
01/02/97,NW  - Disabled echo of misc. items to screen
01/07/97,NW  - Added sys_pcm.f for system dependent calls
01/07/97,NW  - Reworked command line argument handling
01/07/97,NW  - Remove unused variables
01/08/97,NW  - Updated "shouting" output
01/08/97,NW  - Added tabbed output option
01/08/97,NW  - Modified input of 3D turbulence file names.
   NOTE:  Currently FAST turb. file names are not used by
       by AERODYN subroutines.  Separate file names appear in the
       YAWDYN input section.  2D vs. 3D is controlled by NCOMP
       in aerodyn.inc.  Further reconciliation of turbulence
       handling between FAST and AERODYN is needed.
01/08/97,NW  - Modified standard output file names
01/09/97,NW  - Modified RTHS for improved calculation efficiency.
Version 1.05M
01/15/97,NW  - Modified LAYOUT and ZPRINT for single time history output
01/16/97,NW  - Altered output file names to ".SUM" and ".OUT" in BEGIN
01/16/97,NW  - Modified Screen Message in BEGIN
01/20/97,NW  - Modified run time estimate to include Date and Time
01/20/97,NW  - Modified BEGIN to use WR_NR for selected console output
01/20/97,NW  - Modified run control for time or rev base
01/21/97,NW  - Modified run length test for time base
01/22/97,NW  - Modified compiler directives to facilitate conversion to
                 to UNIX equivalent
01/24/97,NW  - Updates for compatibility with F77 for PCXL made in sys_sgi.for
01/24/97,NW  - Corrected array out-of-bounds reference in MOTION for Q()
                     when compiled for two blade configuraiton
01/24/97,NW  - Added run status for completed run.
Version 1.06M
02/09/97,NW  - Modifications to incorporate AERODYN10
02/09/97,NW  - Modified RTHS for call to GFOSUB
Version 1.07M
02/25/97,NW  - Renamed GFOSUB to ADSUB
Version 1.08M
02/26/97,NW  - Define Common block INPUTS
02/26/97,NW  - Remove pitch terms from element forces return by ADSUB
02/26/97,NW  - Modified MAIN, BEGIN, and INPUT for alt. run control
Version 1.09M
02/28/97,NW  - Modified SOLVER, RTHS and GNTORQ call to include REVFLAG for alt. run control
02/28/97,NW  - Modified INPUT to trap OSU FAST wind file operations
Version 1.10M
03/07/97,NW  - Added header lines to output, modified tabbed output
Version 1.11M
03/12/97,AW  - Modified blade damping calculations in subroutine COEFF
03/12/97,AW  - Updated include files for new blade damping calculations
03/12/97,AW  - Updated input file damping parameters to percent values
03/13/97,NW  - Revised end-of-run statistics reporting
03/13/97,NW  - Revise input file format for air density
03/14/97,NW  - Updated damping calculations in routine COEFF
03/14/97,NW  - Remove BEDSTL from input as it is not used by Aero_10
03/15/97,NW  - Correct damping calculations in routine COEFF
03/17/97,NW  - Reviewed workaround for MS-FPS DTIME bug under WIN95
               (Decided to disable runtime summary under WIN95 due to
                PORTLIB conflict in using DTIME and TIMEF)
03/18/97,NW  - Replaced omitted lines in routine COEFF to correct new damping calculations
Version 1.12M
04/01/97,NW  - Added GET_ARG_NUM to "sys_***.for"
04/01/97,NW  - Updated routien BEGIN to test for number of command line arguments
04/01/97,NW  - Revised divide-by-zero trap in RUNTIME in "sys_***.for"
04/01/97,NW  - Add call to OPEN_CON in main routine
04/01/97,NW  - Separate YDINPT block into character and numerical variables
04/02/97,NW  - Revise SETUP, LAYOUT, ZPRINT and OUTPUT common block for E format output
04/02/97,NW  - Altered screen output to use WR_SCR (and similar) routines
04/02/97,MLB - Corrections to routines COEFF and SHP
04/03/97,MLB - Corrections to LOADS, addition of HH wind speed and
               rotor power for output.  Minor cleanup of output names.
04/04/97,MLB - Modified time stuff printed to screen.  Did trig of
      CHI, DELTA3, and BETA in INPUT and saved values for
      use later.
Version 1.16:
05/09/97,MLB - Modified RTHS to unroll loops and clean things up.  Merged fast_ad2.inc
                  and fast_ad3.inc.
v1.16, 05/09/97, M. Buhl
 Modified RTHS to unroll loops and clean things up.  Merged fast_ad2.inc
 and fast_ad3.inc.

v1.17, 07/03/97, M. Buhl
 Akihiro Suzuki of Utah found that RH was not getting initialized in
 YAWIN, so we set it to RHFAST.  We also needed to subtract out this RH
 from the RELM calculation in the same routine.

v1.19, 10/29/97, M. Buhl
 Made mods necessary to port to DEC Visual Fortran.  Mostly date and time
 functions.  This version also incorporated all the fixes Akihiro Suzuki
 had for bugs he found while at the NWTC the summer of 1997.  Not all bugs
 have fixes though.

v1.20, 12-Mar-1998, M. Buhl
 Someone put a line into RTHS to set gravity to zero for debugging purposes,
 but forgot to take it out.  I took it out.

v1.21, 23-Apr-1998, M. Buhl
 Akihiro discovered that he had introduced a bug into subroutine INTERP when
 he added THETA to THETAS, but forgot to convert it to radians.  I multiplied
 theta by D2R to fix it.  This bug messed up the blade tip deflections.

v1.60a0, 14-May-1999  A. Wright
 Changes unknown.

v1.70mlb-a, 04-Feb-2000  M. Buhl, A. Wright
 We modified the output fields for the echo and summary files so that the
 fields were less likely to overflow.
 We changed the blade modal damping so that instead of entering one value for
 both flap modes and one for the edge mode, we now enter three values (one
 for each mode).

v1.70mlb-b, 04-Feb-2000  M. Buhl, A. Wright, K. Pierce
 We changed the sign on the yaw rate that is passed to AeroDyn so it agrees with
 the sign on the yaw angle in NEWTIME().
 We combined two do loops in the transformation to the blade coordinate system
 in ADSUB().

v1.70mlb-c, 08-Feb-2000  M. Buhl
 I changed the output format from E format to ES format.
 I added the ElPrn flag to common YDINPTC in fast_ad.inc so that it could be used
 ZPRINT to print element data.
 I changed a test for NOPRINT(I) in YAWIN_AD to ".NOT. NOPRINT(I)" so that it would
 print only those files for which NOPRINT was false.

v1.70mlb-d, 09-Feb-2000  M. Buhl, K. Pierce
 We redid the QCI transformation matrix.  It appears that a previous version was
 the correct one.
 We changed the use of SNGL() to REAL().

v1.70mlb-e, 10-Feb-2000  M. Buhl, A. Wright, K. Pierce
 We found that the TRANSF common block in adsub.for was not the same as the one in
 fast_ad.inc.  We fixed that and put a comment in both occurances that one cannot
 change one of them without changing the other.  This seems to have affected the
 aerodynamics when the turbine is yawed.
 Marshall redid some of ADSUB() to use variable names for wind vectors that were
 more meaningful.  He alo eliminated some unused code.

v1.70mlb-f, 10-Feb-2000  M. Buhl, K. Pierce, A. Wright
 We discovered that FAST_AD was echoing ZKYAW and ZCYAW instead of ZKTILT and ZCTILT
 to the echo file.
 We found that the output yaw moment included the inertial term, so we subtracted
 it from ZLOAD(14).  This way, the yaw moment is zero in the free-yaw case.

v1.70mlb-g, 10-Feb-2000  M. Buhl
 Made unknown changes.  I'm a bad boy...

v1.80mlb-a, 02-Mar-2000  M. Buhl, A. Wright
 We redid the braking sequence.  We added three new variables (TGOFF,
 TBRAKON, and TBRAKFUL) to the input file and to the DRIVE common block.
 We modified the shutdown sequence so that the generator is suddenly set
 to zero at time TGOFF, then at time TBRAKON, the brake starts to ramp up
 linearly to the torque QBRAKE, where is is fully engaged at time
 TBRAKFUL.  TO accomplish this, we modified GNTORQ() for the case where
 I4 = 4.

v1.80mlb-b, 06-Mar-2000  M. Buhl
 I commented out the stuff to terminate the simulation 2 seconds after
 the rotor stops for shutdowns in the main program.  I also made a
 trivial change to an unrelated error message. I increased the size of
 string Prog in ADSUN so that it could handle the longer program names
 used in AeroDyn v11.35.  I also added TRIM() calls to the Prog
 components to eliminate the extra spaces in the output. I added the
 brake torque into the MG(4,NAUG) calculation in RTHS().

v1.80mlb-c, 07-Mar-2000  M. Buhl
 In YAWIN_AD(), I found a line that set the AeroDyn hinge radius to zero
 for 2-bladed turbines. I have no idea why that was done, so I set it to
 FAST's hub radius.  I also found in the calculation of RELM someone had
 subtracted the hub radius from RELMTMP instead of adding it to it.
 Because RELMTMP are blade locations wrt the tip, the hub radius must be
 added in order to get the blade locations wrt the hub center.  When
 checking the blade radius to make sure that FAST_AD data agreed with
 AeroDyn data, the hub radius was not preconed.  We made it so it would
 be in the calculation.  In the calculation of the tip-loss constant, RL
 was set to RH+RELM*cos(PC), which seemed to add an extra RH, as RELM is
 wrt the hub center.  I also simplified the equation for the tip-loss
 constant.  In INPUT(), I modified the equation for RELMTMP so that it
 used the blade length instead of the blade+hub length.

v1.80mlb-d, 13-Mar-2000  M. Buhl
 I found out from Craig Hansen that RELM is supposed to be the distance
 from the the blade root, so I redid the RELM and RELMTMP calculations.
 I made the mods in fast_adt/input() and yawin_ad/yawin_ad().  Craig
 also pointed out the R goes from zero at the hub radius to 1 at the tip,
 so the new RELM equation accounts for that too.

v1.80mlb-e, 16-Mar-2000  M. Buhl
 I changed the output of the version information to generate the entire
 string in FAST_ADT.FOR\LAYOUT().  I also put TRIM()s around the version
 output in FAST_ADT.FOR\BEGIN() and FAST_ADT.FOR\ECHO().
 I increased NDR and NLD to 21 in fast_ad.inc.
 I made it so FAST_AD rings the bell when done by modifying the main
 program.
 I modified fast_adt.for\gntorq() so that if the magnitude of the rotor
 speed is < 0.1 rad/sec, then ramp it to zero at zero.  This prevents
 large bang-bangs in torque as the turbine comes to a stop.

v1.80mlb-f, 17-Mar-2000  M. Buhl
 I completely rewrote fast_adt.for\gntorq().

v1.80mlb-g, 21-Mar-2000  M. Buhl, R. Wilson
 With Bob's guidance, I modified fast_adt\rths() so that we add the
 generator inertia to the hub inertia when we have no drive train DOF
 and a non-constant rotor speed (i.e., generator model, startup, or
 shutdown).
 I modified fast_adt\fast() so output doesn't happen until t >= TSTRT.
 I modified fast_adt\motion() so azimuth is zero when blade 1 is up.  It
 had been mistakenly set for when it was down.

v1.80mlb-h, 24-Mar-2000  M. Buhl, K. Pierce
 Kirk discovered that generator power and torque weren't output correctly
 for all generator options.  To fix it, we modified RTHS(), LOADS(), and
 GNTORQ() in fast_adt.for.  In RTHS(), we modified the call to LOADS()
 so that it included the LSS speed on the gearbox side of the shaft.  We
 modified LOADS() so it receives the GBspd from RTHS().  We also moved
 the calculation of GB torque and Gen power to the end of the routine
 and calculated the values differently for different cases.  In GNTORQ(),
 we separated the calculation of TGEN into TELEC and TLOSS.  We calculated
 ElecPwr from TELEC.  We added ElecPwr to the DRIVE common block in fast_ad.inc.
 We also modified adsub.for\HHWIND() so that the hub-height wind speed
 and direction would work with FF wind files.
 In fast_adt.for\INITIAL(), we added a bit of code for initializing
 control for variable speed.  In fast_adt.for\GNTORQ() we added a call
 to vsgentrq.f\vsgentrq().  We also added the file vsgentrq.f to the
 project.  It contains the control logic for an example variable-speed
 controller without pitch control.

v1.80mlb-i, 28-Mar-2000  M. Buhl
 I cleaned up the output to the summary file some.  I modified
 fast_adt.for\ECHO() and COEFF().

v1.80mlb-j, 28-Mar-2000  K. Pierce, M. Buhl
 Kirk created a new vsgentrq.f\vsgentrq() that does a table lookup.  We
 also modified fast_adt\gntorq() so that the gearbox efficiency was used
 correctly.

v1.80mlb-k, 03-Apr-2000  K. Pierce
 Kirk realized that vsgentrq.f\vsgentrq() was called multiple times per
 time step, so he fixed it.

v1.80mlb-l, 04-Apr-2000  M. Buhl
 I changed the output of status to the screen so it happens once per
 second instead of once per revolution.  This eliminates the problem of
 no (or few) updates when the rotor is stopped or slowly rotating, as in
 a shutdown or startup.  I added the variable TLP to fast_adt.for\fast()
 and modified the IF test to work the new way.

v1.80mlb-m, 05-Apr-2000  P. Heh, M. Buhl
 Ping suggested a bunch of changes that were pasted from her version into
 the latest NWTC version.
 In fast_adt.for\begin(), she increased the size of the TINP, TOUT, and
 TOUT1 strings to 40 characters.
 In fast_adt.for\coef(), she changed the order of loop 140 so it goes from
 the tip inward.  She also made a few other changes for unknown reasons.
 In fast_adt.for\loads(), she changed the way the tower moments were
 calculated.
 In fast_adt.for\motion(), she set ZMOTN(6) to the yaw rate for 2-bladed
 machines, leaving it as blade 3 in-plane tip deflection.  Marshall is not
 sure he likes that.  The outputs should be reworked.  Ping also changed
 the azimuth output so it is zero at 90 degrees, which Marshall does not
 like and may change it back.
 In fast_adt.for\rths(), she elimiated two calls to trans().  She also
 changed the sign on FAERO(1).  She moved the calculation of the coulomb
 friction of the teeter hinge down in the routine.  She set F(NAUG)=TGEN.
 She redid the calculations of some of the transformation matrices and
 moved them around.

v1.80mlb-n, 05-Apr-2000  M. Buhl
 I changed fast_adt.for\motion() so that the azimuth is output as zero
 when the blade is straight up.

v1.80mlb-o, 06-Apr-2000  M. Buhl, K. Pierce
 We reworked the combined transformation matrices in fast_adt.for\trans()
 by generating the equations with Mathematica using the matrices in the
 fax we got from R. Wilson dated 10-Feb-2000.  We also put in IF tests
 for 2/3 blades so that we didn't assume delta-3 and teeter are zero for
 3-bladed turbines.  We checked delta-3 and it was never set to zero for
 the 3-bladed case, so it was an uninitialized variable and could take
 on any value left over in memory.  We suspect that the CVF compiler
 initializes memory to zero, but that isn't always the case.

v1.80mlb-p, 07-Apr-2000  M. Buhl, K. Pierce, A. Wright
 We redid the calculation of the tower-top moments in fast_adt.for\loads().
 We now use matrix algebra so it is easier to read.  We also changed the
 two DO 1530 loops in that routine to use separate ENDDOs.  We also
 removed the nacelle pitch inertia from the tower-top pitch and roll
 moments and added nacelle mass terms to them too.

v1.80mlb-q, 10-Apr-2000  M. Buhl, K. Pierce, P. Heh
 Ping said the change made in version 1.80mlb-m in fast_adt.for\rths()
 where she removed the calls to trans should have been done later in the
 routine.  I fixed it as she requested.  Ping had also suggested in the
 same version to change the sign on FAERO(1), but that gave us incorrect
 results, so we changed it back.

v1.80mlb-r, 10-Apr-2000  M. Buhl, K. Pierce
 We found that we were adding 90 to the azimuth for 2-bladed turbines, but
 270 for 3-bladed turbines.  They are now both 90.  This makes it so the
 azimuth reads zero when blade 1 is up.  I'll eventually add an input
 variable so the user can decide what to use.

v1.80mlb-s, 18-Apr-2000  M. Buhl, K. Pierce
 We found that the reported hub-height wind speeds were varying for constant
 winds.  It looks like the XGRND, etc. variables are stored in the FFWind
 module instead of aerodyn.inc.  So, we added a USE for the module to
 adsub.for\ff_wind().
 Buhl also rewrote the logic for the screen and summary-file output for
 blade and tower properties in fast_adt.for\coef().

v1.90mlb-a, 18-Apr-2000  M. Buhl
 I redid the specification of output parameters to work like YawDyn.
 Now, all output parameters are specified on a single line and are
 separated by commas or white space.  Because of the change in the input
 file, I raised the version number up a tenth.

-------------------------------------------------------------------------------
--------------------------- FAST v2. ------------------------------------------
-------------------------------------------------------------------------------

v2.00mlb-a, 25-Apr-2000  M. Buhl
 I removed the input parameters that have been superceded by AeroDyn from
 fast_adt.for, fast_ad.inc, yawin_ad.for, adsub.for, and the input files.
 These parameters were VWIND, ETA, ISHR, ITRB2D, ITRB3D, IWNDIR, and
 IAIRFO.

v2.10mlb-a, 26-Apr-2000  M. Buhl
 I renamed the file for the main code to FAST_AD.for.
 I made a bunch of changes to fast_ad\begin() to eliminate the use of
 the user?.inp files.  The input data file name is now entered on the
 command line.  If none is entered, then "fast_ad2.inp" or "fast_ad3.inp"
 is used instead.  The output files use the root name of the input file.
 This will make it easier to run a bunch of cases for version testing.
 I also made changes to fast_ad\begin() and fast_ad.for\fast() to improve
 the screen output a little.
 I moved the array START_TIME to fast_ad.inc so that we can include the
 start time in the summary file.

v2.10mlb-b, 27-Apr-2000  M. Buhl
 An input file Ping sent me wouldn't run in release mode, but did run in
 debug mode or in release when I put prints in the middle of the tower
 interpolation in fast_ad.for\interp(), so I rewrote the tower
 interpolation in modern Fortran.  That seemed to get it run, but it
 still bombed very early in the run.

v2.10mlb-c, 28-Apr-2000  M. Buhl, K. Pierce
 While debugging Ping's problem, we found that Akihiro had made changes
 to AeroDyn and the ADAMS gfosub.f\gfosub() and gfosub.f\newtime() that
 were not put into FAST_AD's adsub.for\adsub() and adsub.for\newtime().
 We made similar changes to adsub() and newtime().  Ping's model still
 bombs due to large teeter rates, but it runs further than it did before.

v2.20mlb-a, 02-May-2000  M. Buhl
 Ping pointed out a problem with how the teeter moments were generated.
 Apparently, a bug had been introduced a year ago that effected the
 teeter dampers other than the linear one.  I modified fast_ad.for\rths()
 to fix it.  While I was messing with that section of code, I decided to
 make the spring constant for the teeter hard stop an input parameter
 instead of hard coding it to 5.0e5, which may not be big enough for a
 multimegawatt turbine.  I had to modify fast_ad.for\input() to read it.
 I also added it to the SPRING common block in fast_ad.inc.  While fixing
 that, I noticed that there was a version of SPRING in yawin_ad.for\yawin_ad()
 that was hopelessly out of date.  I synched it with the one in fast_ad.inc.
 I also had to fix AERO, FMTOUT, and INERTIA.  I put warnings before each
 common block in yawin_ad() and their equivalents in fast_ad.inc telling
 folks not to change one without changing the other.  After running the
 test cases, it appears these incorrect common blocks were causing problems.
 It looks like FAST_AD is now agreeing better with ADAMS.
 I also moved the AWT-26/27-specific teeter damper into its own routine.
 I created usersubs.f\userteet() to hold a user-defined teeter damper
 routine. I decided that we should have a separate file for user-defined
 code.  I put dummy code (returns zero moment) in usersubs\userteet(),
 but put the AWT-26/27 model in osusubs.f\userteet() that I will send
 only to OSU.  I also renamed Kirk's variable-speed routine from
 vsgentrq() to UserGen() and put it in usersubs.f90 after converting it
 to modern Fortran.  That meant I had to modify the call to it in
 fast_ad.for\gntorq().

v2.20mlb-b, 02-May-2000  M. Buhl
 In yawin_ad.for\yawin_ad(), I eliminated the use of the EndTime variable
 and used TMAX instead.  Now we read in only what we need of the turbulence
 files.

v2.20mlb-c, 25-May-2000  M. Buhl, K. Pierce
 In fast_ad.for\inital(), we modified the section for variable-speed
 control systems so that it used the input value ZD(4) for the initial
 rpm instead of OMEG0.

-------------------------------------------------------------------------------
--------------------------- FAST v3. ------------------------------------------
-------------------------------------------------------------------------------

v3.00adw-a, 14-March-2001  A. Wright
  SUBROUTINE INPUT:  Added STRTPTCH here and in FAST_AD.INC - COMMON/TTIME as well
  as subroutine yawin_ad to read time to start pitch control.

v3.00adw-a, 14-March-2001  C. Hansen
  MAIN PROGRAM:  Added TFINPUT:  controller transfer function REAL declaration in main prog.

v3.00adw-a, 14-March-2001  A. Wright, C. Hansen
  MAIN PROGRAM:  Added call to subroutine PITCHCNTRL in main program after
  IF (ITH.GE.100) GOTO 30.  Subroutine PITCHCNTRL performs pitchcontrol to
  control torque or rotorspeed (depending on choice by user).

v3.00adw-a, 14-March-2001  A. Wright
  SUBROUTINE COEFF:  Removed declaration of XMTOP in subroutine COEFF and placed in FAST_AD.INC.

v3.00adw-a, 14-March-2001  OSU
  SUBROUTINE COEFF:  Removed FIRSTMOM and BLDCG stuff out of subroutine COEFF and added to
  different place (see documentation).  Also changed
  TMP=TENS+TDR*DRZFREE to TMP=TENS+0.5*TDR*DRZFREE.  Not sure which is
  correct.

v3.00adw-a, 14-March-2001  OSU
  SUBROUTINE COEFF:  Removed FIRSTMOM and BLDCG stuff out of subroutine COEFF and added to
  different place (see documentation).  Also changed
  TMP=PLOAD+1.*TM(J)*DXZFREE to TMP=PLOAD+0.5*TM(J)*DXZFREE.  Not sure which is
  correct.

v3.00adw-a, 14-March-2001  A. Wright
  SUBROUTINE COEFF:  Removed dependence on blade version in subroutine COEFF for FREQT(7)-FREQT(10)
  calculation.  XMTOP gets calculated for both blade versions and can be
  used for either in the addition to mass coefficient in denominator.

v3.00adw-a, 14-March-2001  OSU
  SUBROUTINE ECHO:  changed format number on WRITE(16,_) statement.  Changed
  903 format and removed 904-905 format statements.

v3.00adw-a, 21-March-2001  A. Hansen:
  SUBROUTINE GNTORQ:
    -  changed arguments passed to UserGen (Case 5 of gen torque
       calculation) so that TGEN is passed and returned instead of TELEC.
       Changed use of efficiencies in calculation of ElecPwr.  TGEN is the torque applied to the
       shaft by the generator.
    -  Added 6th option (Case 6 - input IZD(4)=5) for zero gen torq:  ideling.

v3.00adw-a, 14-March-2001  OSU?:
  SUBROUTINE INITAL:  changed stuff for Start Up case:
  changed to:  QD(4,NMX)=ZD(4)
,
               QD(4,1)=ZD(4)
,
               ZD(4)=0.0
  used to be:  ZD(4)=0.
               QD(4,NMX)=1.6*RPM2RPS
               QD(4,1)=1.6*RPM2RPS
               QD(4,1)=1.6*RPM2RPS
               Q(4,NMX)=PIOVR2
               Q(4,1)=PIOVR2

v3.00adw-a, 14-March-2001  A. Wright and A. Hansen:
  SUBROUTINE INPUT:  added input of PCHMODE and STRTPCH after THETA,
                     added SHAFTMOMLENGTH after DNM (DNM2 for 2-bld),
                     added TWRHTOFFSET after HS.

v3.00adw-a, 14-March-2001  OSU:
  SUBROUTINE INPUT:  added input of TIPBRAK1 and TIPBRAK2 after TBRAKFUL,
             added read-in of NSPAN and SPAN(I)- number of blade
             span stations at which bending moments will be output
             as well as the actual span locations.  Note:  these
             bending moments are in a frame aligned with the section
             chordline at that station, giving flapwise and chordwise bending
             moments instead of in-plane and out-plane moments.


v3.00adw-a, 14-March-2001  OSU and A. Wright:
  SUBROUTINE INPUT:  changed maximum number of columns for motion and loads
      outputs to 60.  This shows up in the DO IN=2,60 do loop:  used to be
      DO IN=2,30.  In addition, added a couple of extra lines within this do loop and
      and changed 40 to 60.
      Also deleted format statements 2002 and 2004.
      Added format statement 2081 2083, 2093, and 2095.
      Deleted format statements:  2189, 2194 and 2203.
      Deleted various other format statements.

v3.00adw-a, 14-March-2001  OSU and A. Wright:
  SUBROUTINE INTERP:  changed tower interpolation loop from: DO J=1,NXTWR-1 to:
   DO J=0,NXTWR.  Also changed in tower interpolation,
   from:         DO I=1,3
                 P(I,NXTWR) = DTX(I,N2)
                 ENDDO ! I

   to:        DO I=1,3
              P(I,NXTWR) = DTX(I,N2-1)
              ENDDO !

   this allowed last interpolation point to be included in TM, TS7 and TS8.

v3.00adw-a, 14-March-2001  OSU:
  SUBROUTINE LAYOUT:  changed character declaration length for TITLE and UNITS
  from 330 to 660.  Made several other changes to allow 60 columns of outputs instead
  of 30.

v3.00adw-a, 14-March-2001  A. Wright, OSU, A. Hansen
  SUBROUTINE LOADS:  Major changes made to this subroutine!!!!!
     - Changed argument list in call to LOADS for both 2- and 3-bladed cases to pass
       XNNAC and XNHUB, quantities used in inertia force calculations.
     - deleted integer declaration of N1 and N2.  They are no longer used here.
     - changed declaration of BBM2 from BBM2(NB,3) to BBM2(NB,3,5).  Reason will be described later.
     - added REAL declaration for CC1A2(3),CC2A2(3).
     - deleted REAL declaration of SCBMOM and SCFFB.
     - Added REAL Declaration for THRUSTe2 and THRUSTe3.
     - Added REAL declaration for TwrTopMom and TwrBasMom, and XNNAC and XNHUB and YawShear.
     - Added REAL    "         "  LOCALPITCH, CPIT and SPIT.
     - Added initialization to zero for several variables:  TwrMom,...,InerFD.
     - Set ZLOAD(5) and ZLOAD(6) to zero for 2-bladed case.
     - Many loads and motions have different numbering now due to increased column output
       capacity.  Blade root shears and tension now ZLOAD(35)-(37).
     - Added calculation of flapwise and chordwise moments at 5 possible arbitrary span
       locations (moments are in a coord. system aligned with chordline, not in-plane and
       out-plane moments!).  This necessitates calculation of LOCALPITCH- the total pitch angle
       at a section due to rigid body pitch (THETA) and aero twist TW(_,_).  In-plane and
       Out-of-plane moments are then transformed to the chordwise system.  Span locations
       are specified in FAST_AD.inp file via NSPAN and SPAN(i).
     - Eliminated one do loop (DO K=1,NB) after statement YADJ = Q4.  Repositioned ENDO statements
       to compensate.
     - Changed TwrMom calculation to reflect no do loop structure.
     - Added calculation of ShaftMom, RotorThrust, and YawShear in same loop as TwrMom.
     - Changed shaft bending moments (now ZLOAD(25) and ZLOAD(26)) from old fixed frame
       coordinates (c-system) to bending moments rotating with shaft (now e-system).
     - Add calculation of shaft bending moments (in rotating frame) at a distance SHAFTMOMLENGTH
       toward the yaw axis from the hub center.
     - Likewise:  shaft forces (ZLOAD(20) and (21)) now in rotating coord. system.
     - Added misc. transformation matrices:  CC1A2, CC2A2 for use in calculating various
       loads.
     - Modified tower top longitudinal moment (ZLOAD(23)) to include the effects of moment due to shaft thrust
       acting at a distance of TWRHTOFFSET above yaw bearing as well as inertia forces of nacelle
       and hub (inertia forces due to tower motion) acting at that distance.  Did not yet add these
       effects to tower later bending moment.
    -  Subtracted out inertia terms due to hub from Yaw Moment at yaw bearing (ZLOAD(30)).
       Before we just subtracted out effects due to nacelle moment of inertia.
    -  Added calculation of shear forces at yaw bearing.
    -  Added calculation of tower base bending moments.  Done one way if tower rigid,
       and other way (using modal method by A. Hansen) if the tower is flexible.  Added
       intermediate calculation of InerFC and InerFD.
    -  Note negative sign on tower base lateral moment ZLOAD(40) - same as sign as  TwrBasMom(1).
    -  Expression for electrical power under Case (1) was modified to apply gen. efficiency and fixed torque loss.


v3.00adw-a, 14-March-2001  A. Wright, OSU, A. Hansen
  SUBROUTINE MOTION:
    -  ADDED declaration of I, CTHETA, STHETA, and TEMP.
    -  Changed ZMOTN(19) from nacelle Absolute Tilt angle
       to Nacelle Tilt angular velocity.  Changed ZMOTN(20) to blade 1 pitch angle.
    -  Set ZMOTN(17)-(19) to zero for 3-bladed case.
    -  Rotated blade tip displacements to the in-plane and out-of-plane coord. system.

v3.00adw-a, 14-March-2001  A. Wright, OSU, A. Hansen
  SUBROUTINE RTHS:
    -  deleted declaration for N60.
    -  changed declaration of BBM2(NB,3) and BBMI2(NB,3)to BBM2(NB,3,5) and BBMI2(NB,3,5).
    -  added declaration of QPITCH:  transformation to effect blade stiffness change with pitch
       change.
    -  Changed declaration of UB2(3) to UB2(5,3), since we now will do for 5 different possible
    -  user selected span stations - printout of blade flapwise and chordwise moments.
    -  added declaration of XNHUB and XNNAC.
    -  commented out calculation of N60PR and N60.
    -  added transformation of U via the calculation:  U = MATMUL(U,QPITCH).
       also added UB2 = MATMUL(UB2,QPITCH).  Also added UD = MATMUL(UD,QPITCH).
    -  added calculation of drag due to tip brakes.
    -  added transformation of XN by QPITCH.
    -  added calculation of loads at intermediate (user defined) blade stations.  added
       calc of BBM2 defined at user selected (up to 5) stations.
    -  added calculation of XNHUB and XNNAC.
    -  added XNHUB and XNNAC in argument list in call to loads.

v3.00adw-a, 14-March-2001  A. Wright, OSU, A. Hansen
  SUBROUTINE SETUP:
    -  Changed PARAMETER statement: PARAMETER(NLD=21) to PARAMETER(NLD=42).
    -  Changed TMOTN(19,1) to 'Tltvel' - Nacelle tilt angular velocity and
       changed TMOTN(20,1) to 'Bl1pitch' - blade 1 pitch angle.
    -  Changed TMOTN(17,1)-TMOTN(19,1) to be undefined for 3-bladed case.
    -  Changed TMOTN(20,1) to blade 1 pitch.
    -  Changed all corresponding TMOTN(_,2) values to reflect needed new units.
    -  Changed TLOAD(7,1)-TLOAD(16,1) to be intermediate blade span station section
       flapwise and chordwise bending moments.
    -  Made several other changes to reflect modified load numbering and units.

v3.00adw-a, 15-March-2001  A. Wright, OSU, A. Hansen
  SUBROUTINE ZPRINT:
    -  Changed REAL declaration of ZC to ZC(60).
    -  Miscellaneous changes as documented in subroutine to allow extra columns.

v3.00adw-a, 15-March-2001  OSU
  FUNCTION REW: OSU added this function for tip brake coefficient.


v3.00adw-a, 15-March-2001  A. Hansen, A. Wright and OSU
  FAST_AD.INC: OSU added this function for tip brake coefficient.
    -  changed statement to:  PARAMETER  ( NLD= 42 ) for extra loads outputs.
    -  added variables SHAFTMOMLENGTH, TWRHTOFFSET, SPAN, and STRTPCH.
    -  added TIPBRAK1 and TIPBRAK2.  Added TCNT and XMTOP.
    -  changed declaration of NC to NC(60).
    -  added variable (integer) PCHMODE and NSPAN.
    -  placed these new variables in common blocks:  AERO (PCHMODE), DRIVE (TCNT,TIPBRAK1 and TIPBRAK2),
       INTEGR (NSPAN), MASS (XMTOP), OUTPUT (SPAN), SHAFT (SHAFTMOMLENGTH and TWRHTOFFSET),
       TTIME (STRTPCH),

v3.00adw-a, 15-March-2001  A. Hansen, A. Wright and OSU
   SUBROUTINE YAWIN_AD.FOR:
    -  added INTEGER declarations for NSPAN, PCHMODE.
    -  added REAL declarations for STRTPCH.
    -  changed common blocks AERO, INTEGR, and TTIME to include these new variables
       and to duplicate same common blocks found in FAST_AD.inc.

v3.00adw-a, 21March-2001  OSU
   FUNCTION SHP
    -  Included refined modeshape function so that for x = 0, correct 2nd derivative of shape function
       will be calculated (previously, this was set to zero if x was small).  This resulted in correct
       stiffness coefficients for the blade and tower.  Previously, since at x=0, the second derivative
       of the shape function was set to zero, resulting in incorrect stiffness coefficients for the tower
       and blades (the stiffness coefficients were too small).

v3.00, 26-Mar-2001  M. Buhl
 I cleaned out all the alpha-version comments.  I also stripped all the
 logic from PitchCntrl() to create the free-form Fortran file PitchCntrl.f90.
 I renamed Alan's version of the pitch control file to PitchCntrl_ADW.for
 (fixed-form Fortran).  Users can use his version as an example.  We should
 get Craig's version for an additional example.
 I cleaned up a lot of the indenting throughout fast_ad.for to make it more
 readable.

v3.01a-mlb, 02-Apr-2001  M. Buhl
 When I printed out the wind direction for the first time, I noticed that
 it had the opposite sign that was input in the wind file.  I changed
 adsub.for\hhwind() to negate the VY term before computing the ATAN2().
 While I was messing with adsub.for, I cleaned out all the old alpha
 comments and fixed up the indenting to make it easier to read.

v3.01b-mlb, 19-Apr-2001  M. Buhl
 Jason Jonkman found that printing out element files did not work.
 In PrtElem.f\OpenElem(), the variable Prog was not dimensioned large
 enough to handle the enlarged Version variable, so I set it to 99 to
 handle most anything.  I also put TRIM()s around all the substrings in
 the Prog equation to eliminate internal spaces in the resulting string.
 Jason also pointed out that the tower mass displayed on screen and in
 the summary file did not match his calculations.  That's because the
 value being printed out is really the tower-top mass.  I changed the
 WRITE statements in FAST_AD.for\COEFF() to fix that.  While there, I
 also fixed the WRITE statements for the blade mass to use the term
 "mass" instead of "weight."
 Jason's keen eyes also spotted an error in the element data.  For the
 end nodes of the blade, the area is only half what it is for the interior
 points, but the code used the standard area.  I modified the calculation
 of the DRs in yawin_ad.for\yawin_ad() to make the end DRs half that of
 the interior ones.  After fixing that, I found the test for consistency
 between the DRs and the Rs no longer worked.  For FAST_AD, because
 the program sets these parameters, there is no need to test them, so
 I disabled that test.
 I tried changing adsub.for\hhwind() back the way it was before version
 3.01a-mlb to see if that was really correct.

v3.01c-mlb, 19-Apr-2001  M. Buhl
 I was wrong.  I had to change adsub.for\hhwind() back the way it was for version
 3.01a-mlb.

v3.01d-adw, 19-Apr-2001  A. Wright
 Added declaration of TwrAccel and revised call to subroutine PITCHCNTRL
 in Program FAST in order to use Craig Hansen's PID pitch control subroutine.
 Added Craig Hansen's PID pitch control subroutine.

v3.01e-mlb, 06-Nov-2001  M. Buhl
 I added TwrAccel to the dummy pitch control routine, PitchCntrl.f90\PitchCntrl().

v3.01f-mlb, 26-Nov-2001  M. Buhl, P. Heh
 Ping says we took out her tip-brake logic from the AeroDyn portion of
 FAST_AD.  I copied the logic from her version to our latest version of
 the code.  I modified aerosubs.f\elemfrc() and adsub() and initial() in
 adsub.f to put her logic back in.  We'll have to get Windward to put
 this logic into AeroDyn 12 when they interface it with FAST.
 I changed all the Cs at the beginnings of lines with !s so that I could search
 for the variable C.  I did this to fast_ad.for, yawin_ad.for, aerodyn.inc,
 aerosubs.f, and adsub.for.
 In fast_ad.for\input(), I eliminated the IndPrint and NFOILTMP variables.  In
 that routine I used a more-efficient method to see which blade stations should
 be output to the element file, so I no longer needed IndPrint.  I also eliminated
 the airfoil interpolation, so I no longer needed NFOILTMP.  We now assume the
 specified airfoil stations are located at the NR+1 interpolated blade stations.

v3.10a-mlb, 27-Nov-2001  M. Buhl
 I added two new switches to the switches section of the input file.  They are
 CompAero and Gravity.  I added the CompAero variable to the Aero common blocks
 in fast_ad.inc and yawin_ad.for\yawin_ad().  In fast_ad.for\input(), I added the
 logic for the two new inputs.  In fast_ad.for\rths(), I put in a IF statement to
 test the CompAero flag.  If false, I set the aero forces to zero.

v3.10b-mlb, 27-Nov-2001  M. Buhl, J. Jonkman
 In FAST_AD.for\COEFF(), we removed the generalized mass term from the calculation
 of the blade frequencies with centrifugal stiffening for the edgewise direction.
 Also in COEFF(), we improved the integration of the generalized stiffness of the
 blades and tower.

v3.10b-mlb, 28-Nov-2001  M. Buhl, J. Jonkman
 I replaced all STOP statements with CALL EXIT (1) for errors.  I added a CALL EXIT (0)
 for normal completion in the main program.  This will allow scripts to determine if
 the program ran to completion.  I also eliminate all PAUSE statements.  Many files and
 routines were affected.
 In fast_ad.for\loads(), I fixed the equation of the shaft moments to use the correct
 thrust components and include gravity terms.  We still need to add inertial effects.
 I added a RotMass variable to the fast_ad.inc\MASS common block.  I assigned it a value
 [WAIT(NB+1)] in fast_ad.for\coef().
 While messing in loads(), I realized that trig functions were being calculated many
 times.  I decided to calculate them at the beginning of the routine and save them for
 later use.  I created cq4, cq5, and sq4.
 Jason found that the blade span locations for output were being used as indices for
 arrays even though they were real numbers.  We put NINT()s around them in
 fast_ad.for\rths().
 When I tried to run without aero, the code bombed because it was calling
 aerosubs.f\hhwind() in fast-ad.for\motion().  I put an IF test around the call.
 I changed it so we don't read in a switch for gravity, but the actual value.  This
 will allow us to model turbines on Mars.

v3.20a-mlb, 19-Dec-2001  M. Buhl, J. Jonkman, A. Wright
 The yaw damping equation in fast_ad.for\RTHS() used to use the absolute value of the
 yaw rate.  We changed it so that the damping tends to resist the yaw motion.  We
 eliminated the no-longer-needed SGNQD6 variable.
 We eliminated the variable SNQD5 that was not actually used in the tilt equations.
 The equation for the Coulomb damping for the teeter hinge resulted in a non-zero
 value when the teeter rate was zero.  We put an IF test around it.
 In fast_ad.for\Teeter(), the quadratic teeter spring had an unusable zeroth term.  We
 considered converting it to a cubic by multiplying the equation by the teeter
 deflection.  The problem with this is that existing models will have to change the
 input files to move the coefficient for the linear spring from ZKTeet(2) to ZKTeet(1).
 Folks might not make this change for old models.  To prevent this problem, we decided
 to convert the spring to a purely linear spring with only a single coefficient.  We
 Converted ZKTeet to a scalar.  This required a change to to fast_ad.inc and also to
 fast_ad.for\INPUTS().
 I reworked the calculation of shaft loads in fast_ad.for\LOADS().  I'm still unhappy
 with it.
 Also in LOADS(), I redid the initialization of some arrays in F90-style.

v3.20a-mlb, 20-Dec-2001  M. Buhl
 In fast_ad.for\inital(), I rewrote the unreadable block of code under "Drivetrain
 flexibility" that inititalized the drivetrain state variables.  It still doesn't make
 sense.  In doing so, I created a new parameter called DT_DOF for the drivetrain DOF
 that goes in fast_ad.inc.

v3.20b-jmj, 03-Jan-2002  J. Jonkman
 In fast_ad.for\COEFF() I reversed the sign of the structural pretwist angle, THETAS(),
    when defining the twisted shape functions, BF().  Like rigid body pitch, THETA, and
    aerodynamic twist, TW(), THETAS() should be positive towards feather, not stall.
 The transformation matrix for rigid body pitch, QPITCH(), was defined correctly in
    fast_ad.for\RTHS(), but was used incorrectly throughout the subroutine.  In RTHS()
    I reversed the order of matrices and vectors in the transformations that involved
    the MATMUL function and QPITCH().  This effected the transformation of variables
    U(), UB2(), UD(), and XN().
 I fixed the calculation of the I-P and O-P tip deflections in fast_ad.for\MOTION().
    The previous transformation was incorrect since it only included rigid body pitch
    effects and the transformation used the wrong sign convention for THETA.  The new
    transformation includes effects from rigid body pitch, THETA, and structural twist
    at the tip through the use of values of the twisted shape functions at the tip,
    BF(:,:,NR,0).  To do this bug fix, REAL variable TEMP was removed and REAL
    variables UTIP and VTIP were added to MOTION().

v3.20c-jmj, 10-Jan-2002  J. Jonkman
 In fast_ad.inc, I reDIMENSIONed arrays AKT(), AMT(), TWRMT(), and TWRST() as (7:10)
    instead of (10) since the elements 1 through 6 are unnecessary.
 In fast_ad.for\COEFF(), I reDIMENSIONed the first index of BFSUM() to be 2 instead
    of 3 since the last dimension wasn't used.
 In fast_ad.for\INPUT() I moved the statement "IF ( ECHOFLAG )  WRITE(19,2262)  NC(IN),
    IN" placed soon after line 32 to the end of the DO...LOOP.  We dont want the
    output channel ID printed unless it is a valid channel.
 The statements "IZ(2)=IZ(1)", "IZ(12)=IZ(11)", and "IZ(14)=IZ(13)" from fast_ad.for\
    INPUT() for a 2-bladed turbine were moved to INITAL() to match the pattern of a
    3-bladed turbine.
 I deleted an unnecessary section of fast_ad.for\INITIAL() that sets the initial speed
    of the induction generator equal to ZD(4).  The code for all cases but fixed-speed
    should be identical.
 In fast_ad.for\SETUP(), I set the titles of motion output channels 17 through 19,
    TMOTN(17 to 19,1), to 'Undefined ' for a 3-bladed turbine.  Similarly, I set the
    titles of load output channels 5 and 5, TLOAD(17 to 19,1), to 'Undefined ' for a
    2-bladed turbine.  The previous titles of these output channels made no sense!
 In fast_ad.for\SETUP(), I set the titles of load output channels 19 through 21,
    TLOAD(19 to 21,1), to 'RotThruE1 ', 'RotThruE3 ', and 'RotThruE2 ' respectively so
    that the titles match the actual orientation of the outputs.  The previous titles
    reflected the 'C' instead of the 'E' reference frame (these loads are actually
    output in the e-vector triad, not the c-vector triad).
 The "!MS$if BLADE_VERSION == 2 / !MS$else / !MS$endif" criteria around the definition
    of XNN(:,6) in fast_ad.for\RTHS() is unecessary, so I deleted it.
 In fast_ad.for\RTHS(), I fixed the definition of the radial velocity of point S on the
    blade relative to the reference frame fixed in the hub, UD(3).  This velocity was
    previously being doubled.
 I added an NINT() around the SPAN(L) in the IF statement before the definition of
    local bending moment BBMI2() in fast_ad.for\RTHS().  I also changed the ".GE." to a
    ".GT." comparison since the moment arm UB2() should be zero if J = NINT(SPAN(L)).
 In fast_ad.for\RTHS(), I redid how the generalized elastic and damping forces for the
    blades are added to GN().  Before this change, the possible variation in stiffness
    and damping for the different blades were being completely ignored.  I re-rolled
    this DO...LOOP while fixing this bug.

v3.20c-jmj, 22-Jan-2002  J. Jonkman
 In fast_ad.for\RTHS(), I removed the unecessary placements of MG(L1,L2) and MG(L1,NAUG)
    on the right hand side of the initial definitions of these array element entries for
    the 3-bladed turbine configuration.  The definition of these array element entries
    for a 3-bladed turbine now matches more closely to that of the 2-bladed turbine.
 The tower mass and stiffness tuners, TWRMT() and TWRST() respectively, needed to be
    applied to every instance of the generalized mass and stiffness of the tower, AMT()
    and AKT() respectively.  Thus, I added the tuners into the definition of the
    generalized properties in fast_ad.for\COEFF() and removed their usage in RTHS().
 The "!MS$if BLADE_VERSION == 2 / !MS$else / !MS$endif" criteria around the definition
    of XN(:,6) for the hub in fast_ad.for\RTHS() is unecessary, so I deleted it.
 Variables TEMP1, TEMP2, and TEMP3 in fast_ad.for\RTHS() are assigned values soon after
    line 1440, but never used.  So I deleted their assignment.
 The original nacelle partial velocity for yaw, XN(:,6) was wrong in fast_ad.for\RTHS()
    since it appended an additional "-COS(CHI)" to the cross product of the vector b2
    (= d2) with the position vector b/n point O (tower-top) and point D (nacelle c.g.).
    The "cos(CHI)-effect" should already be taken into consideration in the
    transformation to the c-vector triad from the d-vector triad.  I revised this.
 I defined XNNAC(:,L) [= XMNAC * XN(:,L)] for a 2-bladed turbine in fast_ad.for\RTHS()
    just like it is defined for 3-bladed turbine.  This variable was used in LOADS()
    but never defined for a 2-bladed turbine.
 I cleaned up the code in fast_ad.for\RTHS() a bit where the portions of MG() associated
    with non-accelerating DOFs are zeroed-out.

v3.20c-jmj, 23-Jan-2002  J. Jonkman
 I reversed the order in which the blades are looped-through when summing loads in
    fast_ad.for\LOADS() to match the way it is done it RTHS().  Now the loop starts with
    blade NB and works its way down to blade 1.
 In fast_ad.for\MOTION(), I added 90 degrees to output 14 (generator azimuth angle) just
    as is done with output 13 (rotor azimuth angle).  Before this change, it must have
    looked really funny comparing this two azimuth positions because they would have
    always been offset by about 90 degrees.
 When calculating the generator azimuth position for a 2-bladed turbine, DOF Q5 was used
    instead of Q15 in fast_ad.for\MOTION().  I fixed this DOF reference.

v3.30a-jmj, 23-Jan-2002  J. Jonkman
 In fast_ad.for\GAUSS(), I redefined the size of the augmented matrix, A(), and the
    solution vector, X() so that they use the input number of rows, N, instead of being
    fixed in size with regards to NDOF and NAUG.
 Some changes I made in fast_ad.for\INITAL() required that the twisted shape functions
    from COEFF() be defined before INITAL() is called.  (see a change documented later)
    Thus, I moved the call to INITAL() directly after the call to COEFF() in the main
    program from INPUT().
 I added the variables ZOOP and ZIP to the variable declarations in fast_ad.inc.  These
    represent the initial OoP and I-P blade tip displacements respectively.  These
    variables replace the specification of the initial flap and edge blade tip
    displacements in the main FAST_AD input file respectively (i.e., ZOOP and ZIP are
    specified in the main input file instead of Z(1) and Z(1+NBE)).  As part of this
    change, I made FAST_AD read-in and echo-out these variables inplace of Z(1) and
    Z(1+NBF2).  To do this, changes were made in fast_ad.for\INPUT() and ECHO().
    I added variables ZOOP and ZIP to COMMON block /INITCN/.

v3.30a-jmj, 24-Jan-2002  J. Jonkman
 Marshall changed the teeter spring to a purely linear spring in fast_ad.inc for
    version 3.20a but forgot to update it in yawin_ad.for\YAWIN_AD().  So I defined the
    teeter spring constant as ZKTEET instead of ZKEET(3) in yawin_ad.for\YAWIN_AD().
    Bad Marshall! :-)
 In fast_ad.for\INITAL() I wrote code to base the intial values of the blade DOFs on
    ZOOP and ZIP instead of Z(1) and Z(1+NBE), the latter of which are no longer read in
    from the input file.  If the specified initial tip displacements are incompatible
    with the enabled DOFs, the code will calculate a "suitable" initial displacement and
    a warning message is written to the screen informing the user that the actual
    initial displacements are different than the specified initial displacements.  While
    making this change I fixed the error in INITAL() so that the initial displacements
    are now applied to ALL of the blades.  To do this change and bug fix I added REAL
    variables A(2,3), CTHETA, DET, INITQE1, INITQF1, INITQF2, STHETA, and TOTRESIDUAL to
    INITAL() along with CHARACTER PARAMATERs APPROX, BADZIP, BADZOOP, IGNORE, and
    INCOMPATIBLE.

v3.30a-jmj, 25-Jan-2002  J. Jonkman
 FAST_AD models the blades and tower as contilever beams where the first term describing
    the mode shapes must be X^2 instead of X.  All of the equations built into FAST_AD
    are derived from the fact that the linear term, PC(*,1) is zero, whether or not the
    user specifies these elements to be in fact zero.  If user actually speficied a non-
    zero linear term for any of the mode shapes, his/her analysis would be seriously
    screwed up.  Thus, I eliminated the linear term of the mode shapes from the input
    file.  To do this change, in fast_ad.inc I reDIMENSIONed the array containing the
    mode shape polynomial coefficients to PC(5,2:6) from PC(5,6).  I also fixed the
    starting index of the counters that work with this array from 1 to 2 in
    fast_ad.for\INPUT() and SHP().  I also cleaned up function SHP() to make it clearer
    to follow.
 In fast_ad.for\COEFF(), I improved the integration of the curvature of the blades to
    find the twisted shape functions, BF(:,:,:,0), and their first derivatives,
    BF(:,:,:,1).  I also improved the integration of SPHI().  The values of these
    variables at the hub (J=0) must be zero since there is no linear term in the
    polynomial describing the mode shapes!  To do this change, I added REAL variables
    SPHI1(3,3) and SPHI2(3,3) to COEFF() while removing variables BFSUM(), SUMSP(), and
    FD.
 In fast_ad.for\SOLVER(), I deleted the unecessary call to RTHS(), which was made after
    ILAST is set to 0 and before the Adams-Moulton corrector formula is applied.  This
    call to RTHS() was not necessary since the only variables changed within RTHS() were
    variables that were passed to LOADS().  However, LOADS() is not called when ILAST is
    set to 0 so the call to RTHS() was, in essence, doing absolutely nothing.  I ran the
    CertTest before and after I deleted this unecessary call and there was absolutely no
    change in the results.  It also improved the speed of the solution by about 30%!
 In fast_ad.for\RTHS(), the definition of UB2(L1,3) was wrong.  Before my change,
    UB2(L1,3) was defined as the difference in the undeflected location of point S
    (point S') on the blade and station L1 for local moment outputs in the i3-direction.
    This change defines UB2(L1,3) to be the difference in the deflected location of
    point S (point S') on the blade and station L1 for local moment outputs in the
    i3-direction.  This required the use of SPHI() evaluated at NINT(SPAN(L1)) to find
    the deflected distances in the i3-direction.

v3.30a-jmj, 28-Jan-2002  J. Jonkman
 In fast_ad.for\RTHS(), I initialized the partial velocities of point S on the blade,
    XN(:,:), to zero at the beginning of the K-loop.  Before this change, there was
    unfavorable coupling b/n the individual blades in the equations of motion (i.e., the
    MG() matrix) since the partial velocities of blade 2 where not being deleted before
    calculating the terms associated with blade 1.  This change allowed me to delete the
    DO 1250 LOOP in RTHS() which was not fully eliminating the cross-coupling b/n the
    blades in the equations of motion.  It also allowed me to delete the setting of
    XN(:,15) to 0.0 for a 2-bladed turbine which was made directly before the DO 1280
    LOOP in RTHS().
 In fast_ad.for\RTHS(), I added in !MS$else case after the definition of the partial
    angular velocity of hub due to tilt for a 2-bladed turbine, XW(:,5), to insure that
    XW(:,5) for a 3-bladed turbine is zero.

v3.30b-mlb, 30-Jan-2002  M. Buhl
 In fast_ad.for\Motion(), I replaced the equations for ZMOTN(13) and ZMOTN(14) and the
 following IF tests that forced values to be between 0 and 360 by wrapping a MOD(stuff,360)
 around the equation. Now, just in case the number ever gets greater than 720, we'll get a
 good result.
 I changed subroutine INITAL() to INITIALIZE() because it caused confusion.  I wanted to
 call it INITIAL, but AeroDyn already owned that name.

v3.40a-mlb, 01-Feb-2002  M. Buhl
 I changed the pitch variable THETA to an array so we can now support individual blade
 pitch.  This required changes to fast_ad.inc, yawin_ad.for\YAWIN_AD(), several
 routines in fast_ad.for (ECHO(), Initialize(), INPUT(), LOADS(), and MOTION()), two
 routines in PitchCntrl_ACH.for (PITCHCNTRL() and CTRL4()), and PitchCntrl\PitchCntrl().
 I removed the MOD() stuff I put in in v3.30b.

v3.50a-mlb, 04-Apr-2002  M. Buhl
 I completely rewrote fast_ad.for\Input() and moved it to fast_io.f90.  I made it so
  both two- and three-bladed turbines use the same input files.  I also rearranged many
  of the parameters.  I added many new parameters.
 I moved most of the tower, blade, and AeroDyn parameters to separate files.
  The main input file now includes names of files containing the data.
 I moved all input parameters to modules in fast_mods.f90.
 I moved all variables in fast_ad.inc to modules in fast_mods.f90:
 I renamed some input variables:
   AMSFAC         to AdjBlMs
   AMSTWR         to AdjTwMa
   Beta           to PreCone (make it a scalar because of AeroDyn?)
   CBLD           to BldDamp
   CDATIP         to TBDrCon
   CDATIPB        to TBDrConD
   CDATIPN        to TBDrConN
   CDrv           to DTTorDmp (now defined on HSS side)
   Chi            to NacTilt
   CInGen         to SIGSlope (now entered as a negative number)
   COULMB         to TeetCDmp
   CTEET          to TeetDmp
   CTWR           to TwrDamp
   DN             to OverHang
   DNM            to ParaDNM
   DNM1           to ParaDNM
   DNM2           to PerpDNM
   ETAGB          to GBoxEff
   ETAGEN         to GenEff
   HINER          to HubIner
   HS             to TwrRBHt
   HSINER         to GenIner
   HTINER         to NacTIner
   HYINER         to NacYIner
   ITSPDM         to TeetDMod
   N1             to NBlInpSt
   N2             to NTwInpSt
   NC             to OutList
   NCMAX          to NumOuts
   NSPAN          to NBlGages
   NTSkip         to DecFact
   Omeg0          to GenSpZT
   OmegR          to GenSpRat
   PchMode        to PCMode
   QBrake         to ShftBrkT
   QCTEET         to TeetDmpP
   QKSTOP         to TeetHSSp
   QKTEET         to TeetSStP
   QKTSTOP1       to TiltSSSp
   QKTSTOP2       to TiltHSSp
   QMotor         to SIGMotT
   RH             to HubRad
   RLU            to UndSling
   RT             to TipRad
   SHAFTMOMLENGTH to ShftGagL
   SPAN           to BldGagL
   STEFAC         to AdjEdSt
   STFFAC         to AdjFlSt
   STFLAT         to AdjSSSt
   STFLNG         to AdjFASt
   STRTPCH        to TPCOn
   TBRAKFUL       to TShBrFl
   TBRAKON        to TShBrDp
   TGOff          to TimGenOf
   Theta          to Pitch
   TILTSTOP1      to TiltSStP
   TILTSTOP2      to TiltHStP
   TIPBRAK1       to TTpBrDp array
   TIPBRAK2       to TTpBrFl array
   TipM           to TipMass
   TITLE          to FTitle
   TSTOP          to TeetHStP
   TSTRT          to TStart
   TWRHTOFFSET    to Twr2Shft
   TWRMT1         to TwrMaT1
   TWRMT2         to TwrMaT2
   TWRST1         to TwrStT1
   TWRST2         to TwrStT2
   XMHub          to HubMass
   XMNac          to NacMass
   XX             to HtFract
   YN             to GBRatio
   ZCTILT         to TiltDamp
   ZCYAW          to YawDamp
   ZIP            to IPDefl
   ZKDrv          to DTTorSpr (now defined on HSS side)
   ZKTEET         to TeetSSSp
   ZKTILT         to TiltSpr
   ZKYAW          to YawSpr
   ZOoP           to OoPDefl
 I eliminated some input variables
   CHDFAC
   EL
   EPP
   HH             (Now calculated internally as: ShaftHt = TowerHt + Twr2Shft)
   IAW            (It didn't actually get set to anything anywhere.  I left code that assumed it was zero)
   IDynSt
   IShad
   NR             (inputing BldNodes in AeroDyn input instead)
   NWR            (It was used with IAW)
   NXTwr          (inputing TwrNodes instead)
   RLUM           (Now calculated internally as: HCM2TPin = UndSling - HubCM)
   TWIFAC
   TWSFAC
 I added some input variables:
   AerCen
   Echo
   GenModel
   GenTiSt
   HubCM
   NumBl
   RatRotSp
   Reg2TCon
   Reg3ConT
   SimVSGen
   SpdGenOn
   TabDelim
   TimGenOn
 I eliminated some internal variables
   I4             (replaced by GenModel and GenDOF)
 I renamed some internal variables and/or moved them to fast_mods.f90:
   BM             to BMD (it conflicted with an AeroDyn variable)
   CDATIP         to TBDrCon
   COS_BETA       to CosPreC
   COS_DEL3       to CosDel3
   COS_CHI        to CosTilt
   DR             to DelRad (only FAST version of DR)
   DT_DOF         to DOF_GeAz
   DX             to DelHt
   DXDZT          (moved only.  will be renamed FlTwrHt later)
   EchoFLag       to Echo (now an input variable)
   HH             to ShaftHt
   NLD            to NumLoads
   NDR            to NBlSeg (This used to be the dimensional value.  Allocated arrays don't need it)
   NR             to NBlSeg
   NXTwr          to NTwSeg
   PELEC          to ElecPwr
   R              to BldSt
   SIN_BETA       to SinPreC
   SIN_DEL3       to SinDel3
   SIN_CHI        to SinTilt
   SPHI           to AxRedShp (SPHI is used in AeroDyn)
   TabFlag        to TabDelim (now an input variable)
   TInp           to InpFile
   TOut to        to RootName
   TOut1          to OutFile
   TOutF          to SumFile
   TW             to AeroTwst (now bladed independent)
   TWRMT          to TwrMaT
   TWRST          to TwrStT
   YAW            to NacYaw
 I completely rewrote the main program and put the result in fast.f90\FAST().  I also
  rewrote fast.for\RunTime(), renamed it SimStatus() and put it in fast_io.f90.
 I created a new module called GenMod() and put it in a new file called fast_mods.f90.  To
  it I added UnEc as the unit for the echo file and UnIn as the unit for the input file.
 I removed all references to controlling the simulation by revolutions.  This entailed XXXXXXXXX.
 I eliminated the VERSION parameter from fast_ad.inc and copied Crunch's SetVersion.f90
  to set it there at run time so we won't have to recompile everything every time
  we change the version number.  I changed the variable name to ProgVer to be similar
  to our other codes.  I declare ProgVer in fast_mods.f90\GenMod().
 I copied Crunch's GenUse.f90 file to be used for FAST_AD.
 I replaced sys_pcd.for with Crunch's SysCVF.f90.  All reference to WR_SCR() were replaced
  with WrScr(), but I did not comment it in the code as they were zillions of them.
 I added a Thevenin-equivalent induction-generator model.
 Some kind soul put a TABFLAG=.FALSE. statement right before we write the output, so
  we couldn't get tab-delimited files any more.  I commented out their statement.
 I eliminated all references to revolutions for run-time control.
 I created a REAL function, Interp(), to do generic interpolations and put it in
  genuse.f90.
 I took all the logic in yawin_ad.for and put it in fast_io.f90\GetAero().
 Alan and I decided we would never run FAST with anything other than AeroDyn, so
  we deceided to call if just plain old FAST from now on.  I renamed all files
  and routines to reflect this.
 In sys_pcd.for, I removed the Str_Len() function and changed references to it to
 LEN_TRIM(), which is now a Fortran standard function.
 I took out sys_pcd.for and replaced it with a subset of SysCVF.f90, which mostly came
  with Crunch.
 I eliminated all the logic to print columnar data to the screen during execution.
 I removed the IMPLICIT NONE from fast_ad.inc because I like to see that statement
  in every routine.  You guessed it, I put the statement in every routine in every file.
 I removed the logic for generating the summary files from Input() and Coef(),
  rewrote it completely in F90, and it now resides in fast-io.f90\PrintSum().  I
  now call PrintSum() from FAST() just after the call to Coef().
 I removed all logic for echoing input to the screen.  Hopefully, the summary file
  will be sufficient.
 Because of the rewrite of the way we generate and prints the status of the simulation,
  we no longer use fast.for\LeapYear(), so I eliminated it.
 I renamed function REW() in fast.for to TBFract().
 I ensured that all routines in fast.for were in alphabetical order, but did not
  comment the moves.
 I added USE statements to almost all routines because so many variables are in
  modules now.
 I eliminated subroutine Setup() and now initialize the valid and invalid title
  strings in fast_mods.f90\Output().
 I renamed ZPRINT() to WrOutput(), moved it from fast.for to fast_io.f90, and
  rewrote it completely.
 I eliminated fast.for\GenConst().  Now, all but TwoPiNB are initialized in the
  type declaration statements in fast_mods.f90\Constants().  I calculate TwoPiNB
  in fast_io.f90\Input() just after the call to GetPrimary().
 I eliminated the call to yawin_ad() in adsub.for\adsub().
 As I worked on various section of fast.for, I rewrote some algorithms to make them
  more efficient or more readable.
 I changed all variable-length arrays to use dynamic memory allocation.  I eliminated,
  or converted to variables, most of the parameters used to define array length.  That
  includes NB, which was replaced by NumBl.
 I modified pitchcntrl.f90 and pitchcntrl_ach.f90 so that some of the parameters
  were removed from the argument list.  I also renamed all variables that I
  mentioned above.
 I changed UserGen so it no longer gets ZTime and DT from the argument stack, but
  from the SimCont() module.  I also changed it from passing the LSS speed to the
  HSS speed.  I calculate the LSS speed in the routine.
 I eliminated the variables TGen and TqBrak and replaced them with the combined
  GBoxTrq (of module Drivetrain()) in Loads() and RTHS().
 I added QT(5) to the Inputs() array that passes info from RtHS() to AeroDyn.  I
  redimensioned the array, inserted tilt to the middle and moved the others down.
 I moved the control logic in fast.f90\FAST() to a new routine, fast.f90\Control().
 I moved the logic for keeping the azimuth between 0 and 360 from FAST() to Solver().
 I changed all declarations for Flt2LStr to be C(15) and Int2LStr to C(11) in all
  files, including AeroDyn files.
 I added aerodynamic centers to the blade-property files.

v3.50b-jmj, 08-Apr-2002  J. Jonkman
 I renamed variables BadZIP and BadZOoP to BadIP and BadOoP respectively in
   FAST.f90/InitBlDefl() so they correlate better with input variables IPDefl and
   OoPDefl respectively.
 In FAST.f90/InitBlDefl() I replaced 2 tests of the FlapDOF2 switch to test the
   EdgeDOF switch instead.  The check on FlapDOF2 was incorrect originally.
 In FAST_io.f90/InterTwr() I added a REAL() around the tower index, Ind.
 In FAST_io.f90/GetTower() I changed the tolerance for the TopDispl from 0.01 to
   0.001 to match the tolerance of the blade mode shapes.
 In FAST_io.f90/Input() I added a calculation of AeroCent() for blade K /= 1 that
   Marshall must have missed.  Bad Marshall!
 In FAST_io.f90/Input() I removed the conversion of Azimuth and AzimB1Up to
   radians.  These variables are assumed to be in degrees later on in the code.
 In FAST_Subs.for/Initialize() I reversed the sign in front of AzimB1Up when
   defining the initial values of Q(4,:).  The code was previously incorrect with
   a plus sign.
 In FAST_Subs.for/MOTION() I made the output azimuth angles relative to the
   AzimB1Up position.
 In FAST_Subs.for/MOTION() I added the calculation of the output blade deflection
   for blade 3.  Marshall must have missed this when making his changes.
 In FAST_Subs.for/MOTION() I deleted the conversion of the ouput blade deflection
   of blade 1 to centimeters.  Marshall must have missed this when making his
   changes.

v3.50b-jmj, 09-Apr-2002  J. Jonkman
 Marshall made a couple of errors in the calculations of the coefficients used in
   the Thevenin equivalent circuit (TEC).  I fixed this by adding 2 variables in
   the fast_mods.f90/DriveTrain() model: TEC_Re1 (Thevenin's equivalent stator
   resistance) and TEC_Xe1 (Thevenin's equivalent stator leakage reactance).  I
   defined and used these in fast_subs.for/Initialize().  In this subroutine I also
   simplified the calculations by defining a local variable ComDenom, representing
   the common denominator of several TEC expressions.
 In FAST.f90/DrvTrTrq() I defined the electrical power, ElecPwr, to be zero when
   the generator is off line.
 In FAST.f90/DrvTrTrq() I made the electrical power equal to the mechanical power
   times the generator efficiency for simple variable-speed control since the
   generator torque is necessarily greater than zero (never-motoring).  Before,
   the mechanical power was divided by the generator efficiency.
 In fast_io.f90/Input() I converted the units of RatRotSp and Reg2TCon to reflect
   the HSS speed in rps.
 In FAST.f90/DrvTrTrq() I redefined GenTrq to use SlipRat instead of Slip for the
   TEC model.  I also input the correct equations for the electrical power, ElecPwr
   (the previous equation was incorrect).  To do this added REAL variables
   ComDenom, PwrLossS, PwrLossR, and PwrMec and COMPLEX variables Current1,
   Current2, and Currentm to DrvTrTrq().  The equations used to find ElecPwr were
   from Ed Muljadi of NREL.

v3.51a-djl, 15-Apr-2002  D. Laino
 Changed over to AeroDyn 12, and created new interface.  Deleted the following files
  from FAST:
   aerodyn.inc
   bedoes.inc
   adsub.for
   aerosubs.f
   modules.f
   prtelem.f
   sensub.f
  Added the following file to FAST:
   AeroCalc.f90
  AeroDyn 12.4 or higher must now be linked with FAST to create the executable.
 Removed the following routines in FAST as they are available in AeroDyn:
   Conv2UC
   CurDate
   CurTime
   Flt2LStr
   Int2LStr
 Renamed OpenOutFile to OpenFOutFile to reflect formatted output file.
  Changed calls accordingly in:
   SUBROUTINE GetPrimary
   SUBROUTINE PrintSum
   SUBROUTINE WrOutHdr
 Removed module AeroDyn from fast_mods.f90.  Removed references to it in:
   SUBROUTINE LOADS
   SUBROUTINE RtHS
   SUBROUTINE Input
   SUBROUTINE WrOutput
 Created Module AeroElem to store element info needed by AeroDyn.  Placed it in
   SUBROUTINE RtHS
 Removed these variables from SUBROUTINE RtHS:
   INTEGER      NPAR
   DOUBLE PRECISION  ATIME
   DOUBLE PRECISION  INPUTS(13)
   DOUBLE PRECISION  PAR( NPAR )
   DOUBLE PRECISION  VALUE
   REAL      ECKS
   REAL      RD
   REAL      WHY
   REAL      ZEE
   INTEGER      ID
   LOGICAL      IFLAG
   LOGICAL      DFLAG
 Renamed array RESULT to AeroForces and changed it from DOUBLE PRECISION to
  REAL.
 Moved VES(3) from local variable in RtHS to module AeroElem.
 Took out everything in the IF (ComAero) section of RtHS and replaced it with
  the call to the new routine AeroCalc in AeroCalc.f90.
 Changed arguments in call to XYZLoc.  The result is now placed in the vector
  ElAeroLoc(3) in module AeroElem, instead of in ECKS, WHY, ZEE in RtHS.
 The current element radius in stored in ElRad in module AeroElem.  It is
  updated before the call to AeroCalc in RtHS.
 Changed END statement in  CheckArgs to indicate it is the END of CheckArgs
  and not anything else (like the World - AAAAAAAAAAAAAAAAAAAAAAAAAARGH!!!)
 Elminated Subroutine GetAero from fast_io.f90, as AeroDyn 12 does it all now.
  Removed call to it in SUBROUTINE Input, and replaced with call to AeroInput.
 Got rid of requirement for identical precone on all blades in GetPrimary.
 Replaced call to PrtElem with call to OutputAero with argument ZTime in
  SUBROUTINE WrOutput.

v3.60a-jmj, 12-Apr-2002  J. Jonkman
 I renamed the FAST summary file from <RootName>.sum to <RootName>.fsm (for FAST
   summary) so it can't possibly conflict with other summary file names (like the
   <WindFile>.sum).
 In fast_mods.f90/Features(), I deleted the initalization of TiltDOF to .FALSE.
   since tilt will now be availabe for a 3-blader and therefore TiltDOF does not
   have to be initalized--it is read in instead [see change to fast_io.f90/
   GetPrimary()].
 I also made PerpDNM and NacTIner read in for a 3-blader in fast_io.f90/
   GetPrimary().
 In fast_io.f90/GetPrimary(), I made sure the nacelle tilt parameters are read in
   from the main FAST input file for a 3-blader turbine (previously, these were
   SkipComment'ed).  Also, now I convert TiltSStP and TiltHStP to radians in
   fast_io.f90/Input().
 In fast_io.f90/Input(), I defined NDOF to be 17 for a 3-blader (tilt is now the
   17th DOF for a 3-blader).
 I removed the calculation of SinTilt, MDNCC, and MDNMCC from fast_io.f90/Input().
 I moved the calculation of CosTilt in fast_io.f90/Input() so it is calculated for
   both the 2 and 3-blader configurations.
 I Deleted unused variables: MDNCC, MDNMCC, SinTilt
 I added variable INTEGER(4) DOF_Tilt (for the location of the tilt DOF) to
   fast_mods.f90/DOFs().  This is defined in FAST_Subs.for/Initialize().
 In FAST_Subs.for/Initialize(), I set the initial / fixed tilt angles to NacTilt
   for both 2- and 3-bladers.
 In FAST_Subs.for/Initialize(), I made TTDspSS act in the + yt dir'n (IEC
   coordinate system), which is the - a3 dir'n so it is consistent with the
   output channels.
 In fast_io.f90/GetPrimary(), I eliminated the check and Abort step when reading
   in the Azimuth value since the previous restrictions were unecessary.
 In fast_io.f90/GetPrimary(), I forced YawNeut to be between -180 and 180
   (inclusive) instead of simply greater or equal to zero.

v3.60a-jmj, 15-Apr-2002  J. Jonkman
 I rewrote FUNCTION SHP to eliminate the need for the PC array and moved it to
   fast_mods.f90/Modes() from FAST_Subs.for.  Now, the array with the shape
   function coefficients [ex, TwFAM1Sh(:)] is an input into FUNCTION SHP.
 I deleted unused variable PC(:,:).
 I made it so the units of RatRotSp and Reg2TCon reflect the LSS speed
   instead of the HSS per a suggestion by Lee J.  This required a change to
   FAST.f90/DrvTrTrq().  I also removed Reg3ConT from the primary input file
   since this can be found with both RatRotSp and Reg2TCon.  This is now
   calculated in FAST_Subs.for/Initialize().
 I moved BldNodes so that it is now read in from the AeroDyn.ipt file.
 I changed the limit on TwrNodes and BldNodes to be >= 1.
 I deleted unused variables: DXDZT, DelHt, FDelHt, FlTwrHt.
 I added variable TwrFlexL (length of flexible portion of the tower).

v3.60a-jmj, 16-Apr-2002  J. Jonkman
 When reading in HubRad in fast_io.f90/GetPrimary(), I added a check to see if
   HubRad >= 0.0.
 I deleted unused variable TBDepCSp(:) from the input and code.
 I moved variable TBDepISp(:) so that it is now read in from the Turbine
   Control section instead of the Tip Brake section.  Also, I moved its storage
   location to fast_mods.f90/TurbCont() from TipBrakes().
 I added variable TpBrDT (time for tip-brake to reach full deployment once
   released) to the primary input file.  It is located in the Tip Brake
   section.
 I removed variable TTpBrFl(:) from the input file.  It is now calculated in
   FAST_Subs.for/Initialize() using TpBrDT and TTpBrDp(:).
 I added the capability of allowing the user to switch all of the tower modes
   on/off independently by removing TwrDOF1 and TwrDOF2 and replacing them with
   TwFADOF1, TwFADOF2, TwSSDOF1, and TwSSDOF2.
 I renamed variables TX(:), TM(:), TS7(:), and TS(8) to HNodesNorm(:), MassT(:),
   StiffTFA(:), and StiffTSS(:) respectively.
 I added variables HNodes (height of tower nodes above the tower rigid base
   height) and DHNodes (length of the variable-lenght tower elements).
 I ALLOCATEd HNodes(:), DHNodes(:), HNodesNorm(:), MassT(:), StiffTFA(:), and
   StiffTSS(:) using TwrNodes instead of NTwSeg and adjusted the code accordingly.
 I deleted unused variable: NTwSeg.
 I deleted unused variables: DelRad, FDelRad, and NBlSeg.
 I added an additional dimension to AxRedShp(:,:,:) (now it is AxRedShp(:,:,:,:))
   since this is now a function of the blade #
 I renamed variable BldLen, BldNLoc(:,:), BMD(:,:), BS(:,:), BE(:,:), and
   BF(:,:,:,:) to BldFlexL, RNodesNorm(:), MassB(:,:), StiffBF(:,:), StiffBE(:,:),
   and TwistedSF(:,:,:,:,:) respectively.
 I ALLOCATEd AxRedShp(:,:,:,:), RNodes(:), DRNodes(:), RNodesNorm(:), MassB(:,:),
   StiffBF(:,:), StiffBE(:,:), and TwistedSF(:,:,:,:,:), AeroTwst(:), Chord(:),
   AFoilIDs(:), PrnElm(:), AeroCent(:,:), and ThetaS(:,:) using BldNodes instead of
   NBlSeg and adjusted the code accordingly.
 I moved the check on BldGagNd(:) till after AeroInput() is called in fast_io.f90/
   Input() from GetPrimary() since BldNodes is now read in from the AeroDyn.ipt
   file and is needed for this check.
 I convert RNodes(:) so that it is relative hub before interpolating the blade
   data.

v3.60a-jmj, 17-Apr-2002  J. Jonkman
 I removed the undocumented teeter damper model 2 (TeetDMod = 2)from the
   FAST_Subs.for/Teeter() routine.  I made TeetDMod = 2 the user-defined teeter
   damper selection and documented this throughout the sample input files.
 I added a check in fast_io.f90/GetBlades() to see if StrcTwst(:) is between -180.0
   and 180.0.
 In fast_io.f90/SimStatus(), I made the output text more descriptive.  This
   originally confused Dave Laino :-).
 I added SUBROUTINE CheckRComp() which checks to see if RNodes(:) and DRNodes(:)
   are compatible w/n a millimeter; if not, FAST aborts.
 I removed RRGap entirely and replaced it with INTEGER PSpnElN (number of the
   innermost blade element which is part of the pitchable portion of the blade
   for partial-span pitch control devices).  This feature is still unavailabe by
   the code (the logic to handle it is not in place yet).

v3.60a-jmj, 18-Apr-2002  J. Jonkman
 I added the ACTION='READ' specifier to the OPEN statement in
   GenUse.f90/OpenInFile().
 In PitchCntrl_ACH.for/PitchCntrl() and CTRL4() and UserSubs.f/UserVSCont() I
   replaced the OPEN statement with a call to the OpenInFile() SUBROUTINE.
 I removed variable TEC_NPha from the primary input file and hardcoded it to 3
   phases throughout the code.
 I added almost 200 INTEGER(4), PARAMETERs to fast_mods.f90/Output() which will be
   used as the indices for computing output loads.
 I added INTEGER(4), PARAMETER :: MaxOutPts (the maximum possible number of output
   channels able to be outputted by the code) to fast_mods.f90/Output().
 I changed OutList(:) to a CHARACTER(10) array (it was an INTEGER(4) array) and
   DIMENSIONed it as OutList(MaxOutPts).  I changed how OutList(:) is used
   throughout the code.  I added a variable OutInd(:), which acts somewhate like
   OutList(:) use to act as (an array of indices for OutData(:)).
 I deleted unused variable InvPar, NumInv2, NumInv3, NumLoads, NumMotns, NumParms,
   ZLoad(:), ZMotn(:), InvPar2(:), and InvPar3(:) from fast_mods.f90/Output() and
   throughout the rest of the code.
 I changed how OutParam(:) (listing of names and units of all output channels) is
   used throughout the code.
 In fast_io.f90/GetPrimary(), I made OutLine a CHARACTER(1000) variable instead of a
   CHARACTER(100) variable:
 I added variables NumWords, EndOfFile, and CountWords to and removed variable
   OutPFmt from fast_io.f90/GetPrimary().

v3.60a-jmj, 19-Apr-2002  J. Jonkman
 I added variable SttsTime (amount of time between screen status messages) to the
   primary input file and to fast_mods.f90/OutPut().  I used this variable in
   FAST.f90/FAST().
 I added SUBROUTINE ChckOutLst() which checks to see if any inputted output channels
   (stored in the OutList(:)) are ill-conditioned (and if so, FAST Aborts) and
   assigns the settings for OutInd(:) and OutParam(:) (i.e, the index, name, and
   units of the output channels, OutData(:)).

v3.60a-jmj, 22-Apr-2002  J. Jonkman
 In fast_mods.f90/Output() I added INTEGER(4) variable OutSign(:), which is used to
   determine whether or not the sign of an output channel is reversed.  The value of
   this variable is either be +1 (sign is normal) or -1 (sign is reversed).  This
   is ALLOCATEd and designated in fast_io.f90/ChckOutLst().

v3.60a-jmj, 23-Apr-2002  J. Jonkman
 Throughout the code I changed it so that RatRotSp and Reg2TCon reflect the HSS speed
   instead of the LSS speed.  In the process, I renamed RatRotSp to RatGenSp.
 I removed THSSBrFl from the primary input file.  This is now calculated in
   FAST_Subs.for/Initialize() using THSSBrDp and a NEW input variable, HSSBrDt (Time
   for HSS-brake to reach full deployment once initiated (sec)).  This new REAL(4)
   variable is now read in after HSSBrTq in the primary input file.
 In FAST_Subs.for/ I deleted COEFF(), LOADS(), and MOTION().
 I deleted RtHS.for/RtHS() and removed RtHS.for from the workspace.

v3.60a-jmj, 24-Apr-2002  J. Jonkman
 I deleted unused variables NBE, NBF2, NBLD(:), DOF_B1ED, and DOF_B2ED throughout the
   code.  I replaced these with INTEGER(4), ALLOCATABLE variables DOF_BE(:,:) and
   DOF_BF(:,:), which act as indices for the blade flap and edge DOFs.
 I deleted unused variables ACB(), AKB(), and AMB() and MODULE CoeffVars().
 I deleted unused variables NB1, NB2, and NB3.
 I replaced variables WAIT() and XMTOP with BldMass() and TwrTpMass respectively.
 I added REAL(4) variables RotIner (inertia of rotor about its centerline), Hubg12Iner
   (inertia of hub about its centerline (transverse to the cyclinder and
   passing through its c.g. = inertia of hub about the g1- and g2- axes)), Nacc2Iner
   (inertia of nacelle about the c2-axis), and Nacc3Iner (inertia of nacelle about the
   c3-axis) to fast_mods.f90/MassInert().
 I deleted unused variables DST7, DST9, TwrDamp(), TwrMaT(), TwrStT(), TwrSt1, TwrSt2,
   AKT(), and AMT().  I replaced the effect of AKT() with REAL(4) variables KTFA() and
   KTSS().
 I replaced variable FreqT() with variables FreqTFA() (fore-aft tower nat. freq.) and
   FreqTSS() (side-to-side tower nat. freq.).
 I added REAL(4) variables AxRedTFA() and AxRedTSS() (The axial-reduction terms for the
   fore-aft and side-to-side tower mode shapes respectively) and TwrMass (mass of tower)
   to fast_mods.f90/Tower().  The tower mass is now an output in <RootName>.fsm.  I also
   added REAL(4), ALLOCATABLE variables TwrFASF() and TwrSSSF() (the tower fore-aft and
   side-to-side shape functions respectively) to /Tower().  This is now ALLOCATEd in
   FAST.f90/Alloc().
 I deleted unused variables BLC(), BLK(), and BldDamp().  I replaced the effect of BLK()
   with REAL(4), ALLOCATABLE variables KBF() and KBE().  I replaced the effect of
   BldDamp() with REAL(4), ALLOCATABLE variables BldFDamp() and BldEDamp().
 I added REAL(4), ALLOCATABLE variables CBF() and CBE() (the generalized flapwise and
   edgewise damping of the blades respectively) to fast_mods.f90/Blades().
 I added REAL(4) variables CTFA() and CTSS() (the generalized fore-aft and side-to-side
   damping of the tower respectively) to fast_mods.f90/Tower().
 I renamed AxRedShp() to AxRedBld().

v3.60a-jmj, 25-Apr-2002  J. Jonkman
 I renamed primary input variable GenTiSt to GenTiStr.
 I added new LOGICAL(2) variable GenTiStp (Method to stop the generator {T: timed using
   TimGenOf, F: when generator power = 0} (switch)), which is now read in from the
   primary input file.  In order to use GenTiStp in FAST.f90/DrvTrTrq() I gave local
   variable GenOnLin the SAVE attribute and initialized it to .FALSE. and added the
   local, LOGICAL(2), SAVE variable Off4Good (is the generator offline for good?) and
   initialized this variable to .FALSE..
 I added REAL(4) variable FlStTunr(2) (Blade flapwise modal stiffness tuners), which is
   now read in from the blade input file, to fast_mods.f90/Blades().  I also added
   REAL(4), ALLOCATABLE variable FStTunr(:,:) (Blade flapwise modal stiffness tuners
   (stored for all blades)), which is defined in fast_io.f90/Input().
 In fast_io.f90/GetBlade(), I made sure the correct file name (BldFile(K)--not BldFile,
   PriFile, ADFile,...) was used throughout.
 When ECHOing out the distributed blade and tower properties in fast_io.f90/GetBlade() and
   GetTower(), I made it so "I" is printed out instead of "I-1" (recall I = 1,2,...,
   NBlInpSt or NTwInpSt).
 I added the deallocation of the distributed blade and tower properties to the fast_io.f90/
   InterpBld() and InterpTwr() subroutines respectively.  (Before this change the arrays
   were deallocated (that is, all but AerCen()) in the Input() subroutine.)
 I added SUBROUTINE FAST.f90/Coeff(), which is used to compute blade properties: KBF(),
   KBE(), CBF(), CBE(), FreqBF(), FreqBE(), AxRedBld(), TwistedSF(), BldMass(), FirstMom(),
   SecondMom(), BldCG(), RotMass, RotIner, Hubg12Iner, rSAerCenj1(), and rSAerCenj2();
   tower properties: KTFA(), KTSS(), CTFA(), CTSS(), FreqTFA(), FreqTSS(), AxRedTFA(),
   AxRedTSS(), TwrFASF(), TwrSSSF(), TwrMass, and TwrTpMass; nacelle properties: Nacc2Iner
   and Nacc3Iner; and generator properties: GenDir.

v3.60a-jmj, 26-Apr-2002  J. Jonkman
 I deleted the LOGICAL(1) DynStall variable from fast_mods.f90/Features since it is already
   stored in AeroDyn().
 I added RotMass and RotIner to the .fsm file in fast_io.f90/PrintSum().
 In fast_io.f90/GetPrimary() I made it so Delta3 is limited3 to be between -90 and 90
   exclusively.
 I added TipNode (the index of the additional node located at the blade tip = BldNodes + 1) to
   fast_mods.f90/Blades().  I defined this in FAST_Subs.for/Initialize() and use it to ALLOCATE
   AxRedBld() and TwistedSF().  I adjusted FAST.f90/InitBlDefl() so that the augmented matrix
   used to solve for the initial blade tip deflections (A) uses the value of the twisted shape
   functions at the blade tip (TipNode) instead of the last analysis point (BldNodes).
 I added TTopNode (the index of the additional node located at the tower-top = TwrNodes + 1) to
   fast_mods.f90/Tower().  I defined this in FAST_Subs.for/Initialize() and use it to ALLOCATE
   AxRedTFA(), AxRedTSS(), TwrFASF() and TwrSSSF().

v3.60a-jmj, 30-Apr-2002  J. Jonkman
 I added a comment line labeled "Blade Parameters" before NBlInpSt is read in from the BldFile.
   This is more consistent with the TwrFile.
 I added LOGICAL variable CalcTMode (Calculate tower mode shapes internally (T: ignore mode
   shapes from below, F: use mode shapes from below) (switch)) to the tower input file.  This
   variable is CURRENTLY IGNORED by the code.  Similarly, I added LOGICAL variable CalcBMode
   (Calculate blade mode shapes internally (T: ignore mode shapes from below, F: use mode shapes
   from below) (switch)) to the blade input file.  This variable is stored internally as LOGICAL,
   ALLOCATABLE variable CalcBModes().  This variable is CURRENTLY IGNORED by the code.  All of
   these variables are stored in fast_mods.f90/Modes().
 I incorporated David Laino's FAST v3.51a-djl changes to v.360a-jmj (see a "3.51a-djl, 15-Apr-2002
   D. Laino" above for a listing of these changes).
 I made the SUBROUTINEs in the AeroCalc().f90 file in alphabetical order.  I did this without
   further documentation.
 I removed unused variable CosTilt from fast_mods.f90/TurbConf().
 I added REAL(4), ALLOCATABLE variables AeroTwst() and Chord() to fast_mods.f90/Blades().
 I ALLOCATE (to BldNodes) FAST variables RNodes(), DRNodes(), Chord(), and AeroTwst() and transfer
   the data from AeroDyn into these variables in AeroCalc/f90/SetFAST_Params().
 In AeroCalc.f90/Set_FAST_Params() I define FASTHH using STILT instead of SinTilt since variable
   SinTilt has been removed and its data is now stored in STILT.

v3.60a-jmj, 01-May-2002  J. Jonkman
 I linked AeroDyn version 12.45 into FAST.  This version now requires that the blade and element
   loops take place in a normal order (K = 1,NumBl; J=1,BldNodes), not the reverse way.
 I made it so GBoxEff and GenEff must now be read in as percentages instead of fractions.  These
   are now converted to fractions in fast_io.f90/Input().  To complete this change I had to USE
   fast_mods.f90/DriveTrain() in Input().
 I convereted the units of TBDepISp(:) to RPS in fast_io.f90/Input().

v3.60a-jmj, 02-May-2002  J. Jonkman
 I added REAL(4) FUNCTION DotProd() and SUBROUTINE CrossProd() to FAST.f90.
 I removed unused REAL(4), ALLOCATABLE() variables BBM(), BBM2(), BBMI(), BBMI(), BMom(), BMomI(),
   CI(), CZ(), FF(), FFB(), GC(), GCI(), GN(), GNI(), MG(), QDD(), XN(), XNHUB(), XNN(), and
   XNNac() from fast_mods.f90/RtHndSid(), FAST.f90/Alloc(), and FAST_Subs.for/Solver().
 I eliminated all of the passed parameters to RtHS() since none of them where needed any more.
 I removed unused INTEGER variable ILAST from FAST_Subs.for/Solver().
 I moved the ALLOCATEion of the ZK() arrays in FAST_Subs.for/Solver() to the biggening of the
   Runga-Kutta portion of the code.  Now the ALLOCATEion will only occur during the first few
   time steps.  These variables don't need to ALLOCATEd for the Adams-Bashforth solver!
 I renamed the FK() matrix which holds the accelerations of the DOFs to QD2().  I also renamed
   the F() array which holds the solution vector from RtHS() (i.e., the acceleration vector) to
   QD2T().
 I added REAL(4) variable TeetAng (current teeter angle = QT(3) for 2-blader or 0 for 3-blader
   (this is used in place of QT(3) throughout RtHS().) to fast_mods.f90/RtHndSid().  This is
   defined at the beginning of RtHS().

v3.60a-jmj, 03-May-2002  J. Jonkman
 I removed unused SUBROUTINEs TRANS() and XYZLOC() from FAST_Subs.for/ and unused MODULE
   Transforms() from fast_mods.f90/ and all of its associated REAL(4) variables: QAD(), QAI(),
   QBI(), QCI(), QDI(), QEI(), QFI(), and QGI().
 I added SUBROUTINE FAST.f90/RtHS(), which is used to compute and solve the equations of motion
   for a particular time step.
 I added MODULE fast_mods.f90/CoordSys(), which is used to store the coordinate sytems used
   internally by FAST.  This MODULE stores REAL(4) variables a1(), a2(), a3(), b1(), b2(), b3(),
   c1(), c2(), c3(), d1(), d2(), d3(), e1(), e2(), e3(), f1(), f2(), f3(), g1(), g2(), g3(), and
   ALLOCATABLE variables i1(), i2(), i3(), and j1(), j2(), and j3().  The ALLOCATABLE variables are
   ALLOCATEd in FAST.f90/Alloc().  All of these variables are defined in a new SUBROUTINE I added
   entitled FAST.f90/SetCoordSy()
 In fast_io.f90/Input() I define Delta3  = 0.0, CosDel3 = 1.0, and SinDel3 = 0.0 for a 3-blader.
   These are used in FAST.f90/SetCoordSy().
 In fast_io.f90/Input() I convert the values of BlPitchF() to radians.

v3.60a-jmj, 06-May-2002  J. Jonkman
 I added new input variables REAL(4) TiDynBrk (time to initiate deployment of the dynamic generator
   brake) and CHARACTER(99) DynBrkFi (name of file containing dynamic generator brake properties).
   TiDynBrk is stored in fast_mods.f90/TurbCont() and DynBrkFi is stored in fast_mods.f90/
   General().  Both variables are CURRENTLY UNUSED by the code.
 I added REAL(4), ALLOCATABLE variables PAngVelEB(:,:,:), PAngVelEG(:,:,:), PAngVelEH(:,:,:),
   PAngVelEL(:,:,:), and PAngVelEN(:,:,:) (the partial angular velocities (and there 1st time
   derivatives) of the base plate (body B), generator (body G), hub (body H), low-speed shaft
   (body L), and the nacelle (body N) in the inertia frame (body E for earth)) to
   fast_mods.f90/RtHndSid().  Similarly, I added REAL(4), ALLOCATABLE variables PLinVelEC(:,:,:),
   PLinVelED(:,:,:), PLinVelEJ(:,:,:), PLinVelEO(:,:,:), PLinVelEP(:,:,:), PLinVelEQ(:,:,:)
   PLinVelES(:,:,:,:,:), and PLinVelET(:,:,:,:) (the partial linear velocities (and there 1st time
   derivatives) of the hub center of mass (point C), nacelle center of mass (point D), yaw / shaft
   axis intersection point (point J), base plate (point O), teeter pin (point P), apex of rotation
   (point Q), point on a blade (point S) and point on the tower (point T) in the inertia frame
   (body E for earth)) to fast_mods.f90/RtHndSid().  I also added REAL(4), ALLOCATABLE variables
   rQS(:,:,:) (position vector from the apex of rotation (point Q) to the a point on a blade (point
   S), rS0S(:,:,:) (position vector from the blade root (point S(0)) to a point on a blade (point
   S)), rT(:,:) (position vector from ground to a point on the tower (point T)), and rT0T(:,:)
   (position vector from a height of TwrRBHt (base of flexible portion of tower) to a point on the
   tower (point T)) to fast_mods.f90/RtHndSid().  These are ALLOCATEd in FAST.f90/Alloc() and
   defined in RtHS().
 I added REAL(4) variable rO(3) (position vector from ground to tower-top / base plate (point O))
   to fast_mods.f90/RtHndSid().  This is defined in FAST.f90/RtHS().
 I added INTEGER(4) variable GenDir to fast_mods.f90/DriveTrain(), which is the Direction of the
   generator = +/- 1 (+ 1 = same direction as LSS; -1 = opposite direction of LSS).  This is now
   defined in FAST.f90/Coeff().

v3.60a-jmj, 07-May-2002  J. Jonkman
 I added REAL(4), ALLOCATABLE variables LinAccESt(:,:,:) (portion of the linear acceleration of a
   point on a blade (point S) in the inertia frame (body E for earth) associated with everything
   but the QD2T()'s) and LinAccETt(:,:) (portion of the linear acceleration of a point on the
   tower (point T) in the inertia frame (body E for earth) associated with everything but the
   QD2T()'s) to fast_mods.f90/RtHndSid().  I also added REAL(4), ALLOCATABLE variables
   PFrcS0B(:,:,:) (partial force at the blade root (point S(0)) due to the blade), FrcS0Bt(:,:)
   (portion of the force at the blade root (point S(0) due to the blade associated with
   everything but the QD2T()'s), PMomH0B(:,:,:) (partial moment at the hub (body H) / blade root
   (point S(0)) due to the blade), and MomH0B(:,:) (portion of the moment at the hub (body H) /
   blade root (point S(0)) due to the blade associated with everything but the QD2T()'s) to
   fast_mods.f90/RtHndSid().  I also added REAL(4), ALLOCATABLE variables FSAero(:,:,:) (the
   aerodynamic force per unit span acting on a blade at point S), FSTipDrag(:,:) (the aerodynamic
   force at a blade tip resulting from tip drag), MHAero(:,:,:) (the aerodynamic moment per
   unit span acting on a blade at point S), PFrcPRot(:,:) (partial force at the teeter pin (point
   P) due to the rotor), PMomLPRot(:,:) (partial moment at the teeter pin (point P) on the
   low-speed shaft (body L) due to the rotor), PFrcONcRt(:,:) (partial force at the yaw bearing
   (point O) due th the nacelle, generator, and rotor, PMomBNcRt(:,:) (partial moment at the
   base plate (body B) / yaw bearing (point O) due the nacelle, generator, and rotor), and
   PMomNNcRt(:,:) (partial moment at the nacelle (body N) / yaw-shaft axis intersection (point J)
   due the nacelle, generator, and rotor) to fast_mods.f90/RtHndSid().  These are ALLOCATEd in
   FAST.f90/Alloc() and defined in RtHS().
 I added REAL(4) variables FrcPRott(3) (portion of the force at the teeter pin (point P  ) due to
   the rotor associated with everything but the QD2T()'s), MomLPRott(3) (portion of the moment
   at the teeter pin (point P) on the low-speed shaft (body L) due to the rotor associated with
   everything but the QD2T()'s), FrcONcRtt(3) (portion of the force at yaw bearing (point O) due
   to the nacelle, generator, and rotor associated with everything but the QD2T()'s),
   MomBNcRtt(3) (portion of the moment at the base plate (body B) / yaw bearing (point O) due to
   the nacelle, generator, and rotor associated with everything but the QD2T()'s), MomNNcRtt(3)
   (portion of the moment at the nacelle (body N) / yaw-shaft axis intersection (point J) due the
   nacelle, generator, and rotor associated with everything but the QD2T()'s), LinAccEOt(3)
   (portion of the linear acceleration of the base plate (point O) in the inertia frame (body E
   for earth) associated with everything but the QD2T()'s), and GBoxEffFac (the factor used to
   apply the gearbox efficiency effects to the equation associated with the generator DOF) to
   fast_mods.f90/RtHndSid().  These are defined in FAST.f90/RtHS().

v3.60a-jmj, 08-May-2002  J. Jonkman
 I added REAL(4) variable RefHH (hub-height at the begining of the simulation (i.e., the reference
   hub height)) to fast_mods.f90/TurbConf().  I also added REAL(4) variable AirDens (air density
   = RHO) to fast_mods.f90/EnvConc().  I define these in AeroCalc.f90/Set_FAST_Params().
 In AeroCalc.f90/AeroCalc(), I made ElAeroFrc() hold the 3 values of the current element forces (2)
   and moment (1) per unit span in purely the AeroDyn coordinate sytem convention (see Appendix C
   of the AeroDyn user's guide for a definition of this convention).  Now FAST.f90/RtHS() handles
   the conversion from the AeroDyn coordinate system to FAST's coordinate system.
 I changed AeroCalc.f90/AeroCalc() so that FirstLoop and TIMFLAG are set properly when looping
   through the blades and elements in ascending order (instead of the screwy, reverse order).
 I added REAL(4), ALLOCATABLE variables rSAerCenj1(:,:) and rSAerCenj2(:,:) (distance from point S
   on a blade to the aerodynamic center in the j1- and j2-directions, respectively (m)) to
   fast_mods.f90/Blades().  These are ALLOCATEd in FAST.f90/Alloc() and calculated in Coeff().
 In AeroCalc.f90/GetVNVT() I changed the calculations of the wind velocity in the coned coordinate
   system to use i1(IBlade,:), i2(IBlade,:) instead of the recently deleted QAI() array.

v3.60a-jmj, 09-May-2002  J. Jonkman
 In AeroCalc.f90/GetBladeParams() I made AziAng refer to the current blade instead of just blade 1.
 In AeroCalc.f90/GetRotorParams() I made HubVDue2Yaw and TiltAngle depend on the new tilt DOF for
   a 3-blader (i.e., now I use QT(DOF_Tilt) instead of QT(5) and NacTilt).

v3.60a-jmj, 13-May-2002  J. Jonkman
 I added REAL(4), ALLOCATABLE variable AugMat(:,:) (which is the augmented matrix used for the
   solution of the QD2T()s in FAST.f90/RtHS).  This ALLOCATEd in FAST.f90/Alloc().

v3.60a-jmj, 14-May-2002  J. Jonkman
 When calculate GBoxTrq in FAST.f90/DrvTrTrq(), I made it so the gearbox efficiency effects are
   included in FAST.f90/RtHS() instead.

v3.60a-jmj, 15-May-2002  J. Jonkman
 I swiched the index for Tilt and GeAz for a 3-blader.  Now the Tilt DOF is 5 for both
   configurations and GeAz is 17 for 3-blader.  Now DOF_Tilt is no longer needed, so I deleted it.
 I added SUBROUTINE FAST.f90/CalcOuts(), which is used to compute the selected output channels
   (motions and loads) and place them in the OutData() array.  Now all of the output channels
   (both motions and loads) are calculated in this single SUBROUTINE.
 In fast_io.f90/WrOutput() I replaced the call to MOTION() with a call to CalcOuts().
 In fast_mods.f90/Output() I added REAL(4), ALLOCATABLE variables LinAccES(:,:,:) (total linear
   acceleration of a point on a blade (point S) in the inertia frame (body E for earth)),
   FrcS0B(:,:) (total force at the blade root (point S(0)) due to the blade), and MomH0B(:,:)
   (total moment at the hub (body H) / blade root (point S(0)) due to the blade).  These are
   ALLOCATED in FAST.f90/Alloc() and defined in CalcOut().

v3.60a-jmj, 16-May-2002  J. Jonkman
 I added REAL(4) variable ProjArea (swept area of the rotor projected onto the rotor plane (the
   plane normal to the low-speed shaft) to fast_mods.f90/TurbConf().  This is defined in
   fast_io.f90/Input() and is used in FAST.f90/CalcOuts().
 I moved variable GenTrq from FAST.f90/DrvTrTrq() to fast_mods.f90/DriveTrain().  To complete
   this change, I eliminated the passing of variable GenTrq into SUBROUTINE UserVSCont().

v3.60a-jmj, 17-May-2002  J. Jonkman
 I added REAL(4), ALLOCATABLE variables CThetaS(:,:) and SThetaS(:,:), which are the COS() and
   SIN() of ThetaS(:,:), respectively.  These are ALLOCATEd and defined in fast_io.f90/Input().
 In FAST.f90/Control(), I improved the calculations of TFInput and TwrAccel.
 In FAST.f90/Control(), I codified the logic for the override pitch manuever.  To do this, I
   added REAL(4), ALLOCATABLE variables TmpBlPitch(:) (the temporary value of BlPitch(:) upon
   entering SUBROUTINE FAST.f90/Control()), DelBlPitch(:) (the change in pitch that must occur
   during each time step for override pitch control), and FirstTHere(:) (.TRUE. before the
   override pitch manuever has begun (First Time Here)) to fast_mods.f90/TurbCont().  These new
   arrays are ALLOCATEd in FAST.f90/Alloc().
 In PROGRAM FAST in FAST.f90, I moved the CALL to Control() to a point after the time step is
   advanced and after WrOutput() is CALLed.  This is because it uses values of the DOF that
   reflect the advanced time step.  Also, it also shouldn't change the value of BlPitch before
   outputing it in WrOutput().

v3.60a-jmj, 21-May-2002  J. Jonkman
 I renamed primary input variable HSSBrTq (fully deployed HSS-brake torque (N-m)) to HSSBrTqF
   so there are no internal naming conflicts.

v3.60b-jmj, 30-May-2002  J. Jonkman
 I converted outputs HorWndDir and VerWndDir to degrees in SUBROUTINE FAST.f90/CalcOuts() (they
   where previously in radians, which was incorrect).  Thanks Craig for finding this bug.

v3.60c-mlb, 31-May-2002  M. Buhl
 I linked FAST with the new AeroDyn v12.46 and decided we needed to include the
  AeroDyn version in the output file.  I modified fast_io.f90\WrOutHdr() to USE
  AeroDyn's Identify module and added a write statement.  Because I added an
  extra line to the output file, I had to modify the Crunch parameter files to
  skip one more line of header.

v3.60d-jmj, 03-Jun-2002  J. Jonkman
 I added the cross product of the tower top position vector with the tower top shear force to
   the initialization of the tower base moments.  Before this bug fix, the tower base moments
   were seriously wrong!  Sorry about that mistake.  At least I found this bug fairly
   quickly...  This change wont affect anything other than the 3 tower base moments: TwrBsMxt,
   TwrBsMyt, and TwrBsMzt.
 In SUBROUTINE AeroCalc.f90/USRMES(), I changed the statement "CALL EXIT(-1)" to
   "CALL EXIT(1)".  The 1 should be positive not negative.  This was preventing the CertTest
   from stopping when FAST bombed.
 I replaced the expression "TipSpeed = MAX(r  * revs, 1.0e-6)" with
   "TipSpeed = MAX(ABS(r  * revs), 1.0e-6)" in AeroDyn 12.46 SUBROUTINEs infdist() and
   infinit() and linked this slightly modified version of AeroDYn 12.46 to FAST when compiling
   FAST's executable.  I did this to prevent CertTest 04 from bombing during the shutdown
   manuever between seconds 18 and 19.  I DID NOT change the copy of AeroDyn 12.46 that is
   posted on the web, so anyone trying to compile FAST with AeroDyn 12.46 will not be able to
   run the CertTest without it bombing in Test04 (unless, of course, they too make this slight
   change to AeroDyn 12.46 before compiling).  We are currently in the process of working with
   the good ol' folks at Windward Engineering to determine how best to modify AeroDyn so that
   shutdown manuevers are modeled correctly when the dynamic inflow model is selected.  So if
   anyone out there is compiling FAST for what ever reason, heed my warning!!!

v3.60e-jmj, 05-Jun-2002  J. Jonkman
 I added REAL(4), ALLOCATABLE variables n1(:,:,:), n2(:,:,:), and n3(:,:,:) to
   fast_mods.f90/CoordSys().  These are the three vector / directions of the vector triad
   fixed in a deflected blade element (i.e., local coordinate system), which is aligned with
   the local structural axes.  These are coincident with the LxbK, LybK, and LzbK directions
   specified in the FAST user's manual.  These are similar to the blade element-fixed
   coordinate systems used in ADAMS.  I also added REAL(4), ALLOCATABLE variables m1(:,:,:),
   m2(:,:,:), and m3(:,:,:) to fast_mods.f90/CoordSys().  These define the blade element--
   fixed coordinate system use to calculate and return aerodynamic forces and moments from
   AeroDyn.  This coordinate system is rotated about positive n3 by the angle BlPitch(K) +
   ThetaS(K,J).  These new arrays are ALLOCATEd in SUBROUTINE FAST.f90/Alloc().
 I added the calculations for vector / directions n1(), n2(), n3(), m1(), m2(), and m3() to
   SUBROUTINE FAST.f90/SetCoordSy().  In this addition, I had to USE MODULES Blades() and
   DOFs() in SetCoordSy().  I also had to add local REAL(4) variables CPitPTwstS,
   SPitPTwstS, Lj1(3), Lj2(3), Lj(3), ThetaIP, ThetaOoP, ThetaLxb, ThetaLyb, SQRT1Lx2,
   SQRT1Lx2Ly2, and SQRT1Ly2 and local INTEGER(4) variable J to SetCoordSy().

v3.60e-jmj, 10-Jun-2002  J. Jonkman
 In fast_io.f90/GetPrimary(), I made FAST output a warning message when flap mode 1 is not
   enabled and flap mode 2 is enabled.  To do this, I had to USE MODULE SysSubs in
   GetPrimary().
 I made the transformation from a to b more consistent with Bernoulli-Euler beam theory and
   consistent with how it is now done with the blade elements.  b2 is now normal to the
   plane caused by rotations ThetaFA about a3 and ThetaSS about a1.  Also, b1 and b3 are
   now orthogonal and mutaually orthoganal with b2.  Also, each b is now a function of every
   a.  See my work done by hand for details on how this new approach works and why it is
   better than the old transformation.  To make this change, I removed local REAL(4)
   variables CThetaFA, SThetaFA, CThetaSS, and SThetaSS from FAST.f90/SetCoordSy().  I also
   added REAL(4) variables ComDenom, SQRT1FA2, SQRT1FA2SS2, and SQRT1SS2 to SetCoordSy().

v3.60e-jmj, 11-Jun-2002  J. Jonkman
 In FAST.f90/Coeff(), I included the hub radius effects in the equation for the rotor
   inertia, RotIner.  The previous equation was incorrect when HubRad is not zero.  This only
   affects what is printed in the <RootName>.fsm file.
 In FAST.f90/Coeff(), I made FreqTFA(:,1) and FreqTSS(:,1) reflect the tower frequencies with
   neither gravitational destiffening nor tower-top mass effects.  These are the frequencies
   used to calculate the generalized damping coefficients of the tower--this updated way is
   now consistent with FAST's old method of calculating the generalized damping coefficients,
   so user's wont have to retune there damping ratios to get their results to match previous
   runs of FAST.  The tower damping coefficients specified in the input file reflect the
   damping that are inherent in the tower alone.  Note that the tower frequencies printed in
   the <RootName>.fsm file, FreqTFA(:,2) and FreqTSS(:,2), include both gravitational
   destiffening and tower-top mass effects and these values are uneffected by this change.  I
   did a similar thing for the blades, so now FreqBF(:,:,1) and FreqBE(:,:,1), which are used
   to compute the generalized damping of the blades, reflect the blade frequencies with
   neither centrifugal stiffening nor tip-mass (that is, tip brake mass) effects.  This
   updated method is how I originally proposed to calculate the generalized damping
   coefficients when rederiving the equations of motion.
 In AeroCalc.f90/GetRotorParams(), I placed an ABS() around QT(4) when calculating RotorSpeed.
   According to David Laino of Windward Engineering, the rotor speed passed to AeroDyn must
   always be positive.  In FAST, it is possible for the rotor speed to change sign (e.g., when
   the high-speed shaft brake locks the high-speed shaft, the inertia of the rotor will cause
   it oscillate about the locked generator position when the drive train DOF is enabled).
   This change allowed me to undo the change I made to AeroDyn 12.46 in FAST v3.60d.  Thus,
   the warning I gave there is no longer necessary! :-)

v3.60e-jmj, 12-Jun-2002  J. Jonkman
 I renamed variables rSAerCenj1() and rSAerCenj2() to rSAerCenn1() and rSAerCenn2()
   respectively.  These variables now represent the distance from point S (25% chord) to the
   aerodynamic center of blade element J in the n1 and n2-directions respectively (the
   n-vector triad is the blade element-fixed coordinate system aligned with the local
   structural axes).  Since these variables are defined slightly differently due to there
   different orientation, I had to add local REAL(4) variables TmpDistj1 and TmpDistj2 to
   FAST.f90/Coeff when defining them.  These are now used with n1() and n2() to find
   rSAerCen in FAST.f90/RtHS().
 In FAST.f90/RtHS(), I expressed the components of VES() in the m-vector triad instead of
   the i-vector triad.  The m-vector triad is coincident with the i-vector triad when the
   blade is undeflected.  This is how it is done in ADAMS--using the deflected blade
   coordinate sytem.
 Similarly, in AeroCalc.f90/GenVNWT(), I expressed VTWind in the m2(K,J,:)-direction and
   VNWind in the m1(K,J,:)-dirction.  This is how it is done in ADAMS--using the deflected
   blade coordinate sytem.
 The previous two changes to the code make it so AeroDyn calculates and outputs aerodynamic
   loads (i.e., the AeroForces() vector) in the m-vector triad (i.e., using deflected blade
   coordinates, like ADAMS).  Thus, in FAST.f90/RtHS(), I calculate FSAero() and MMAero()
   (see next change) using AeroForces() expressed in the m-vector triad instead of the
   i-vector triad.
 I renamed variable MHAero() to MMAero() to reflect the body the aerodynamic pitching
   moment is now applied to (i.e., the blade eleMent body insted of the Hub).
 I added REAL(4), ALLOCATABLE variable PAngVelEM(:,:,:,:,:) (Partial angular velocity (and
   its 1st time derivative) of eleMent J of blade K (body M) in the inertia frame (body E
   for earth)) to fast_mods.f90/RtHndSid().  This is ALLOCATEd in FAST.f90/Alloc() and is
   defined in FAST.f90/RtHS().  This is used in RtHS() to add the aerodynamic pitching
   moment effects to the components of the forcing vector associated with purely blade
   DOFs.
 In FAST.f90/CalcOuts(), I changed the calculations of the blade 1 local span
   accelerations so that they incorporate the new blade element-fixed coordinate system
   that is oriented with the local structural axes.  In this process I deleted now unused
   variables LinAccESj1 and LinAccESj2 from CalcOuts().
 Similarly, in FAST.f90/CalcOuts(), I changed the calculations of teh blade 1 local span
   moments (loads) so that they incorporate the new blade element-fixed coordinate system
   that is oriented with the local structural axes.  In this process, I rename local
   variable MomHGagB() to MomMGagB() to reflect the body the aerodynamic loads are applied
   to (i.e., the blade eleMent body).  I also deleted now unused variables MomHGagBj1 and
   MomHGagBj2 from CalcOuts().
 In AeroCalc.f90/GetRotorParams(), I changed the calculation of TiltAngle so that now it
   uses live tilting effects associated with both the tilt and tower deflection DOFs.
   Essentially, TiltAngle is the angle of shaft relative to the horizontal plane (the
   ground) where a positive TiltAngle sends the nominally upwind end of the shaft
   downwards.  To complete this change, I added local REAL(4) variables c1DOTa1, c1DOTa2,
   and c1Dota3 and USEd FAST MODULE CoordSys in GetRotorParams().

-------------------------------------------------------------------------------
--------------------------- FAST v4. ------------------------------------------
-------------------------------------------------------------------------------

v4.00, 09-Jul-2002  M. Buhl
 I removed all the alpha change comments.
 I added more blanks to the end of the "Total Real Time" message because the write
  did not completely cover the last status message.

v4.01, 25-Jul-2002  J. Jonkman
 I made local variable ZTTMP in FUNCTION TBFract() SINGLE PRECISION (a REAL) instead of
   DOUBLE PRECISION to make it compatible with the REAL(4) ZTIME specification.  This
   change makes the tip brakes work properly--before they wouldn't deploy.
 In SUBROUTINE PrintSum() I made the .fsm file say that aerodynamics computations were
   enabled via a test with CompAero instead of FlapDOF1.  The previous test was a bug,
   which only affected the .fsm file.
 I increased the size of the last dimension of arrays FreqBE() and FreqBF() from 2 to 3.
   In 3, I calculate the values of the frequencies w/ centrifugal stiffening and
   tip brake mass effects (this use to be in 2).  In 2, I calculate the values of the
   frequencies w/o centrifugal stiffening, but w/ tip brake mass effects.  These are the
   two sets of frequencies now output in the .fsm file.  Prior to this change, the
   frequency w/o centrifugal stiffening output in the .fsm file did not have tip brake
   mass effects included, whereas the frequency w/ centrifugal stiffening did--this was
   inconsistent.  Now the both include the effects of tip brake masses.  This change
   only effects the .fsm file.
 I made the overall rotor inertia output in the .fsm file include precone effects via a
   change in SUBROUTINE Coeff().  This change only effects the .fsm file.
 I moved SUBROUTINE Teeter() and FUNCTION TBFract() from FAST_Subs.for to FAST.f90 and
   converted them over to modern Fortan.

v4.02, 04-Sep-2002  J. Jonkman
 I added the feature that additional prefixes other than '-' can be used to specify a
   sign reversal for the selected output channels.  Now, the prefix characters '-',
   '_', 'm', or 'M' can be used to reverse the sign (+/-) of any selected output
   channel.  This required a simple change to SUBROUTINE fast_io.f90/ChckOutLst().
   NOTE: If, in the future, any output channel is named with a character beginning with
   'm' (or 'M'), this simple code will have to be made a lot more complex!
 I added an output channel for the rotor blade tip speed ratio named "TipSpdRat" or
   simply "TSR".  This output channel is unavailable if CompAero = False.  This
   addition required a small change to SUBROUTINEs fast_io.f90/ChckOutLst() and
   FAST.f90/CalcOuts().  To complete this change, I added REAL(4), PARAMETER TipSpdRat
   to MODULE fast_mods.f90/Output() and REAL(4) variable AvgNrmTpRd, which is the
   average tip radius normal to the shaft, to MODULE fast_mods.f90/TurbConf().
   AvgNrmTpRd is calculated in SUBROUTINE fast_io.f90/Input().
 I moved SUBROUTINEs Gauss(), Initialize(), and Solver() from FAST_Subs.for to FAST.f90
   and converted them over to modern Fortan.  This eliminated the need for the
   FAST_Subs.for file, so I deleted it from the project workspace and FAST archives.
   To complete this change I deleted unused variable ITH from PROGRAM FAST.f90/FAST()
   and moved variable Step from FAST() to MODULE fast_mods.f90/SimCont().  Variable
   Step is now used in place of ITH in SUBROUTINE Solver().  I also moved the
   initialization of the IC() array from Sover() to SUBROUTINE Initialize()--a more
   appropriate location.  I also modified SUBROUTINE Gauss() so that it does not
   modify the augmented matrix (AugMat) that is passed into it.  This was needed for
   the changes made in 4.02 on 12-Sep-2002.

v4.02, 12-Sep-2002  J. Jonkman
 I improved the HSS brake model so that it is impossible for the HSS brake to reverse
   the direction of the generator, which is a physically impossible scenario.  The
   problem arises since we are integrating in discrete time, not continuous time.  To
   do this added I SUBROUTINE FixHSSBrTq() to FAST.f90.  Essentially, this routine
   disables the generator azimuth DOF when it is found that the HSS brake torque at
   time "i" would have been large enough to reverse the direction of the generator at
   time "i+1".  The routine also calculates the exact acceleration and necessary HSS
   brake torque that would force the generator speed at time "i+1" to zero.  If the
   "DYNIN" InfModel is engaged, the routine also causes AeroDyn to switch over to the
   "EQUIL" InfModel to prevent instabilities in AeroDyn caused by very small rotor
   speeds.  Once the generator DOF is disabled in SUBROUTINE FixHSSBrTq(), a new
   segment of code in FAST.f90/RtHS() is used to calculate the exact HSS brake torque
   necessary to maintain the locked generator value.  In this new code of SUBROUTINE
   RtHS() a check is made to see if the required HSS brake torque is larger than its
   maximum allowable, and if so, it enables back the generator DOF (w/o switching
   back the InfModel).  Since FixHSSBrTq() is a function of the integration type (of
   time), it is called from SUBROUTINE FAST.f90/Solver().
 To complete the aforementioned changes, I added variable REAL(4) variable HSSBrTrqC
   [which is a copy of the value of HSSBrTrq calculated in SUBROUTINE DrvTrTrq()] to
   MODULE fast_mods.f90/DriveTrain().  I also added REAL(4) ALLOCATABLE variables
   OgnlGeAzCo(:) and OgnlGeAzRo(:) (the original column and row of the augmented
   mass matrix calculated in RtHS() before application of known disabled DOFs) to
   MODULE fast_mods.f90/RtHndSid().  These are ALLOCATEd in SUBROUTINE
   FAST.f90/Alloc() and are defined in RtHS().  I also added REAL(4) local variable
   RqdFrcGeAz (the force term required to maintain zero acceleration for the generator
   azimuth DOF) to SUBROUTINE RtHS().
 All of these aforementioned changes made on 12-Sep-2002 only affect the shutdown
   sequences using a HSS brake.  They wont affect the functionality of any other
   aspect of the simulator.

v4.02, 02-Oct-2002  J. Jonkman
 I linked FAST to the latest version of AeroDyn, 12.47.
 In SUBROUTINE PitchCntrl_ACH.for/CTRL4() I replaced the CALL to OpenInFile() using
   'pitcntrl.plt' with a CALL to OpenOutFile()--since the file to be opened is an
   output file.  Thanks to Dave Laino for finding this bug.
 I deleted local unused variable Flt2LStr from PROGRAM FAST.f90/FAST().
 I fixed a bug in the equation for the generalized blade edge damping, CBE(), in
   SUBROUTINE FAST.f90/Coeff().  FreqBF() should be FreqBE() instead.
 I added one line of code in SUBROUTINE PitchCntrl_ACH.for/CTRL4() per a request by
   C. Hansen.
 I initialized LOGICAL array FirstTHere() to .TRUE. in SUBROUTINE
   FAST.f90/Initialize().  This should be initialized to insure that the override
   pitch maneuver works properly.

v4.03, 31-Dec-2002  J. Jonkman
 I linked FAST to the latest version of AeroDyn, 12.51.  NOTE: with this new
   version of AeroDyn there comes a change to the AeroDyn input file.  That
   is, a new switch to incorporate a hub loss model is added after the tip loss
   model switch.  See the updated AeroDyn User's guide for version 12.50 for
   details on this and other changes made to AeroDyn.
 I linked Craig Hansen's PitchCntrl() SUBROUTINE() to the downloadable
   version of FAST, so user's don't need to recompile FAST if they want to use
   this routine.
 I fixed a bug in the equation for the output loads at the shaft strain gage
   location.  A minus sign was missed in the equation.  This only affects the
   results if shaft strain gage loads are output using ShftGagL.  I found this
   bug during some FAST to ADAMS comparison work.
 I fixed a bug in the screen status message routine so that now the text won't
   jump around if SttsTime is set to less than 1.0.  This change does not affect
   any of the simulation results.  To complete this change I modifed how
   TiLstPrn was calculated in PROGRAM FAST() and made a couple of minor changes
   to SUBROUTINE() SimStatus().  Thanks Pat Moriarty for finding this bug.
 I removed SUBROUTINE Abort() from file GenUse.f90.  This had to be done since
   a SUBROUTINE entitled Abort was added to AeroDyn in file GenSubs.f90.  I
   like the Abort SUBROUTINE in GenUse.f90 much better, but AeroDyn must take
   precedence since it is used and must be compatible with several dynamics
   codes.
 I removed unneeded SUBROUTINE() OutputAero() from file AeroCalc.f90.  Now I
   call SUBROUTINE ElemOut() directly from SUBROUTINE WrOutput().
 I removed unneeded variable TwrGagL from MODULE fast_mods.f90/Output().

v4.10, 02-Oct-2002  J. Jonkman
 I moved the local variable TeetAngVel from SUBROUTINE FAST.f90/RtHS() to
   MODULE fast_mods.f90/RtHndSid() and moved its definition to SUBROUTINE
   FAST.f90/SetCoordSy().
 I initialized variable TeetDefl to 0.0 in MODULE fast_mods.f90/InitCond().
   Similarly, I initialized all variables to 0.0 in MODULE
   fast_mods.f90/TeeterVars().
 I added the file FAST2ADAMS.f90 and associated SUBROUTINEs MakeADM(),
   MakeACF(), and MakeACF_LIN to the FAST source code.  MakeADM(), MakeACF(),
   and MakeACF_LIN are routines used to generate an ADAMS dataset file (.adm)
   and two ADAMS control files (.acf) respectively using the geometry and
   mechanical properties specified in the FAST input files as model input
   parameters.
 I added a new INTEGER(4) variable UnAC (the I/O unit number for the ADAMS
   control output file (.acf) for simulation) to MODULE
   fast_mods.f90/General().
 I added a new INTEGER(4) variable UnAD (the I/O unit number for the ADAMS
    dataset output file (.adm)) to MODULE fast_mods.f90/General().
 I added a new INTEGER(4) variable UnAL (the I/O unit number for the ADAMS
   control output file (.acf) for ADAMS LINEAR) to MODULE
   fast_mods.f90/General().

v4.10, 24-Oct-2002  J. Jonkman
 I added a new input switch to the primary input file named "ADAMSPrep".  This
   new input parameter is now input between the "Echo" and "NumBl" inputs in
   the SIMULATION CONTROL portion of the primary input deck.  ADAMSPrep is the
   ADAMS preprocessor mode switch {1: Run FAST, 2: use FAST as a preprocessor
   to create equivalent ADAMS model, 3: do both}.  INTEGER(4) variable
   ADAMSPrep is stored in MODULE fast_mods.f90/SimCont() and read in in
   SUBROUTINE fast_io.f90/GetPrimary().
 Using a check on ADAMSPrep, I added calls to new SUBROUTINEs MakeADM, MakeACF,
   and MakeACF_LIN from PROGRAM FAST.f90/FAST().
 I added LOGICAL(1) internal variable MakeLINacf to MODULE
   fast_mods.f90/SimCont().  This variable determines whether or not an ADAMS
   control file for an ADAMS linear analysis is made along with the ADAMS
   dataset and whether or not the RESULTS statement is included in the ADAMS
   dataset.

v4.10, 13-Nov-2002  J. Jonkman
 I added new distributed tower properties in the tower file as follows:
   TwGJStif (tower torsional stiffness),
   TwEAStif (tower extensional stiffness),
   TwFAIner (tower fore-aft (about yt-axis) mass inertia per unit length),
   TwSSIner (tower side-to-side (about xt-axis) mass inertia per unit length),
   TwFAcgOf (tower fore-aft mass cg offset), and
   TwSScgOf (tower side-to-side mass cg offset).
 These variables are only read in when an ADAMS dataset is created from FAST
   (i.e., ADAMSPrep = 2 or 3) and are only used to create the ADAMS dataset--
   they are not used in the FAST simulation!  These variables are stored in
   MODULE fast_mods.f90/Tower() and are read in from SUBROUTINE GetTower().
 These 6 new tower property input variables are interpolated to the tower
   analysis nodes as stored in the following new variables: StiffTGJ, StiffTEA,
   InerTFA, InerTSS, cgOffTFA, and cgOffTSS (which are also stored in
   fast_mods.f90/Tower()).  These variables are ALLOCATEd in SUBROUTINE
   fast_io.f90/Input(), are defined in SUBROUTINE InterpTwr(), and are
   output in the FAST summary file (.fsm) through SUBROUTINE PrintSum().
 Similar to the new tower inputs, I added new distributed blade properties in
   the blade file(s) as follows:
   GJStff  (blade torsional stiffness for a given input station),
   EAStff  (blade extensional stiffness for a given input station),
   FlpIner (blade flap (about local structural yb-axis) mass inertia per unit
            length for a given input station),
   EdgIner (blade edge (about local structural xb-axis) mass inertia per unit
            length for a given input station),
   FlpcgOf (blade flap (along local aerodynamic xb-axis) mass cg offset for a
            given input station),
   EdgcgOf (blade edge (along local aerodynamic yb-axis) mass cg offset for a
            given input station),
   FlpEAOf (blade flap (along local aerodynamic xb-axis) elastic axis offset for
            a given input station), and
   EdgEAOf (blade edge (along local aerodynamic yb-axis) elastic axis offset for
            a given input station).
 These variables are only read in when an ADAMS dataset is created from FAST
   (i.e., ADAMSPrep = 2 or 3) and are only used to create the ADAMS dataset--
   they are not used in the FAST simulation!  These variables are stored in
   MODULE fast_mods.f90/Blades() and are read in from SUBROUTINE GetBlade().
 These 8 new blade property input variables are interpolated to the blade
   analysis nodes as stored in the following new variables: StiffBGJ, StiffBEA,
   InerBFlp, InerBEdg, cgOffBFlp, cgOffBEdg, EAOffBFlp, and EAOffBEdg (which
   are also stored in fast_mods.f90/Blades()).  These variables are ALLOCATEd
   in SUBROUTINE fast_io.f90/Input(), are defined in SUBROUTINE InterpBld(), and
   are output in the FAST summary file (.fsm) through SUBROUTINE PrintSum().

v4.20, 28-Feb-2003  J. Jonkman
 NOTE: FAST v4.10 was never released to the public, though FAST v4.20 does
   incorporate the v4.10 changes.
 I removed all of the old alpha comments from the source code for versions 4.03
   and earlier.
 I fixed a minor bug in SUBROUTINE GenUse.f90/Interp(), which caused FAST to
   crash in some situations.
 I added new REAL(4) variable Q4Init to MODULE fast_mods.f90/InitCond().  This
   is the initial value of the internal rotor azimuth DOF (q4).  This variable
   is now defined in SUBROUTINE FAST.f90/Initialize().
 I added new INTEGER(4) variable NActvDOF to MODULE fast_mods.f90/DOFs().  This
   is the number of active (enabled) DOFs in the model.  This variable is now
   defined in SUBROUTINE FAST.f90/Initialize().
 I added a new input switch to the primary input file named "AnalMode".  This
   new input parameter is now input between the "ADAMSPrep" and "NumBl" inputs
   in the SIMULATION CONTROL portion of the primary input deck.  AnalMode is
   the FAST analysis mode switch {1: Run a time-marching simulation, 2: create
   a periodic linearized model}.  INTEGER(4) variable AnalMode is stored in
   MODULE fast_mods.f90/SimCont() and read in in SUBROUTINE
   fast_io.f90/GetPrimary().
 I moved the chunk of code which contains the time-marching method from PROGRAM
   FAST.f90/FAST() to a new SUBROUTINE FAST.f90/TimeMarch(), since this code
   should only be executed when AnalMode == 1.  This check on AnalMode is now
   placed in PROGRAM FAST().
 I moved the initializtion of ZTime to zero into MODULE
   fast_mods.f90/SimCont().
 I moved the check to ensure the azimuth DOFs are between zero and TwoPi from
   the end of SUBROUTINE FAST.f90/Solver() to after Solver() is CALLed since
   I don't always want to inforce this condition.
 I added MODULE fast_mods.f90/Linear().  This MODULE stores variables for
   FAST's linearization.
 I added INTEGER(4) variable UnLn to MODULE fast_mods.f90/General().  This is
   the I/O unit number for the FAST linear output file (.lin).
 I added new input variable ADAMSFile to the primary input file.  This new
   input parameter is located after a new comment line, which is located after
   the ADFile input paraemter.  ADAMSFile is a path/filename for a file
   containing ADAMS-specific data input.  CHARACTER(99) ADAMSFile is stored in
   MODULE fast_mods.f90/General() and read in in SUBROUTINE
   fast_io.f90/GetPrimary().  ADAMSFile is CURRENTLY IGNORED by FAST, but will
   eventually be used to define more advanced ADAMS datasets using FAST's input
   parameters.  When time permits, I will code these new features.
 I added a new lineariztion parameters section to the primary input file.  This
   new section is between the simulation control and turbine control sections.
   It contains the following new input variables:
   "DispTol" - Convergence tolerance for the 2-norm of displacements in the
               periodic steady state calculation (rad)
   "VelTol"  - Convergence tolerance for the 2-norm of velocities    in the
               periodic steady state calculation (rad/s)
   "NAzimStep" - Number of azimuth steps in periodic linearized model (-)
   These variables REAL(4) (x2) and INTEGER(4) (x1) variables are stored in
   MODULE fast_mods.f90/Linear() and are read in in SUBROUTINE
   fast_io.f90/GetPrimary().  To do this, I had to USE MODULE Linear() in
   SUBROUTINE GetPrimary().
 I added the file FAST_Lin.f90 and associated SUBROUTINEs CalcSteady() and
   Linearize() to the FAST source code.  CalcSteady() is used to march in time
   until a periodic steady state solution (if rotor is spinning) or static
   equilibrium (if rotor is parked) is found via a simple tolerance check.
   Once found the periodic solution is interpolated to find the periodic
   !   operating point displacements, velocities, and accelerations of each DOF
   at each of the equally-spaced azimuth steps.  Linearize is used to perturb
   each displacement and velocity DOF about its periodic operating point at
   each of equally-spaced azimuth steps to compute the linearized state
   matrices.

v4.20a-jmj, 21-Mar-2003  J. Jonkman
 I added an additional output names for channel RootMxck, RootMyck, RootMxbk,
   and RootMybk as follows: RootMIPk, RootMOoPk, RootMEdgk, and RootMFlpk
   (where k = 1,2,3--the blade number).  This required a minor change to
   SUBROUTINE() fast_io.f90/ChckOutLst().  The previos output channel names
   still work.  This addition was requested by N. Kelley / M. Buhl.

v4.20b-mlb, 08-Apr-2003  M. Buhl
 I changed all REALs to REAL(ReKi) and DOUBLE PRECISION statements to
   REAL(DbKi) so we can easliy vary the precision.  I had to USE Precision()
   to import the parameters DbKi & ReKi.

v4.20c-jmj, 28-Apr-2003  J. Jonkman
 I linked FAST to the latest version of AeroDyn, 12.53a-jmj, so that we can
   easily switch between single and double precision using variable ReKi in
   MODULE Precision of the new version of AeroDyn (see also 4.20b-mlb changes).
 I added the REAL() function around several lines of code and converted all
   SNGL() functions to REAL() functions so that the code does not crash when
   converting between single and double precision.
 To compile in double precision, change variable "ReKi", which is stored in
   MODULE AeroMods.f90/Precision(), to "8" and add the compile option
   "/real_size:64" (or "/4R8") to the project settings.  To revert back to
   single precision, change ReKi to 4 and remove the "/real_size:64" (or
   "/4R8") compile option.
 I now have the program version indicate the compiled precision through a
   slight change to variable "ProgVer".
 I removed a reference to unUSEd MODULE TurbConf() in SUBROUTINE WrOutHdr().
 I updated MODULE ModCVF.f90/System() the modern visual FORTRAN way.

v4.20d-jmj, 02-Jun-2003  J. Jonkman
 I renamed input switch TeetDMod to TeetMod.  This is because this switch is
   now used to control both the spring and damper models as follows: (0) ignore
   all teeter spring and damper models, (1) using the standard spring and
   damper models, which are based on the inputs in the primary FAST input file,
   and (2) use the user-defined SUBROUTINE UserTeet() to define your on
   rotor-teeter spring and damper model.  This change required a slight change
   to MODULE fast_mods.f90/TeeterVars(), SUBROUTINE fast_io.f90/GetPrimary(),
   SUBROUTINE FAST.f90/Teeter(), and SUBROUTINE FAST2ADAMS.f90/MakeADM().
   Before this change, the input switch only controlled which teeter damper
   model to use.  Users will not have to modify their input decks to handle
   this change unless they are using a user-defined teeter model.  This change
   was requested by D. Laino.
 I added the logic to compute the hub-loss constants stored in array HLCNST to
   SUBROUTINE AeroCalc.f90/Set_FAST_Params().  I stole the logic from
   SUBROUTINE GetHLCnst() in the ADAMS-to-AeroDyn (A2AD) source file
   GFOSUB.f90.  I have no idea why D. Laino didn't tell me I had to add this
   logic early (when I linked FAST to AeroDyn 12.51).  Before this change,
   the hub loss model did not work.
 I converted source file UserSubs.f to modern Fortran.  It is now called
   UserSubs.f90.
 I also converted source file PitchCntrl_ACH.for to modern Fortran and made it
   slightly more readable.  It is now called PitchCntrl_ACH.f90.  In the
   process, I added the current simulation time, ZTime, as a new argument to
   the PitchCntrl() SUBROUTINE call, so that the pitch control routines do not
   require FAST MODULEs (so that we can use the same routines for ADAMS).  This
   also required minor changes to SUBROUTINE FAST.f90/Control() and SUBROUTINE
   PitchCntrl.f90/PitchCntrl().
 I modified SUBROUTINE UserSubs.f90/UserVSCont() so that it does not need any
   of the FAST MODULEs (this way we can link this source file to ADAMS, which
   can't USE FAST MODULEs).  To do this, I added variables GBRatio, ZTime, DT,
   and GenTrq to the argument list.
 I removed unused variables SGOn, TGOn, and TGOff from MODULE
   fast_mods.f90/TurbCont().
 I modified the extracted ADAMS .acf files so that the outermost blade FIXED
   JOINTs, which are used to lock the outermost blade FIELDs, are not
   DEACTIVATED when the TipMass'es are equal to zero.  This prevents extremely
   high frequencies from appearing in the results--the extremely high
   frequencies appeared before this change since, when the TipMass'es were
   zero, the outermost blade FIELDs coupled with the minute tip masses produce
   large frequencies.  The unfortunate result of this change is that identical
   ADAMS models (other than the tip masses) will have a different number of
   DOFs if the only difference between the models is that one has a tip mass
   and the other does not.  This change required slight modifications to
   SUBROUTINEs FAST2AMAMS.f90/MakeACF() and MakeACF_LIN().
 I changed, slightly, the orientation of the tip brake drag force since the
   existing orientation would have been impossible to replicate in ADAMS since
   the orientation does not change as the blade deflects.  Since, the use of
   the i2-vector was only an approximation anyway, I instead used the
   body-fixed m2-vector, which is coincident with the i2-vector when the blade
   is undeflected.  The use of the m2-vector is easier to replicate in ADAMS.
   Also, this should not significantly effect the dynamics of the tip brake
   drag.  I used the m2-vector that is closest to the tip.  This change
   required a minor modification to SUBROUTINE FAST.f90/RtHS().
 In SUBROUTINE FAST2ADAMS.f90/MakeADM(), I added MARKER/( 500 + K ), which is a
   FLOATING MARKER attached to the GROUND and used for computing tip drag
   forces.  I also added MARKER/( 10000*K + 5100 ), which is a MARKER fixed in
   the blade tip brake and oriented with the FAST blade K coordinate system. I
   also added VFORCE/( 10000*K + 5100 ), which is used to compute tip brake
   drag forces.  The effects of the tip brake drag forces are removed in the
   ADAMS/LINEAR analysis through a small change to SUBROUTINE MakeACF_LIN().
 I modified the extracted ADAMS models so that they implement the same advanced
   pitch control paradigms FAST uses (using inputs from section TURBINE CONTROL
   of FAST's primary input file).  The demanded pitch angle for blade K is
   defined in VARIABLE/(10000*K).  The pitch error for blade K (the difference
   between the demanded and actual pitch angle) is defined in
   VARIABLE/(10000*K+1).  The pitch control is applied through a pitch actuator
   (unlike FAST, which assumes the actuator is infinitely FAST!).  The pitch
   actuator torques are defined in SFORCE/(10000*K).  This required minor
   changes to SUBROUTINEs FAST2ADAMS.f90/MakeADM() and MakeACF().
 I modified the extracted ADAMS models so that they implement the generator
   models used by FAST (as specified in the FAST input deck).  The generator
   models are defined in SFORCE/3150.  This change required minor additions to
   SUBROUTINEs FAST2ADAMS.f90/MakeADM() and MakeACF().
 I modified the extracted ADAMS models so that they implement the HSS braking
   model used by FAST (as specified in the FAST input deck).  The maximum HSS
   braking friction is defined in FRICTION/3151.  The ramping portion of the
   HSS braking friction is defined in SFORCE/3151.  This change required minor
   additions to SUBROUTINEs FAST2ADAMS.f90/MakeADM() and MakeACF().
 In SUBROUTINE FAST2ADAMS.f90/MakeADM(), I added STRING statements for passing
   file names to ADAMS user-written subroutines.  Now the time-series output
   file is named "<RootName>_ADAMS.plt" and the AeroDyn input file need not be
   named "AeroDyn.ipt".  Woohoo!
 In SUBROUTINE FAST2ADAMS.f90/MakeADM(), I now pass the FTitle to ADAMS user-
   written routines using a STRING statement.  To complete this change, I
   needed to place restrictions on which CHARACTERs can appear in FTitle.
 In SUBROUTINE FAST2ADAMS.f90/MakeADM(), I now pass the OutFmt to ADAMS user-
   written routines using a STRING statement.
 In SUBROUTINE FAST2ADAMS.f90/MakeADM(), I now pass the output channel names
   and units to ADAMS user-written routines using STRING statements.
 In SUBROUTINE FAST2ADAMS.f90/MakeADM(), I now pass the TabDelim flag to the
   user-defined REQSUB() through PARameter 7 (along with NumBl and CompAero).
 In SUBROUTINE FAST2ADAMS.f90/MakeADM(), I now pass the values of the BldGagNd
   array into the ADAMS routines through an ARRAY statement.  PARameter 9 of
   the REQUEST statement is now used to pass TipRad.
 In SUBROUTINE FAST2ADAMS.f90/MakeADM(), I added the constraint that the
   initial teeter angle, TeetDefl, must be zero if an ADAMS dataset is to be
   made.  I had to add this constraint since routine GFOSUB(), as it is written
   now, won't read in the blade element properties correctly if the initial
   teeter deflection is not zero.  Is there a way of modifying GFOSUB() so that
   we can start with an initial teeter angle?
 I removed effects of local variables for ADAMS specific massess, since these
   were unnecessary.  I also added small numbers (through new variable SmllNmbr)
   to all mass and inertias in the extracted ADAMS dataset so as to avoid a
   singularity in the EoM in case the inputted mass and/or inertias or zero.
 I added LOGICAL(1) switch SaveGrphcs, which is used to determine whether or
   not to save GRAPHICS output.
 I added SUBROUTINE fast_io.f90/GetADAMS(), which is used to read in
   ADAMS-specific input parameters from ADAMSFile.

v4.20e-jmj, 06-Jun-2003  J. Jonkman
 I linked FAST to the latest version of AeroDyn, 12.53b-jmj.
 I updated all CHARACTER*len variable declaration statements with modern
   CHARACTER(len) declarations.

v4.21, 16-Jun-2003  J. Jonkman
 I rolled up all the alpha changes into this new version.  I eliminated all
   alpha comments.

v4.22a-jmj, 02-Jul-2003  J. Jonkman
 I changed the definition of of internal DOF Q4 so that it represents the shaft
   compliance (i.e., the azimuth angle of the rotor relative to that of the
   generator) instead of the absolute rotor azimuth angle.  In equation form
   this means that Q(4)old = Q(4)new + Q(DOF_GeAz).  This will not effect any
   of the simulation results.  This change was necessary for making sense of
   the output state matrices available through FAST's new linearization
   routines.  This modification required changes (some extensive) to routines
   FAST.f90/Initialize(), "/RtHS(), "/SetCoordSy(), "/TimeMarch(),
   "/CalcOuts(), fast_mods.f90/InitCond(), FAST_Lin.f90/CalcSteady(),
   "/Linearize(), and AeroCalc.f90/GetBladeParams() and "/GetRotorParams().
 I changed how the gearbox friction (through input GBoxEff) is implemented in
   the equations of motion--I implemented a method that is easier to
   understand.  This required changes to routine FAST.f90/RtHS().

v4.22b-jmj, 08-Jul-2003  J. Jonkman
 In SysCVF.f90, I changed UserTime() from a REAL(ReKi) variable to a REAL(4)
   variable so that this source file no longer needed to USE MODULE
   Precision().  Along with UserTime(), I changed the precision of variable
   UsrTime1 in MODULE fast_mods.f90/SimCont() and variables UsrTime and
   UsrTime2 in SUBROUTINE fast_io.f90/RunTimes() to REAL(4) so that they
   match the precision of UserTime().
 I removed the explicit declarations of the precision for variable Exists in
   the routines of source file GenUse.f90.  This was changed so that the
   statements using variable Exists work with any compiler.
 I added source files SysLL.f90 and ModLL.f90 to the FAST archive.  These
   source files should be used in place of SysCVF.f90 and ModCVF.f90 when
   compiling FAST in Lahey Linux (LL stands for Lahey Linux; CVF stands for
   Compact Visual Fortan).  Source files SysCVF.f90 and ModCVF.f90 should
   be used in place of SysLL.f90 and ModLL.f90 when compiling FAST using
   Compact Visual Fortan.  I also added a template of a makefile for compiling
   FAST in Lahey Linux to the archive.  This makefile is named make_LL.  It is
   only a template and will not work for compiling the latest version of FAST.
   Nevertheless, it may be a useful starting point if YOU need to compile FAST
   in Lahey Linux.

v4.22c-jmj, 10-Jul-2003  J. Jonkman
 In PROGRAM FAST.f90/FAST(), I added a check to prevent FAST from creating an
   ADAMS control file (.acf) for an ADAMS/Linear analysis if there is no active
   DOFs.  To do this I had to USE MODULE DOFs in PROGRAM FAST().

v4.30a-jmj, 14-Jul-2003  J. Jonkman
 I added new input variable LinFile to the primary input file.  This new
   input parameter is located after a new comment line, which is located after
   the ADAMSFile input paraemter.  LinFile is a path/filename for a file
   containing FAST linearization input data.  I moved the entire contents of
   the linearization control parameters section, including inputs DispTol,
   VelTol, and NAzimStep, from the primary input file to this new input file
   and added several more needed input parameters.  CHARACTER(99) LinFile is
   stored in MODULE fast_mods.f90/General() and read in in SUBROUTINE
   fast_io.f90/GetPrimary().  The parameters in LinFile are read in new
   SUBROUTINE fast_io.f90/GetLin().  As of this version, the only inputs that
   work are the original DispTol, VelTol, and NAzimStep.
 I added new LOGICAL(1) input CalcStdy, and INTEGER(4) inputs TrimCase,
   MdlOrder, CntrlInpt, NDisturbs, and Disturbnc() to LinFile.  These new
   inputs are stored in MODULE fast_mods.f90/Linear().
 I removed a reference to unUSEd MODULE Precision in SUBROUTINE
   fast_io.f90/GetADAMS().

v4.30b-jmj, 14-Jul-2003  J. Jonkman
 In SUBROUTINE FAST2ADAMS.f90/MakeADM() I fixed two minor bugs in the logic
   used to make statements ARRAY/1 and ARRAY/2.

v4.30c-jmj, 15-Jul-2003  J. Jonkman
 I coded the logic for new linearization input switch CalcStdy.  This required
   changes to PROGRAM FAST.f90/FAST(), MODULE fast_mods.f90/Linear(), and
   SUBROUTINEs FAST_Lin.f90/CalcSteady(), Linearize(), and fast_io.f90/Input().

v4.30d-jmj, 17-Jul-2003  J. Jonkman
 I fixed a bug in the calculation of output channel RotPwr.  This bug
   originated from the changes made during version 4.22a-jmj.

v4.30e-jmj, 22-Jul-2003  J. Jonkman
 I added the mass matrix times operating point acceleration effects (the
   d[M({Q})]{QD2op}/d{Q} terms) to the stiffness matrix in the linearized
   output.  This required minor changes to routine FAST_Lin.f90/Linearize().
 I fixed a bug in the calculation of QAzimInit in routine
   FAST.f90/Initialize().  The bug caused some FAST linearization routines to
   output unexpected results.
 In routine AeroCalc.f90/AeroCalc() I changed D. Laino's logic that ramps the
   aerodynamic forces up over the first 2 sec so that the aerodynamic load
   ramping only occurs during a time marching analysis (AnalMode == 1).  This
   ramping isn't needed in FAST but it is useful to keep so that FAST and
   ADAMS responses agree.  We don't want this ramping when linearizing FAST
   since we don't want the aero loads and aerodynamic damping terms to depend
   on time.
 I moved the declarations of INTEGER(4) variables ADAMSPrep and AnalMode from
   MODULE SimCont() to MODULE General to avoid an interface problem with
   AeroDyn.
 I removed references to the unUSEd MODULE SimCont in routines
   fast_io.f90/GetBlade(), GetTower(), InterBld(), InterpTwr(), and PrintSum().
   I also removed a reference to the unUSEd MODULE General in routine
   FAST_Lin.f90/CalcSteady().

v4.30f-jmj, 23-Jul-2003  J. Jonkman
 I linked FAST to the latest version of AeroDyn, 12.54.
 I changed the format and contents of the "Some Useful Information:" section of
   the FAST linearization output file (the .lin file).
 I added the internal FAST DOF indices to the "Order of States in Linearized
   State Matrices:" section of the FAST linearization output file (the .lin
   file).
 I moved REAL(ReKi) variables AbsQNorm and QbsQDNorm from SUBROUTINE
   FAST_Lin.f90/CalcSteady() to MODULE fast_mods.f90/Linear() so that I could
   use the values of these variables in SUBROUTINE FAST_Lin.f90/Linearize().
 I added logic in fast_io.f90/Input() to set the GenDOF to False if RotSpeed =
   0 during a FAST linearization analysis.  If RotSpeed = 0 when linearizing
   FAST, the generator should be locked in place!

v4.30g-jmj, 01-Aug-2003  J. Jonkman
 I fixed a bug in the calculation of tip brake drag forces initiated by rotor
   speed.  This bug originated from the changes made during version 4.22a-jmj.
   The fix required a minor change to SUBROUTINE FAST.f90/RtHS().
 I doubled the size of the displacement and velocity pertubations, DelQ() and
   DelQD(), in SUBROUTINE FAST_Lin.f90/Linearize() so that the magnitudes are
   closer to to those given in program SymDyn.
 I coded the logic for the new input variable MdlOrder.  This required
   extensive additions to SUBROUTINE FAST_Lin.f90/Linearize().
 I coded the logic for outputting the linearized matrices related to the output
   measurements also requiring extensive additions to
   SUBROUTINE FAST_Lin.f90/Linearize().
 I coded the logic for outputting the linearized matrices related to the
   control inputs and input wind disturbances through new inputs CntrlInpt,
   NDisturbs, and Disturbnc.  This required extensive additions to SUBROUTINE
   FAST_Lin.f90/Linearize(), and minor changes to MODULE fast_mods.f90/Linear()
   and SUBROUTINEs fast_io.f90/GetLin() and FAST.f90/DrvTrTrq().
 I also changed the logic for how the mass, stiffness, and damping matrices are
   computed for the 2nd order model (MdlOrder = 2).  Now these matrices are
   computed using the 1st order state matrix, [A].
 I changed more of the format and contents of the FAST linearization output
   file (the .lin file).
 I added a local INTEGER(4) PARAMETER variable named IterRtHS to SUBROUTINE
   FAST_Lin.f90/Linearize().  This variable is used to cause FAST to loop
   through RtHS() every time a DOF or input is pertubed when linearizing FAST.
   This is used to counteract the problems arising in AeroDyn since the
   iteration for the induction factor starts from the previous states.  This
   variable makes FAST mimic what SymDyn does.  However, we testing the
   variable, I found that the number of iterations on RtHS() made little
   difference on the resulting state matrices.  So I disabled the extra
   iterations by setting IterRtHS to 1 (but the functionality is still
   available by changing the value of IterRtHS).

v4.30h-jmj, 05-Aug-2003  J. Jonkman
 I added an additional output names for channels TipAcxk and TipAcyk as
   follows: OoPAccelk and IPAccelk (where k = 1,2,3--the blade number).  This
   required a minor change to SUBROUTINE() fast_io.f90/ChckOutLst().  The
   previos output channel names still work.  This addition was requested by M.
   Buhl.

v4.30i-mlb, 07-Aug-2003  M. Buhl
 I fixed the bug in fast_io.f90\SimStatus() that caused some of the status messages
   to display stars instead of numbers in some of the time fields.
 I modified SetVersion() so that it mentioned the precision only if it is not
   single.

v4.30i-mlb, 11-Aug-2003  M. Buhl
 I set the units for ROOTMXC2 and ROOTMIP2 in fast_io.f90\ChckOutLst().  These
   were accidently left out.

v4.30j-jmj, 19-Aug-2003  J. Jonkman
 In routine FAST2ADAMS.f90/MakeADM(), I added a check to make sure ARRAY/1 is
   not written to the ADAMS .adm file if NumOuts is 0 (otherwise, ADAMS would
   crash).
 I added source files SysLU.f90 and ModLU.f90 to the FAST archive.  These
   source files should be used in place of SysCVF.f90 and ModCVF.f90 when
   compiling FAST in Lahey Unix (LU stands for Lahey Unix; CVF stands for
   Compact Visual Fortan).  Source files SysCVF.f90 and ModCVF.f90 should
   be used in place of SysLU.f90 and ModLU.f90 when compiling FAST using
   Compact Visual Fortan.

v4.30k-jmj, 22-Aug-2003  J. Jonkman
 I incorporated the changes made to FAST by PJM (Pat Moriarty of NREL)
   associated with noise prediction.  Pat called his version of FAST v4.10, but
   it was never officially released as that.  His noise prediction algorithms
   are now included in this version.  I altered several of his changes so that
   his code is compatible with the upgraded version of FAST documented in this
   ChangeLog.  Pat did not make change log comments of his changes, but he
   documented some of his work in the following reference:
      Moriarty, P. J.; Migliore, P.G.  Semi-Empirical Aeroacoustic Noise
      Prediction Code for Wind Turbines, NREL/TP-500-34478.  Golden, Colorado:
      National Renewable Energy Loboratory, 2003.

v4.30l-jmj, 26-Aug-2003  J. Jonkman
 Its my birthday today!  Wahoo!
 I linked FAST to the latest version of AeroDyn, 12.55.
 I changed routines fast_io.f90/GetBlade(), GetTower(), and GetPrimary() so
   that the input variables which are currently ignored (including CalcBMode,
   CalcTMode, TiDynBrk, PSpnElN, and DynBrkFi) are not read in.

v4.30, 05-Sep-2003  J. Jonkman
 I rolled up all the alpha changes into this new version.  I eliminated all
   alpha comments.

v4.31a-jmj, 25-Sep-2003  J. Jonkman
 I added the logic for computing a trim solution to SUBROUTINE
   FAST_Lin.f90/CalcSteady().
 In SUBROUTINE FAST_Lin.f90/CalcSteady(), I added artificial damping to the
   blade, tower, and drivetrain in order to improve convergence.  This didn't
   improve the convergence times much and, in fact, made the solution more
   unstable.  Thus, I disabled it by setting the gain for artificial damping,
   KDamp, to zero.
 In SUBROUTINE FAST_IO.f90/GetLin(), I now make sure that the pitch angles are
   identical when trimming rotor collective blade pitch (TrimCase = 2).
 I added more constraints on the inputs to prevent a FAST from performing a
   poor linearization analysis.
 I added more columns of information to the simulation status that is written
   to the screen during the computation of a steady state solution for FAST
   linearization.  This required a minor change to SUBROUTINE
   FAST_Lin.f90/CalcSteady().
 I modified the value of the generator torque pertubation, DelGenTrq, so that
   it is accurate for a wider variety of turbine configurations (based on
   testing).
 I modified how the generator torque pertubation, DelGenTrq, effects the
   torques during a FAST linearization analysis.  This require changes to
   routines FAST.f90/DrvTrTrq() and UserSubs.f90/UserGen().  The change to
   UserGen() required a minor change to source file SFOSUB_FAST.f90 in A2AD.
 In the header of the <RootName>.lin output file, I updated the description of
   the type of steady state solution found.  This required a minor change to
   SUBROUTINE FAST_Lin.f90/Linearize().

v4.31b-jmj, 26-Sep-2003  J. Jonkman
 I changed the operating point values from zero to the initial conditions when
   CalcSteady is set to False.  This way FAST can linearize a model about an
   operating point indicated by the user.  This upgrade required minor changes
   to PROGRAM FAST.f90/FAST() and SUBROUTINE FAST_Lin.f90/Linearize().

v4.31c-jmj, 02-Oct-2003  J. Jonkman
 I removed the natural frequencies from the FAST summary data file (the
   <RootName>.fsm file) since these frequencies were very rough estimates
   (innaccurate) and much more accurate frequencies are now available throuh
   FAST's linearization capability.  Frankly, I didn't want anyone using these
   valeus.  This required changes to SUBROUTINE FAST_IO.f90/PrintSum().

v4.31d-jmj, 03-Oct-2003  J. Jonkman
 I fixed a bug in SUBROUTINE AeroCalc.f90/Set_FAST_Params().  The definition of
   variables CAeroTwst and SAeroTwst needed indices in them.  This bug was made
   when incorporating Pat's aeroacoustics algorithms in v4.30k-jmj and affected
   all of the FAST and FAST-to-ADAMS results for models with an appreciable
   range in aerodynamic twist!  Thanks Erik Withee for leading me to this bug.

v4.31, 03-Oct-2003  J. Jonkman
 I rolled up all the alpha changes into this new version.  I eliminated all
   alpha comments.

v4.40a-jmj, 08-Oct-2003  J. Jonkman
 I renamed the default primary input file from "primary.fad" to "primary.fst"
   in MODULE FAST_MODS.f90/General().  This change was requested by M. Buhl.
 I added a reference to whether CompNoise is Enabled/Disabled in the FAST
   summary file (<RootName>.fsm file).  This required a minor change to
   SUBROUTINE FAST_IO.f90/PrintSum().
 In the FAST-to-ADAMS preprocessor, I made sure the DEACTIVATE statements
   pertaining to the fixed pitch MOTION are not included in the ADAMS control
   file (.acf) of a simulation if it will be running with fixed pitch
   throughout the entire simulation.  This required a minor change to
   SUBROUTINE FAST2ADAMS.f90/MakeACF() and resulted in minor changes to the
   comparisons between FAST and ADAMS (the comparisons were all a little
   better).
 I fixed a bug in the FAST-to-ADAMS preprocessor that manifested itself in
   flexible blades with large elastic offsets.  The reference LENGTH in the
   blade FIELD statements should depend on the elastic offsets.  This required
   a couple of minor changes to SUBROUTINE FAST2ADAMS.f90/MakeADM().
 I compiled FAST.exe using Compaq Visual Fortran (CVF) version 6.6.B.  This did
   not bring about any differences relative to the results obtained when
   compiling using CVF version 6.6.A.

v4.40b-jmj, 09-Oct-2003  J. Jonkman
 I added the twist/flap coupling coefficient, Alpha, to the distributed
   properties of the blade input files.  These twist/flap coupling effects are
   now included in the extracted ADAMS datasets (they do not affect the results
   of FAST).  This required minor changes to MODULE FAST_MODS.f90/Blades(),
   SUBROUTINES FAST_IO.f90/GetBlade(), Input(), InterpBld(), and PrintSum(),
   and SUBROUTINE FAST2ADAMS.f90/MakeADM().

v4.40c-jmj, 27-Oct-2003  J. Jonkman
 I add the precurve and presweep inputs to the distributed properties of the
   blade input files.  These are named PrecrvRef and PreswpRef and are offsets
   that define a reference axis relative to the pitch axis for precurved and
   preswept blades.  These effects are now included in the extracted ADAMS
   datasets (they do not affect the results of FAST).  This required minor
   changes to MODULE FAST_MODS.f90/Blades(), SUBROUTINES
   FAST_IO.f90/GetBlade(), Input(), InterpBld(), and PrintSum(), SUBROUTINE
   FAST.f90/Initialize(), and SUBROUTINE FAST2ADAMS.f90/MakeADM().

v4.40d-jmj, 28-Oct-2003  J. Jonkman
 In SUBROUTINE FAST_IO.f90/ReadRAry(), I fixed a minor bug as requested by
   Marshall Buhl.  This change does not affect the results of FAST.

v4.40e-jmj, 07-Nov-2003  J. Jonkman
 I added output parameters for examining the blade torsional deflections from
   ADAMS simulutions run using ADAMS datasets created using the FAST-to-ADAMS
   preprocessor.  These are TipRDzc1 (or TipRDzb1) for blade 1, TipRDzc2 (or
   TipRDzb2) for blade 2, and TipRDzc3 (or TipRDzb3) for blade 3.  I also
   added output parameters for examining the tower torsional deflection,
   velocity, and acceleration from ADAMS simulutions run using ADAMS datasets
   created using the FAST-to-ADAMS preprocessor.  These are YawBrRDzt for
   torsional deflection, YawBrRVzt for torsional velocity, and YawBrRAzt for
   torsional acceleration.  All of these outputs are always zero for FAST
   simulation results.  This required minor changes to MODULE
   FAST_MODS.f90/Output() and SUBROUTINEs FAST_IO.f90/ChckOutLst() and
   FAST.f90/CalcOuts().  This feature was requested by D. Laino.

v4.40f-jmj, 11-Dec-2003  J. Jonkman
 In SUBROUTINE, FAST2ADAMS.f90/MakeADM(), I deleted MARKER 2105 and renamed
   MARKER 2100 to "NacelleCS_M" since the nacelle / yaw coordinate system is
   now located at the tower-top / yaw bearing.
 I added a calculation for the electrical generator power in SUBROUTINE
   UserSubs.f90/UserVSCont().  This calculation use to be located in SUBROUTINE
   FAST.f90/DrvTrTrq() directly after the call to UserVSCont().
 I modified the parameter lists of SUBROUTINEs UserGen() and UserVSCont() so
   that the same parameters are passed to/from the SUBROUTINEs.
 I added a CALL to SUBROUTINE UserVSCont() from SUBROUTINE UserGen() so that
   both SUBROUTINEs, do exactly the same thing--that is, both use K. Pierce's
   sample variable-speed torque controller, which uses a torque-speed lookup
   table.   To complete this chagne, I modified the parameter lists of
   SUBROUTINEs UserGen() and UserVSCont() so that the same parameters are
   passed to/from both SUBROUTINEs.  This required minor changes to SUBROUTINEs
   FAST.f90/DrvTrTrq() and FAST2ADAMS.f90/MakeADM().  This change was requested
   by C. Hansen and Jean-Guillaume Lonjaret.

v4.40, 11-Dec-2003  J. Jonkman
 I rolled up all the alpha changes into this new version.  I eliminated all
   alpha comments.

-------------------------------------------------------------------------------
--------------------------- FAST v5. ------------------------------------------
-------------------------------------------------------------------------------

v5.00a-jmj, 19-Dec-2003  J. Jonkman
 I modified the inputs for the new FAST furling functionality.  Since this is a
   major modification to FAST (in terms of its impact on the equations of
   motion), I decided to roll the digit before the decimal.  The changes to the
   primary input file are as follows:
   REMOVED: TiltDOF, NacTilt, ParaDNM, PerpDNM, NacTIner, and all of the
            NACELLE-TILT section including the header plus inputs TiltSpr,
            TiltDamp, TiltSStP, TiltHStP, TiltSSSp, and TiltHSSp.
   ADDED:   NacCMxn, NacCMyn, NacCMzn (all these replace ParaDNM and PerpDNM),
            ShftTilt (between TwrRBHt and Delta3), YawBrMass (before NacMass),
            and a new FURLING section including the header plus inputs Furling
            and FurlFile (this section replaces the NACELLE-TILT section).
   In order to obtain equivalent models between FAST v4.40 and FAST v5.00 (for
   a nontilting turbine) set the following values for the new inputs:
            NacCMxn   = ParaDNM*COS(NacTilt) - PerpDNM*SIN(NacTilt)
            NacCMyn   = 0.0
            NacCMzn   = ParaDNM*SIN(NacTilt) + PerpDNM*COS(NacTilt) + Twr2Shft
            ShftTilt  = NacTilt
            YawBrMass = 0.0
            Furling   = False
            FurlFile  = <may be left blank>
   For a tilting turbine, you will now need to create a FurlFile.
 I added code and variables for reading in the new inputs from the furling
   input file, FurlFile.

v5.00b-jmj, 14-Jan-2004  J. Jonkman
 I fixed a bug involving input SpdGenOn.  It was never converted from RPM to
   RPS internally, even though it should have been.  This required a minor
   addition to SUBROUTINE FAST_IO.f90/Input().
 I fixed a bug in the computation of CMat for outputs LSSTipPxa and LSSGagPxa.
   This bug was caused by the use of function MOD when computing outputs
   LSSTipPxa and LSSGagPxa in SUBROUTINE CalcOuts().  To fix this bug I added
   LOGICAL(1) variable IgnoreMOD (for "Ignore MOD") to MODULE
   FAST_MODS.f90/Linear() and made use of it in SUBROUTINEs FAST.f90/CalcOuts()
   and FAST_Lin.f90/Linearize().  IgnoreMOD is initialized to .FALSE. in MODULE
   Linear so that it does not effect the results of any other outputs.
 I made input variable HubIner available for both 2- and 3-bladed rotor
   configurations.  HubIner is the hub inertia about the rotor axis [for
   3-bladers] or teeter axis [for 2-bladers].  For 2-bladers, the definition of
   HubIner is unchanged.  This change had a small effect on MODULE
   FAST_MODS.f90/MassInert() and SUBROUTINEs FAST_IO.f90/GetPrimary(),
   FAST.f90/Coeff(), and RtHS().
 In SUBROUTINE FAST_IO.f90/PrintSum() I added logic so that the rotor
   configuration (i.e., upwind / downwind) is printed in the FAST summary file
   (.fsm) when SumPrint = True.
 I modified SUBROUTINE UserSubs.f90/UserTeet() so that the current simulation
   time, ZTime, is now a passed variable.  This is to maintain consistency with
   the other user-defined routines.
 In SUBROUTINE AeroCalc.f90/Set_AD_Params() I removed the initialization of
   AeroDyn variables TILT, CTILT, STILT, and YawAng since AeroDyn does not need
   to know these values before the first time step.
 I implemented logic for the new FAST furling functionality.  This required
   extensive changes to the inner-workings of FAST--especially the formulation
   of the equations of motion.

v5.00c-jmj, 05-Feb-2004  J. Jonkman
 I incorporated changes to the noise calculations that were suggested by Pat
   Moriarty.  This required the addition of SUBROUTINE NoiseSubs.f90/CalcFFTI()
   and changes to MODULE NoiseMods.f90/Noise() and SUBROUTINEs
   AeroCalc.f90/Set_FAST_Params() and NoiseSubs.f90/InflowNoise(),
   WriteSPLOut(), and CalcHHTI().  Here is his description of these changes:
      "Corrections to aeroacoustic noise routines.  In the turbulent inflow
      model, the turbulent intensity and mean wind speed are now calculated
      starting from TStart for both hub height and full field wind files.  The
      directivity of the turbulent inflow noise has been modified to behave
      like a low-frequency noise source below a cut off frequency proportional
      to the local velocity and inversely proportional to the chord length.
      Above this cut off frequency the directivity is assumed to be that of a
      high-frequency noise source."

v5.00d-jmj, 27-Feb-2004  J. Jonkman
 I removed the pitching moment term from the tail fin aerodynamic loads
   calculation.  This required minor changes in MODULE FAST_Mods.f90/Output()
   and SUBROUTINEs FAST_IO.f90/ChckOutLst(), FAST.f90/CalcOuts(),
   AeroCalc.f90/TFinAero(), and UserSubs.f90/UserTFin().  Note that input
   parameter TFinChord has been removed from the FAST furling input file and
   that the tail fin pitching moment terms are no longer available output
   parameters because of this change.
 I added blade tip-to-tower clearance output parameters for all blades.  These
   are named TipClrnc1 (or TwrClrnc1 or Tip2Twr1) for blade number 1 (and
   similarly for blades 2 and 3).  This required minor changes to MODULE
   FAST_Mods.f90/Output() and SUBROUTINEs FAST_IO.f90/ChckOutLst() and
   FAST.f90/CalcOuts().
 In FAST.f90/RtHS(), I now pass to AeroDyn properties of the actual aerodynamic
   center location, not just properties for current point S.  This should
   produce minor differences relative to earlier versions of the code only when
   AeroCent(:) inputs are much different than 0.25.
 I made changes to the ADAMS-specific-input data file in order to handle the
   new FAST furling functionality and modified FAST accordingly.  The changes
   to the ADAMS-specific-input data file are as follows (these only affect
   GRAPHICS output):
   REMOVED: TetPnLngth and TeetPinRad since I didn't think the teeter pin
               GRAPHICS were very useful.
   ADDED:   LSSLength - this is the length of LSS and determines the distance
               from the rotor apex (3-blades) or teeter pin (2-blades) to the
               center of the gearbox [in prior versions, the LSS extended from
               the rotor apex (3-blades) or teeter pin (2-blades) to the yaw
               axis so that the gearbox was centered about the yaw axis]
            BoomRad - this is the radius of the tail boom CYLINDER used for
                tail boom GRAPHICS.
   In order to obtain equivalent GRAPHICS output between ADAMS datasets
   generated using FAST v4.40 and those geneated using FAST v5.00, set the
   following values for the new inputs:
            LSSLength = ABS(OverHang)
            BoomRad   = 0.0
 I implemented logic for the new FAST furling functionality into the
   FAST-to-ADAMS preprocessor.  This required extensive changes to the inner-
   workings of the FAST-to-ADAMS preprocessor.
 I have the FAST-to-ADAMS preprocessor now align the hub GRAPHICS CYLINDERs
   with the coned coordinate systems instead of extending from the hub center
   of mass location.  This required a minor change to SUBROUTINE
   FAST2ADAMS.f90/MakeADM().
 I renumber the SFORCE for user-defined rotor-teeter models from 4011 to 4010
   in the FAST-to-ADAMS preprocessor.  This required a minor change to
   SUBROUTINE FAST2ADAMS.f90/MakeADM().

v5.00e-jmj, 03-Mar-2004  J. Jonkman
 I added output parameters for an estimate of the location of the rotor center
   of thrust.  These outputs are named CThrstAzm and CThrstRad (or CThrstArm).
   The outputs are estimated by using values of output parameters LSSTipMys,
   LSSTipMzs, and RotThrust.  This required minor changes to MODULE
   FAST_Mods.f90/Output() and SUBROUTINEs FAST_IO.f90/ChckOutLst() and
   FAST.f90/CalcOuts().
 I fixed a bug in SUBROUTINE PitchCntrl.f90/PitchCntrl().  BlPitch is not a
   passed argument.  This change does not affect the results of FAST.

v5.00, 12-Mar-2004  J. Jonkman
 I rolled up all the alpha changes into this new version.  I eliminated all
   alpha comments.

v5.10a-jmj, 26-Apr-2004  J. Jonkman
 I added input CntrlRgn between the file description and input NCNST in file
   'pitch.ipt' for Craig Hansen's default pitch control routine, which is
   linked with the distributed version of FAST.  CntrlRgn is the control region
   {CntrlRgn = 2 = power control, 3 = speed control}.  In order to obtain
   equivalent models between FAST v5.00 and FAST v5.10 (i.e., to use same pitch
   control routine) set the following values for the new input:
      CntrlRgn  = PCMode + 1 (since PCMode = 1 = power control, PCMode = 2 =
         speed control in FAST v5.0)
   Naturally, I also modified SUBROUTINE PitchCntrl_ACH.f90/PitchCntrl() to
   handle this new input variable.
 I removed argument TFInput and added arguments ElecPwr, HSS_Spd, and GBRatio
   to the user-defined routine PitchCntrl() since the pitch control routine
   itself now determines whether to control power (region 2) or speed (region
   3).  I also added argument BlPitch so that current blade pitch angles,
   BlPitch, are passed to routine PitchCntrl() independently of the command
   (demand) pitch angles, TFOutput, that are returned by the routine--this
   helped to greatly simplify the logic in SUBROUTINE FAST.f90/Control().
   These changes required minor changes to SUBROUTINEs FAST.f90/Control(),
   PitchCntrl_ACH.f90/PitchCntrl(), and PitchCntrl.f90/PitchCntrl().
 I upgraded FAST to handle yaw control and to permit its interface with
   Simulink.  The changes to the primary input file are as follows:
   CHANGED: PCMode - Pitch control mode so that {0: none, 1: user-defined from
               routine PitchCntrl, 2: user-defined from Simulink} (switch)
            VSContrl - Variable speed control mode so that {0: none, 1: simple
               VS, 2: user-defined from routine UserVSCont, 3: user-defined
               from Simulink} (switch)
   ADDED:   YCMode and TYCOn before PCMode in the Turbine Control section -
               these define yaw control options like inputs PCMode and TPCOn do
               for pitch control.
            TYawManS, TYawManE, and NacYawF between TBDepISp(3) and TPitManS(1)
               in the Turbine Control section - these define override yaw
               control options like inputs TPitManS, TPitManE, and BlPitchF do
               for pitch control.
   In order to obtain equivalent models between FAST v5.00 and FAST v5.10
   (i.e., no yaw control) set the following values for the new and changed
   inputs:
      YCMode    = 0
      TYCOn     = 9999.9 (a don't care)
      PCMode    = 0 if PCMode was 0 in FAST v5.0
                  1 if PCMode was 1 or 2 in FAST v5.0
      VSContrl  = same as the value of VSContrl in FAST v5.0
      TYawManS  = 9999.9 (a don't care > TMax)
      TYawManE  = 9999.9 (a don't care >= TYawManS)
      NacYawF   = 0.0    (a don't care)
 I incorporated logic for yaw control in FAST and the FAST-to-ADAMS
   preprocessor.
 I moved the CALL to SUBROUTINE Control() from TimeMarch() to the beginning of
   RtHS().  Control() is not called the first time step in order to maintain
   consistency with the old method of calling Control() and since most control
   measurements that could be passed to the control routines will not have been
   defined until after the first time step has passed.  This change was needed
   in order to interface FAST with Simulink.  In order to make this change work,
   I had to use a local array named BlPitchop in SUBROUTINE
   FAST_Lin.f90/Linearize() instead of the global array TmpBlPitch, which is
   used in routine Control().
 I moved the declaration of array AllOuts() from SUBROUTINE FAST.f90/CalcOuts()
   to MODULE FAST_Mods.f90/Output() so that all of the outputs can be accessed
   by user-defined control routines.
 I moved the CALL to SUBROUTINE CalcOuts() from WrOutput() to TimeMarch() so
   that array AllOuts() is updated every time step (instead of every DecFact
   number of timesteps) so that it can be used in user-defined control
   routines.
 I moved PROGRAM FAST() from source file FAST.f90 to its own, new source file,
   FAST_Prog.f90.  This was necessary so that Maureen Hand, while compiling
   FAST as an S-Function for Simulink, can compile the routines in FAST.f90
   without using PROGRAM FAST().
 In MODULE FAST_Mods.f90/General(), I added LOGICAL(1) variable Cmpl4SFun and
   initialized it to .FALSE..  This variable is used by FAST to determine
   whether or not FAST has been compiled as an S-Function for Simulink [it will
   be set to .TRUE. by the routine (to be written by M. Hand) used to interface
   FAST with Simulink].
 In SUBROUTINE SetVersion.f90/SetVersion(), I made the ProgVer more descriptive
   based on the value of variables Cmpl4SFun and ReKi.
 In source files NoiseMods.f90 and NoiseSubs.f90, I changed all of the REAL and
   REAL(4) declarations to REAL(ReKi) declarations and changed the REAL(8)
   declarations to REAL(DbKi) declarations to maintain consistency with the
   rest of the code.  I also alphabatized all of the variable declarations.
 In source file NoiseSubs.f90, I changed all the ALOG10() FUNCTIONs to LOG10()
   FUNCTIONS so that we could compile these noise routines in double precision.
 I removed the ramp-up of aerodynamic loads over the first 2.0 seconds of
   simulation in SUBROUTINE AeroCalc.f90/AeroCalc() since it caused the torque
   controller in Simulink to go crazy.  Besides, it was never numerically
   necessary in FAST and is not necessary in ADAMS when using the FAST-to-ADAMS
   preprocessor.
 I removed redundant initial condition variables and soft-switch arrays, Z and
   ZD and IZ and IZD respectively, from the code.  I could do this since
   SUBROUTINE FAST.f90/RtHS() forces the accelerations to equal zero, resulting
   in the same thing.  This change was also required when implementing yaw
   control with YawDOF disabled (i.e., the user-defined yaw controller
   prescribes the actual yaw angle and yaw rate with no actuator) since
   SUBROUTINE Solver() would have overwritten the yaw demands the way it was
   previously implemented.  I also replaced INTEGER(4) array IZD() with
   LOGICAL(1) array DOF_Flag(), which is stored in MODULE FAST_Mods.f90/DOFs().
   I also removed the initialization of the data in column NMX of the Q and QD
   arrays since these calclations were useless.  These changes resulted in
   remarkable simplifications to SUBROUTINEs FAST.f90/Initialize() and Solver()
   and the ability to add yaw control.
 I made the error message for the blade flap/twist coupling coefficient more
   descriptive.  This change was requested by K. Pierce.
 I renamed interal array FirstTHere with the more descriptive name BegPitMan.
 I made the logic for the override pitch maneuver more elegant, like how it is
   implemented in the FAST-to-ADAMS preprocessor.  This required replacing
   array DelBlPitch with arrays BlPitchI and BlPitchFrct, which are stored in
   MODULE FAST_Mods.f90/TurbCont().
 I updated all of the source lines longer than 132 characters so that they are
   132 characters or less (the standard freeform FORTRAN limit).  Comments past
   132 characters don't matter.  I did not document these changes in the code.
 I made a couple of IF...THEN tests in SUBROUTINEs FAST2ADAMS.f90/MakeADM() and
   NoiseSubs.f90/PredictNoise() compliant with the freeform FORTRAN standard.

v5.10b-jmj, 06-May-2004  J. Jonkman
 I upgraded the FAST linearization routines to handle yaw control inputs.  The
   changes to the linearization input file are as follows:
   ADDED:   NInputs - Number of control inputs [0 (none) or 1 to 4+NumBl] (-)
               before CntrlInpt
   CHANGED: TrimCase - Trim case so that {1: find nacelle yaw, 2: find
               generator torque, 3: find collective blade pitch} (switch) [used
               only when CalcStdy=True and GenDOF=True]
            CntrlInpt - List of control inputs [1 to NInputs] {1: nacelle yaw
               angle, 2: nacelle yaw rate, 3: generator torque, 4: collective
               blade pitch, 5: individual pitch of blade 1, 6: individual pitch
               of blade 2, 7: individual pitch of blade 3 [unavailable for
               2-bladed turbines]} (-) [unused if NInputs=0]
   In order to obtain equivalent models between FAST v5.00 and FAST v5.10
   (i.e., no yaw control in linearization) set the following values for the new
   and changed inputs:
      TrimCase  = 2 if TrimCase was 1 in FAST v5.0
                  3 if TrimCase was 2 in FAST v5.0
      NInputs   = 0       if CntrlInpt was 0 in FAST v5.0
                  1       if CntrlInpt was 1 or 2 in FAST v5.0
                  NumBl   if CntrlInpt was 3 in FAST v5.0
                  2       if CntrlInpt was 4 in FAST v5.0
                  1+NumBl if CntrlInpt was 5 in FAST v5.0
      CntrlInpt = <may be left blank> if CntrlInpt was 0 in FAST v5.0
                  3       if CntrlInpt was 1 in FAST v5.0
                  4       if CntrlInpt was 2 in FAST v5.0
                  5,6     if CntrlInpt was 3 and NumBl=2 in FAST v5.0
                  5,6,7   if CntrlInpt was 3 and NumBl=3 in FAST v5.0
                  3,4     if CntrlInpt was 4 in FAST v5.0
                  3,5,6   if CntrlInpt was 5 and NumBl=2 in FAST v5.0
                  3,5,6,7 if CntrlInpt was 5 and NumBl=3 in FAST v5.0
 I moved local variables YawPosCom and YawRateCom from SUBROUTINE
   FAST.f90/Control() to MODULE FAST_Mods.f90/TurbCont() so that they could be
   accessed by Simulink.
 I added a few test conditions on some of the input parameters based on the
   value of variable Cmpl4SFun since FAST with Simulink wont work for all
   possible input settings.  This required minor changes to SUBROUTINEs
   FAST_IO.f90/Input(), GetPrimary(), and SetVersion.f90/SetVersion().
 I added logic so that the ".out", ".fsm", ".opt", ".elm", ".nos", ".spl",
   ".spa", and ".cho" output files will use the <RootName> appended with
   "_SFunc" when FAST is compiled for use with Simulink--that is, when
   Cmpl4SFun = .TRUE..
 To make it more descriptive, I have updated the comment about AllOuts() at the
   beginning of each of the source files containing user defined routines.

v5.10c-jmj, 14-May-2004  J. Jonkman
 In MODULE FAST_Mods.f90/General(), I renamed INTEGER(4), PARAMETER Flag to
   FlagType to eliminate a variable name conflict in Simulink.  This required
   minor changes to SUBROUTINEs FAST_IO.f90/GetPrimary(), ReadLVar(), and
   GenUse.f90/CheckIOS() and does not effect any results from FAST.

v5.10d-jmj, 19-May-2004  J. Jonkman
 In SUBROUTINE FAST.f90/RtHS(), I moved the CALL to Control() from after the
   variable initializations to before the variable initializations so that
   TwrAccel would be computed correctly in Control().  This bug was created in
   FAST v5.10a and found by A. Wright.
 I added files FAST_SFunc.dll, Read_FAST_Input.m, SimulinkSamples/Simsetup.m,
   SimulinkSamples/OpenLoop.mdl, and SimulinkSamples/Test01_SIG.mdl to the
   FAST archive.

v5.10e-jmj, 16-Sep-2004  J. Jonkman
 I fixed a bug in the linearization routines as follows:  when trimming
   generator torque (TrimCase == 2), the generator torque was not being
   perturbued properly, which lead to an error in the input matrix, [B],
   associated with the generator torque.  This bug only manifested itself when
   TrimCase == 2 and when CntrlInpt 3 was selected in the FAST linearization
   input file.  Fixing this bug required minor changes to SUBROUTINEs
   FAST.f90/DrvTrTrq() and FAST_Lin.f90/Linearize().  Thank you to Alan Wright
   for finding this bug.
 I added names GenSpeed and GenAccel to the list of other names available with
   the output parameters whose primary names are HSShftV and HSShftA
   respectively.
 I upgraded FAST to permit user-defined high-speed shaft braking torque.  The
   changes to the primary input file are as follows:
   ADDED:   HSSBrMode in the Turbine Control section - this switch defines the
               HSS brake model {1: simple, 2: user-defined from routine
               UserHSSBr}
   In order to obtain equivalent models between FAST v5.00 and FAST v5.10
   (i.e., no user-defined HSS brake) set the following value for the new input:
      HSSBrMode = 1
 I incorporated logic for user-defined HSS brake control in FAST and the
   FAST-to-ADAMS preprocessor.  These changes were requested by GE Wind Energy
   and Nothern Power Systems.
 I simplified the logic for the HSS brake correction to make available the
   user-defined HSS brake model.  I eliminated the setting of
   DOF_Flag(DOF_GeAz) = .FALSE. by SUBROUTINE FixHSSBrTq().  I was able to
   do this since I now always run through the logic in FixHSSBrTq() after ZTime
   > THSSBrDp regardless of whether the direction of the HSS has been reversed
   by the HSS brake.  This required changes to MODULE FAST_Mods.f90/RtHndSid()
   and SUBROUTINEs FAST.f90/Alloc(), FixHSSBrTq(), RtHS(), ans Solver().
 I replaced local ALLOCATable array QD2TOld(:) in SUBROUTINE
   FAST.f90/FixHSSBrTq() with array QD2TC(:) now stored in MODULE
   FAST_Mods.f90/RtHndSid() and ALLOCATEd in SUBROUTINE FAST.f90/Alloc().
 I simplified the implementation of the HSS brake in the FAST-to-ADAMS
   preprocessor to make available the user-defined HSS brake model.  I did this
   by maintaining a constant FRICTION_TORQUE_PRELOAD in FRICTION/3151 and by
   changing the shape of SFORCE/3151 from a single saw-tooth shaped function to
   a call to routine SFOSUB().  SFORCE/3151 is used to cancel out part or all
   of the brake torque from the FRICTION/3151 statement when the HSS brake is
   not fully applied (the logic for this is now in SFOSUB).  In the
   FRICTION/3151 statement, I also replaced the 0.0001 in the
   STICTION_TRANSITION_VELOCITY argument with SmllNmbr, which is a generic
   small number instead of what used to look like a "reasonable" small number.
   These changes required minor changes to SUBROUTINEs FAST2ADAMS.f90/MakeACF()
   and MakeADM() and were based off suggestions from Kirk Pierce.
 I added a new SUBROUTINE named SmllRotTrans() to source file FAST.f90.  This
   routine computes the 3x3 transformation matrix, TransMat, to a coordinate
   system x (with orthogonal axes x1, x2, x3) resulting from three rotations
   (Theta1, Theta2, Theta3) about the orthogonal axes (X1, X2, X3) of
   coordinate system X.  All angles are assummed to be small, as such, the
   order of rotations does not matter and Euler angles do not need to be used.
   This routine is now used to compute the transformation matrix (TransMat)
   between undeflected (X) and deflected (x) coordinate systems of the tower
   and blades in SUBROUTINE FAST.f90/SetCoordSy() and FAST2ADAMS.f90/MakeADM().
   The new transformation matrix, TransMat, replaces the old deflected member
   transformation matrices used by routines SetCoordSy() and MakeADM() with a
   more exact correction to the Bernoulli-Euler transformation matrix.  It was
   derived using the singular value decomposition of the Bernoulli-Euler
   transformation matrx.  Please see routine SmllRotTrans() for more
   information.  This new transfromation matrix should yield better response
   predictions of blade and tower deflections and ensuing dynamic responses
   (i.e., compared to ADAMS) and also allows the transformation matrix to
   include the effects of torsional DOFs in future releases of the code.
 I moved the example user-defined routines written by Kirk Pierce (KP),
   UserGen() and UserVSCont(), from source file UserSubs.f90 to their own, new
   source file, UserVSCont_KP.f90.  I also added commented-out dummy
   placeholders of routines UserGen() and UserVSCont() to source file
   UserSubs.f90.  I also removed source file PitchCntrl.f90 from the FAST
   archive and moved its dummy placeholder PitchCntrl() routine to source file
   UserSubs.f90 (this is commented out in UserSubs.f90).  These changes were in
   preparation of adding example routines for interfacing FAST with
   Bladed-style DLL controllers (see next change).
 In the example user-defined variable-speed control SUBROUTINE
   UserSubs.f90/UserVSCont() written by Kirk Pierce, I placed a check on
   GBRatio so that FAST will Abort if GBRatio is not unity.  I added this
   condition since this example routine returns the generator torque cast to
   the LSS side of the gearbox, whereas routine UserVSCont() should be
   returning the torque on the HSS side.  Thus, the example routine, as
   implemented, will only work if the LSS and HSS speeds are the same.  This
   change was requested by B. Jonkman and N. Kelley to prevent them and other
   user's from making mistakes.
 In source file SysCVF.f90, I added SUBROUTINE Get_CWD(), which is used to
   retrieve the path of the current working directory.  I did NOT add this
   routine to source files SysLL.f90 or SysLU.f90 since I am not sure how to.
   User's of Lahey Linux and/or Lahey Unix most modify SysLL.f90 and/or
   SysLU.f90 respectively in order to recompile this new version of FAST.
 I added CHARACTER(1024) variable DirRoot to MODULE FAST_Mods.f90/General().
   This string stores the name of the root file including the full path to the
   current working directory and is now defined in SUBROUTINE FAST.f90/Begin().
   The definition of DirRoot makes use of the new Get_CWD() SUBROUTINE.
 I add the number of blades, NumBl, to the list of parameters passed to
   user-defined SUBROUTINEs UserGen(), UserVSCont(), and UserYawCont().  I also
   added the time step, DT, to the list of parameters passed to user-defined
   SUBROUTINEs PitchCntrl() and UserYawCont().  I also added the name of the
   root file including the full path to the current working directory, DirRoot,
   to the list of parameters passed to ALL of the user-defined SUBROUTINEs.
   These changes were made in order to support the new interface to the
   Bladed-style DLL controllers (see later change).
 I added source file Source/BladedDLLInterface.f90 to the FAST archive.  This
   source file contains example PitchCntrl(), UserHSSBr(), UserVSCont(), and
   UserYawCont() routines, which can be used to interface FAST with a master
   controller implemented as a dynamic-link-library (DLL) in the style of
   Garrad Hassan's Bladed wind turbine software package.  All four routines
   call routine BladedDLLInterface(), also contained in source file
   BladedDLLInterface.f90, which contains a call to the Bladed-style DLL that
   evaluates as DISCON().  Routine BladedDLLInterface() USEs a MODULE named
   BladedDLLParameters(), also contained in source file BladedDLLInterface.f90,
   which stores values of PARAMETER constants used in the interface.  This
   source file is useful if you have a DLL controller created for a Bladed
   model and you want to use the same controller for your FAST model.  This
   source file is also a useful template if you prefer to control pitch, HSS
   brake torque, generator torque, and yaw with a single master controller,
   regardless of whether or not you use the Bladed code and regardless of
   whether or not you want to work with DLLs.  The executable version of FAST
   that is distributed with the FAST archive is NOT linked with the routines
   contained within this new source file.
 I added files DISCON.f90, DISCON.dll, and DISCON.lib to the FAST archive.
   These are an example source file, DLL, and import library for Bladed-style
   DLL controllers, respectively.
 In SUBROUTINEs PitchCntrl_ACH.f90/PitchCntrl() and AeroCalc.f90/USRMES(), I
   removed all CALLs to EXIT ( 1 ) with CALLs to Abort() in order to prevent
   ungraceful crashes in FAST/Simulink.
 In MATLAB m-file Read_FAST_Input.m, I made one minor change in order to
   accomodate the new input in the Turbine Control Features section of the
   input file (HSSBrMode).
 I added SignalSpecification blocks to the torque and yaw control signal inputs
   in the FAST Wind Turbine Block of the sample Simulink models OpenLoop.mdl
   and Test01_SIG.mdl (this just required these signals to each be of dimension
   2; the pitch controller signal size changes based on the number of blades).
   Prior to this change, Simulink didn't know how to distribute the vectors
   that were muxed together prior to entering the S-function if the torque
   controller and pitch controller input was not constant.  In this new way,
   Simulink distributes the five vector inputs to the mux block correctly.
   This change was requested by Maureen Hand.
 I added compile option /assume:byterecl so that FAST can be used with TurbSim
   wind input files.

v5.10f-jmj, 29-Sep-2004  J. Jonkman
 I linked FAST to the latest version of AeroDyn, 12.57.
 I added test conditions on the value CTWindFlag in SUBROUTINEs
   AeroCalc.f90/Set_FAST_Params() and FAST_IO.f90/Input() so that the FAST
   Aborts if one attempts to use coherent turbulent wind input in a
   linearization analysis or during calculations of noise.  The linearization
   and noise routines do not support coherent turbulent wind.  This change was
   required during the interface with AeroDyn 12.57.
 I split an IF test condition in SUBROUTINE FAST_IO.f90/Input() into two
   conditions so that the program doesn't crash if subscript bounds checking is
   enabled.  Thanks to Marshall Buhl for finding and reporting this bug!
 I added compile option /stand to catch nonstandard errors.
 In the CertTest, I regenerated the FF wind files to use SNWind v1.22 (the
   previously used version was v1.20).
 Also in the CertTest, I updated some SWRT model properties based on model
   tuning work done by Craig Hansen.  Updates were made to the Spd_Trq.dat,
   airfoil tables, and tail-furl spring/damper values.

v5.10, 30-Sep-2004  J. Jonkman
 I rolled up all the alpha changes into this new version.  I eliminated all
   alpha comments.

-------------------------------------------------------------------------------
--------------------------- FAST v6. ------------------------------------------
-------------------------------------------------------------------------------

v6.00a-jmj, 06-Jan-2005  J. Jonkman
 I modified the primary input file, and the logic used to read it in, in order
   to incorporate an improved simple variable-speed control model that will now
   include Region 2 1/2, new nacelle IMU and tower strain gage outputs, and new
   platform motion functionality.  Since the new platform motion functionality
   is a major modification to FAST (in terms of its impact on the equations of
   motion), I decided to roll the digit before the decimal.  The changes to the
   primary input file are as follows:
   RENAMED: RatGenSp to VS_RtGnSp - this is still the rated generator speed for
               simple variable-speed generator control (HSS side) (rpm).
            Reg2TCon to VS_Rgn2K - this is still the generator torque constant
               in Region 2 for simple variable-speed generator control
               (HSS side) (N-m/rpm^2).
   ADDED:   VS_RtTq between VS_RtGnSp and VS_Rgn2K in the TURBINE CONTROL
               section - this is the rated generator torque/constant generator
               torque in Region 3 for simple variable-speed generator control
               (HSS side) (N-m).
            VS_SlPc between VS_Rgn2K and GenModel in the TURBINE CONTROL
               section - this is the rated generator slip percentage in Region
               2 1/2 for simple variable-speed generator control (%)
            A new PLATFORM MODEL section including header plus inputs PtfmModel
               and PtfmFile before the TOWER section.  Input PtfmModel is a
               switch indicating the type of platform as follows {0: none, 1:
               onshore, 2: fixed bottom offshore, 3: floating offshore}.  Input
               PtfmFile contains the name of the input file containing inputs
               pertaining to the platform configuration and DOFs [unused when
               PtfmModel=0].  In FAST v6.00, all nonzero PtfmModel options will
               work the same way by calling PtfmFile.  In future versions, the
               format of PtfmFile will depend on which PtfmModel option is
               selected.
            NcIMUxn, NcIMUyn, and NcIMUzn between SttsTime and ShftGagL in the
               OUTPUT section - these inputs specify the x,y,z location in the
               nacelle coordinate system of the nacelle Inertial Measurement
               Unit (IMU), which is oriented with the shaft coordinate system.
            NTwGages and TwrGagNd between ShftGagL and NBlGages in the OUTPUT
               section - these inputs specify the number and location of the
               tower strain gages like inputs NBlGages and BldGagNd do for
               the blade 1 strain gages.
   In order to obtain equivalent models between FAST v5.10 and FAST v6.00a-jmj
   set the following values for the new and changed inputs:
            VS_RtGnSp = RatGenSp
            VS_RtTq   = Reg2TCon*RatGenSp*RatGenSp
            VS_Rgn2K  = Reg2TCon
            VS_SlPc   = 9999.9E-9 (a very small don't care > 0.0)
            PtfmModel = 0
            PtfmFile  = <may be left blank>
            NcIMUxn   = 0.0 (a don't care)
            NcIMUyn   = 0.0 (a don't care)
            NcIMUzn   = 0.0 (a don't care)
            NTwGages  = 0
            TwrGagNd  = <may be left blank>
 I added code and variables for reading in the new inputs from the platform
   input file, PtfmFile.
 I added code and variables for new outputs related to nacelle IMU motions,
   local tower motions and loads, and platform motions and loads.  This
   required changes to MODULE FAST_Mods.f90/Output() and SUBROUTINE
   FAST_IO.f90/ChckOutLst().  I documented these new outputs in OutList.txt.
 I removed the "Other Names" for the blade 1 local span motions and loads,
   which required a minor change to SUBROUTINE FAST_IO.f90/ChckOutLst().
 I modified the summary (.fsm) file to include additional information, like the
   structural and aerodynamic time steps, turbine mass properties including the
   platform, and platform DOFs.  This required minor changes to SUBROUTINEs
   FAST_IO.f90/PrintSum(), FAST.f90/Coeff(), and FAST_Mods.f90/MassInert().
 I modified the simple variable-speed control model to include Region 2 1/2
   using the new variables above.  I did this in both FAST and the
   FAST-to-ADAMS preprocesssor.  This required changes to SUBROUTINEs
   FAST_IO.f90/Input(), FAST.f90/Initialize() and DrvTrTrq(), and
   FAST2ADAMS.f90/MakeADM().
 I fixed a bug in SUBROUTINE FAST_IO.f90/Input() that caused FAST to Abort()
   prematurely when DYNamic INflow is engaged and CompAero is False when
   linearizing FAST.  Thank you Marshall for finding and reporting this bug.
   This bug fix will not effect any of the results, but will prevent an
   annoyoing nuisance Abort().
 I replaced INTEGER 0s with REAL 0.0s in several IF tests involving conditions
   with REAL numbers.  This bug did not cause any reported problems, but I did
   not want it to in the future.
 I removed the limits of -180deg to 180deg on inputs NacYawF and BlPitchF(:)
   per Marshall's request.  Now there is no restriction on the values of these
   inputs.  This change does not effect any of the results.
 I added logic to test the 0 to 360deg limit to the Azimuth input as described
   in the FAST User's Guide.  I'm not sure why this was absent from the code.
 I added an upper limit of 180deg to input variables TeetDmpP, TeetSStP, and
   TeetHStP for consistency with the furling stop inputs.  This change does not
   effect any of the results.
 I changed all of the lower limit restrictions whose limit was -180.0 from
   inclusive to exclusive since this caused problems in ADAMS when the ATAN2()
   FUNCTION is used to initialize variables.  This change does not effect any
   of the results.
 I reworded several Abort() messages into proper English.  This change does not
   effect any of the results.
 I changed the declaration comment describing internal variable GenTrq (and
   several of its variations) from "Mechanical generator torque" to "Electrical
   generator torque", which is a more accurate description.  This change does
   not effect any of the results.
 In SUBROUTINE FAST.f90/SmllRotTrans(), I flipped the indices so that we are
   specifying rows, not columns, in the definition of the TransMat() matrix
   when ComDenom = 0.0.  This change does not effect any of the results but
   makes the definition of the TransMat() matrix more intuitive.
 I removed the ALIAS attribute from the DLLIMPORT statement in SUBROUTINE
   BladedDLLInterface.f90/BladedDLLInterface() since the ALIAS attribute
   contributes nothing to a DLLIMPORT statement.  This change does not effect
   any of the results.
 I modified CertTest.bat slightly so that it doesn't bomb if MATLAB is not
   installed on the user's computer.  Instead, the batch file proceeds to Test
   15.  This change was requested by Marshall Buhl.
 I modified MATLAB file Read_FAST_Input.m slightly so that variables are
   initialized properly for the FAST S-Function now that there are new inputs
   in the primary input file.
 I added DFORRT.DLL to the FAST archive so that user's without a Fortran
   compiler will not receive runtime errors associated with DFORRT.DLL.

v6.00b-jmj, 18-Mar-2005  J. Jonkman
 I implemented logic for the new nacelle IMU and tower strain gage outputs and
   platform motion functionality into the time-marching and linearization
   analysis capabilities of FAST.  This required extensive changes to the
   inner-workings of FAST--especially the formulation of the equations of
   motion.
 I renamed output channels WindVxt, WindVyt, and WindVzt to WindVxi, WindVyi,
   and WindVzi, respectively since the wind speeds relative to the inertia
   frame (i) are more important than the wind speeds relative to the tower-base
   frame (t), which can now move relative to the inertia frame.  Without
   platform motion, WindVxi, WindVyi, and WindVzi will give the same results as
   WindVxt, WindVyt, and WindVzt use to give.
 I also changed the blade tip accelerations outputs so that they are now in the
   local blade coordinate system instead of the undeflected coordinate system
   (this required that their names change).  I also changed the tower-top / yaw
   bearing angular (rotational) velocity and acceleration outputs so that they
   are now in the tower-top / base-plate coordinate system instead of the tower
   base coordinate system (this also required that their names be changed).
   These changes were made so that the associated outputs are in coordinate
   systems that are easier to measure in the real world.
 I added logic in SUBROUTINE FAST.f90/RtHS() so that the tip brake drag forces
   are not included when CompAero is disabled.
 I modified the summary (.fsm) file to include an indication of how many DOFs
   are active (enabled) in the model.  This required a minor change to
   SUBROUTINE FAST_IO.f90/PrintSum().  While in PrintSum(), I renamed the
   "Flexible Tower Height" output to "Flexible Tower Length" so that the value
   isn't confusing when TwrDraft is nonzero.  I also added a Disabled/Enabled
   indication of the Rotor-teeter DOF in the "Turbine features:" section.
 In source file BladedDLLInterface.f90, I removed routine GetNacAccel() by
   using the new nacelle IMU acceleration outputs instead of trying to compute
   Records 82, 83, and 84 (nacelle roll, nodding, and yaw accelerations) within
   the Bladed DLL interface.  This change will make the values of Records 82
   and 84 slightly different than what they were in FAST v5.10 since they are
   now specified in the shaft (tilted) coordinate system instead of the nacelle
   (nontilted) coordinate system.  I'm not sure which coordinate system Bladed
   actually uses in its interface to DLL controllers, but user's of the Bladed
   DLL interface in FAST and FAST-to-ADAMS should be aware of this slight
   modification. FAST and FAST-to-ADAMS use the shaft coordinate system to
   specify the nacelle accelerations since that is how nacelle IMUs are
   oriented on all commercial wind turbines known by the developers of FAST.
 In source file BladedDLLInterface.f90, I also modified Record 37, the nacelle
   yaw angle from North, to include rotations due to platform yaw and tower
   torsion.  However, this Record is only an estimate of the true nacelle
   orientantation from North and is computed as follows:
   Record 37 = ( YawPzn + YawBrRDzt + PtfmRDzi )*D2R - NacYaw_North.  This
   estimate is not accurate instantaneously in the presence of significant
   tower deflection or platform angular (rotational) displacement since the
   angles used in the computation are not all defined about the same axis of
   rotation.  Again, I'm not sure how Bladed intended this parameter be
   specified in its interface to DLL controllers, but user's of the Bladed DLL
   interface in FAST and FAST-to-ADAMS should be aware of this slight issue.
 I added the type of rotation as a CHARACTER string argument to SUBROUTINE
   FAST.f90/SmllRotTrans().  This required minor changes to SUBROUTINEs
   FAST.f90/SmllRotTrans(), SetCoordSy(), and FAST2ADAMS.f90/MakeADM() and does
   not effect any of the results.  It does however allow FAST to inform the
   user where a large rotation is occuring upon such an event.
 I modified SUBROUTINE FAST.f90/Coeff() so that it computes the twisted shape
   functions, TwistedSF, even if the blade DOFs are disabled during model
   initialization.  I did this since the DOFs can be enabled/disabled at
   runtime from within user-defined routines.
 I removed the simple platform stiffness and damping model from the platform
   input file, PtfmFile, since I realized that even a simple foundation model
   will need added mass terms.  Thus, I decided that for the first release with
   platform capability, I would only have one user-defined routine for all
   platform loading.  This loading must include hydrodynamic and hydrostatic
   terms, mooring line restoring and damping, and/or foundation stiffness,
   damping, and added mass.
 I made FUNCTION FAST.f90/TBFract() an internal procedure to SUBROUTINE RtHS()
   by using the CONTAINS statement.  This change does not effect any of the
   results.
 I removed some unecessary computations in SUBROUTINE FAST_IO.f90/Input(), some
   unneeded variables in MODULE FAST_Mods.f90/TurbConf(), and an unUSEd MODULE
   in SUBROUTINEs FAST.f90/Teeter() and FAST_Lin.f90/CalcSteady().  These
   changes do not effect any of the results.
 I fixed a few spelling errors in SUBROUTINE
   BladedDLLInterface.f90/BladedDLLInterface().  This does not effect any of
   the results.
 I modified MATLAB file Read_FAST_Input.m slightly so that the platform DOFs
   are initialized for the FAST S-Function.
 I modified the CertTest to use TurbSim v1.00e instead of SNwind.  The *.ddd
   wind files are no longer distributed in the archive since they are not
   generated by TurbSim like they were by SNwind.

v6.00c-jmj, 15-Apr-2005  J. Jonkman
 I fixed a bug in the calculation of the local tower strain gage moment
   outputs.  There was a mixup in the use of units (N and N-m versus kN and
   kN-m).  This bug was created in FAST v6.00b-jmj, when adding the local tower
   strain gage outputs to FAST.  This bug fix only changes the results for the
   local tower strain gage moment outputs (all other outputs will remain the
   same).
 I added output channels TipRDxbK and TipRDybK, which are the angular
   (rotational) roll and pitch deflections of the tip of blade K, respectively
   (where K = 1,2,3--the blade number) (relative to the undeflected position).
   I gave them additional names of RollDeflK and PtchDeflK, respectively.  I
   also added an additional output name of TwstDeflK for channel TipRDzbK.
   This required changes to MODULE FAST_Mods.f90/Output() and RtHndSid() and
   SUBROUTINEs FAST_IO.f90/ChckOutLst() and FAST.f90/Alloc(), CalcOuts(), and
   RtHS().
 I also added an additional output name for channels YawBrRDxt, YawBrRDyt, and
   YawBrRDzt as follows: TTDspRoll, TTDspPtch, and TTDspTwst, respectively.
   This required a minor change to SUBROUTINE() FAST_IO.f90/ChckOutLst().  The
   previous output channel names still work.
 I implemented logic for the new nacelle IMU and tower strain gage outputs and
   platform motion functionality into the FAST-to-ADAMS preprocessor.  This
   required several changes to the inner-workings of the FAST-to-ADAMS
   preprocessor.
 In the FAST-to-ADAMS preprocessor [routine FAST2ADAMS.f90/MakeADM()], I
   renumbered GRAPHICS/1200, the rigid-tower-base GRAPHICS, to GRAPHICS/1400 in
   accordance with what is specified in the FAST2ADAMSStatements.xls
   spreadsheet.  This change does not effect any of the ADAMS simulation
   results.
 I changed the upper and lower limits of input parameters PtfmRoll, PtfmPitch,
   and PtfmYaw to -15 to 15 degrees so that a small angle warning isn't
   triggered by excessively large initial condition input settings.  I also
   changed the upper and lower limits of input parameter ShftSkew to -15 to 15
   degrees for consistency.  This required minor changes to SUBROUTINEs
   FAST_IO.f90/GetPtfm() and GetFurl().
 I undid the change made to FAST v6.00a-jmj that removed the ALIAS attribute
   from the DLLIMPORT statement in SUBROUTINE
   BladedDLLInterface.f90/BladedDLLInterface() because it caused a problem in
   ADAMS.  This does not effect any of the results.
 In OutList.txt, I modified the description of the rotational deflection
   outputs at the blade tip (TipRDxbK, TipRDybK, and TipRDzcK where K =
   1,2,3--the blade number) and tower-top (YawBrRDxt, YawBrRDyt, and YawBrRDzt)
   and rotational displacement outputs of the platform (PtfmRDxi, PtfmRDyi, and
   PtfmRDzi) in accordance with the minor changes made to A2AD v12.18c-jmj.
 In the CertTest, I modified the "Length of analysis time series" input in the
   TurbSim imput files to equal 600.0 seconds and regenerated the wind files
   for all cases.  This change was recommended by Bonnie Jonkman in order to
   bring about more frequencies and more realistic winds in the wind files
   without increasing the size of the .wnd files 

v6.00, 10-Jun-2005  J. Jonkman
 I rolled up all the alpha changes into this new version.  I eliminated all
   alpha comments.
 In FAST_IO.f90/GetFurl(), I modified the Abort() error message for
   incorrectly-defined inputs RFrlUSSP, RFrlUSDP, TFrlUSSP, and TFrlUSDP.  This
   change does not effect any of the simulation results.
 I added an example platform input file, Platform.dat, to the CertTest folder
   of the FAST archive for user's to use.  The certification test will be
   updated to include testing of new platform motion and loading functionality
   once FAST has been interfaced to SML.
 I removed the CreatePageAlpha.pl, update_webAlpha.bat, and update_page.bat
   scripts from the "all" archive since the Alpha webpage has been removed from
   the server.

v6.01a-jmj, 29-Jul-2005  J. Jonkman
 In source file BladedDLLInterface.f90, I modified the interface to the Bladed-
   style master controller DLLs so that we don't have to link with the .lib
   file when compiling.  This allowed me to remove the /libs:dll Project
   compile Option.  It also allowed me to remove the DISCON.dll and DISCON.lib
   files from the FAST archive.  The DFORRT.dll is no longer needed when a DLL
   is not being called from FAST--since it is needed when calling a DLL I have
   left the DFORRT.dll in the FAST archive.  Thank you to Anders Hansen of
   Risoe for advice on how to make this change.
 I added the DOF index variables, as described in the FAST linearization output
   files, to MATLAB file Read_FAST_Input.m so that they are available within
   the MATLAB workspace and FAST S-Function and can be used in place of the
   index numbers when performing control studies requiring full-state feedback.
   This change was requested by Alan Wright and Karl Stol and does not effect
   any of the results.
 I added additional output names of BlPitch1, BlPitch2, BlPitch3, YawPos,
   YawRate, YawAccel, and YawMom to their corresponding output channels.  This
   required a minor change to SUBROUTINEs FAST_IO.f90/ChckOutLst().  I reworded
   the description of the yaw actuator in SUBROUTINE UserSubs.f90/UserYawCont()
   as a result of this change.  This change does not effect any of the results.
 I added INTEGER(4), PARAMETER :: Time = 0 to MODULE FAST_Mods.f90/Output() so
   that one can access the Time output channel from the AllOuts() array.  This
   required that I add the , ONLY: attribute to two USE statements in order to
   avoid variable naming conflicts--one in SUBROUTINE FAST_Lin.f90/Linearize()
   and the other in SUBROUTINE NoiseSubs.f90/CalcFFTI().  I made use of the new
   Time PARAMETER in place of 0 in SUBROUTINE FAST.f90/CalcOuts() and in place
   of ZTime in SUBROUTINE FAST_IO.f90/WrOutput() and throughout source file
   BladedDLLInterface.f90.  This change does not effect any of the results.
 In SUBROUTINE BladedDLLInterface.f90/UserYawCont(), I initialized the value of
   LastTime to the time of the previous time step instead of to zero in order
   to avoid a "kick" in YawPosCom when TYCOn is nonzero.
 In SUBROUTINE FAST_IO.f90/GetPrimary(), I reworded the warning message
   displayed when the 2nd blade flap mode is enabled without the 1st and I also
   added warning messages for when the 2nd tower fore-aft and side-to-side
   modes are enabled without the 1st.  I am not sure why these warning messages
   were absent from the code.  This change does not effect any of the results.
 In order to account for the generator effeciency specification of 95%, I
   increased the simple variable-speed control torque constants of the WindPACT
   1.5MW baseline wind turbine model in the CertTest (Test11.fst, Test12.fst,
   Test13.fst, and Test14.fst) by 1/0.95.  Before this change, the peak power
   was topping out at (1500kw)*(0.95) = 1425kw insted of 1500kw.  After this
   change, the peak power is correct.  I'm not sure why the torque constants
   were specified incorrectly before.
 In the CertTest, I also modified the OutList of several of the test cases in
   order to test output channels not previously tested.

v6.01, 12-Aug-2005  J. Jonkman
 I added a MIN( 1.0, * ) to the calculation of output parameter CThrstRad in
   SUBROUTINE FAST.f90/CalcOuts() in order to limit the value betweeen 0.0 and
   1.0 (inclusive).  This change does not effect any of the results other than
   the value of CThrstRad.
 I rolled up all the alpha changes into this new version.  I eliminated all
   alpha comments.