#!/bin/sh
# Sumutecsv_test2 - for program SUMUTECSV
# Author: Andre Latour, Oct 2021
#
  echo "----------------------------------------------------------------------------"
  echo "---  This test is the same as test4 except it inputs the same mute values   "
  echo "---  via a q-file. It also subtracts the results of test4 from the results  "
  echo "---  produced herein. The sumax results at end should be 0.0,0.0            "
  echo "----------------------------------------------------------------------------"

#
# I know the 3d grid is 121 by 23 cells. Make 2783 traces.
# Make 1 trace per cdp with offset of 500. 
#
  sunull nt=1500 ntr=2783 dt=0.004 >tnullq4.su
  sumath <tnullq4.su op=add a=100 >tnullq4a.su
  sushw <tnullq4a.su >tnullq4acdp.su key=cdp a=1 b=1
  sushw <tnullq4acdp.su >tnullq4acdpoff.su key=offset a=500 b=0
#
# sugethw <tnullbcdpoff.su key=tracl,cdp,offset >afile
#
# Similar to test1, if you set extrapi=1 amd extrapc=1 the mute function values
# will produce a mute time of cdp*10 ms.                             
#
  sumutecsv <tnullq4acdpoff.su >tnullq4acdpoffmute.su rfile=kEFG.csv mode=1 extrapi=0 extrapc=0 \
        qin=t4q.csv \
#
  suxwigb <tnullq4acdpoffmute.su key=cdp xcur=0.5 
#
# 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 tnull4acdpoffmute.su tnullq4acdpoffmute.su op=diff >tnullq4fake.su
#
  sumax <tnullq4fake.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.
