#!/bin/sh
# Sunmocsv_realistic2q - for program SUNMOCSV
# Author: Andre Latour, Jan 2022
#
  echo "----------------------------------------------------------------------------"
  echo "---  This is a realistic test. It takes traces that were created with       "
  echo "---  an exactly known amount of NMO and corrects them using SUNMOCSV.       "
  echo "---  The input velocity functions are deliberately over-corrected in        "
  echo "---  some parts of the 3d and deliberately under-corrected in other parts.  "
  echo "---  The resulting stack is displayed.                                      "
  echo "---  This is similar to Sunmocsv_realistic2 except that the input velocity  "
  echo "---  functions are in the qin file ALONG with other unrelated values.       "
  echo "----------------------------------------------------------------------------"
#
# The traces are known to have the following velocity since it was applied using the
# inverse option in sunmo, as follows: 
# sunmo <fakexsrf.su >fakexsrfn.su invert=1 tnmo=0,190,450,800 vnmo=1800,3500,4000,5000
#
  sunmocsv <fake7.su >fake41.su rfile=kEFG.csv check=1 print=1 qin=qx2.csv 2>tinfo4.txt \
#
  sustack <fake41.su >fake42.su key=cdp 
#
  suxwigb <fake42.su key=cdp &
#
# The next 2 programs subtract the results of the command line input test Sunmocsv_realistic2 
# and this test of qin file input (which has the same velocity function values).
# The result should be all zeroes of course.                                      
#
  suop2 fake32.su fake42.su op=diff >fake43.su
#
  sumax <fake43.su
#
# The suop2 and sumax concept above can be used as a (limited) unit test. 
# Before adding some option in the code, run all tests and preserve the outputs.
# Then make your code changes, and rerun all tests. Then use suop2,sumax
# to compare the old/new output files. The result should be 0,0 unless 
# you intended otherwise.  
#   However, do not presume this would be useful in general.
#   That is, if you uploaded the output files into GITHUB (or whatever) then,
#   later, you could run suop2,sumax tests comparing the old GITHUB files     
#   to files newly generated by these tests. 
#        You could then automate this into unit-tests.                                                     
#   But that is not likely to be a generally useful thing for Seismic Unix.
#   The trouble comes down to the fact the seismic data is floating point.
#   As hardware/compiler/optimizers develop, floating point results always 
#   change slightly, especially for seismic sample values themselves, but 
#   also for some header values (for instance: statics). For any change
#   of hardware/compiler/optimizer the difference after sumax is not 0.
#   Having worked a long time for a major corporation that developed an 
#   industry-leading seismic processing system, checking these kinds of
#   unit-tests requires large effort, manpower, and organizational structure
#   that Seismic Unix will never have available.
#
