🎉 Feature request

Is your feature request related to a problem? Please describe.

The program Mvfsacrsnh.c has its own repository and it should be deleted from this repository.

Describe the solution you'd like

Include the reference to the vfsa repository and explain it is a dependency of the this package in the README.

🎉 Feature request

Is your feature request related to a problem? Please describe.

The CRE Gather Stack process is done in a loop for each experiment and could be generalized in a function inside a Madagascar Recipe.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

🐛 Bug report

Describe the bug

Runing the multi Layer experiment from commit 28de03d, I received a No such file or directory error in the pipe from sfgetcregather to sfput in the Flow above:

To Reproduce
Steps to reproduce the behavior:

1. Run the SConstruct of the experiment with 'scons' command
2. The central CMP m0 should be 3.5Km (it's when the error occurs).
   

   creGatherStack/experiments/multiLayerModel/cre/SConstruct

   Line 35 in 28de03d

   om0 = 2+1.5

3. See error

< interpolatedDataCube2.rsf /root/madagascar/bin/sfgetcregather verb=y cremh=creMhCoordinates-m0-0-t0-0.rsf m=creMcoordinate-m0-0-t0-0.rsf | /root/madagascar/bin/sfput label1="Time" unit1="s" label2="Offset" unit2="km" > creGather-m0-0-t0-0.rsf
sfgetcregather: Active mode on!!!
sfgetcregather: CRE gather coordinates m(h) (cremh file): 
sfgetcregather: n1=161 d1=0.012500 o1=0.000000
sfgetcregather: Input file dimensions: 
sfgetcregather: n1=1001 d1=0.004000 o1=0.000000
sfgetcregather: n2=161 d2=0.012500 o2=0.000000
sfgetcregather: n3=804 d3=0.006250 o3=0.000000
sfput: build/api/c/file.c: No in= in file in: No such file or directory
scons: *** [creGather-m0-0-t0-0.rsf] Error 1

Desktop (please complete the following information):

• OS: Linux CentOS
• Version 7.8 kvm

Additional context

The bug is probably because the CMP coordinate is increasing fast in relation to the offset increasing and the program sfgetcregather is looking for traces with a CMP coordinate outside of the model.

See the model dimensions above:

~$ echo "161*0.0125" | bc -l # Maximum Offset
2.0125
~$ echo "804*0.00625" | bc -l # Maximum CMP
5.02500

See the sfdisfil of the vector of CMP coordinates of the CRE trajectory. The last ones are clearly outside of the model (>5.025):

sfdisfil < creMhCoordinates-m0-0-t0-0.rsf 
   0:           3.5          3.5        3.501        3.502        3.503
   5:         3.504        3.506        3.508        3.511        3.514
  10:         3.517         3.52        3.524        3.528        3.533
  15:         3.537        3.542        3.547        3.553        3.559
  20:         3.565        3.571        3.577        3.584         3.59
  25:         3.597        3.605        3.612         3.62        3.627
  30:         3.635        3.643        3.652         3.66        3.668
  35:         3.677        3.686        3.695        3.704        3.713
  40:         3.722        3.731        3.741         3.75         3.76
  45:          3.77        3.779        3.789        3.799        3.809
  50:         3.819        3.829         3.84         3.85         3.86
  55:         3.871        3.881        3.892        3.902        3.913
  60:         3.924        3.934        3.945        3.956        3.967
  65:         3.978        3.989            4        4.011        4.022
  70:         4.033        4.044        4.055        4.066        4.077
  75:         4.089          4.1        4.111        4.123        4.134
  80:         4.145        4.157        4.168         4.18        4.191
  85:         4.203        4.214        4.226        4.237        4.249
  90:          4.26        4.272        4.284        4.295        4.307
  95:         4.318         4.33        4.342        4.354        4.365
 100:         4.377        4.389        4.401        4.412        4.424
 105:         4.436        4.448         4.46        4.472        4.483
 110:         4.495        4.507        4.519        4.531        4.543
 115:         4.555        4.567        4.579        4.591        4.603
 120:         4.614        4.626        4.638         4.65        4.662
 125:         4.674        4.686        4.698         4.71        4.723
 130:         4.735        4.747        4.759        4.771        4.783
 135:         4.795        4.807        4.819        4.831        4.843
 140:         4.855        4.867        4.879        4.892        4.904
 145:         4.916        4.928         4.94        4.952        4.964
 150:         4.977        4.989        5.001        5.013        5.025
 155:         5.037         5.05        5.062        5.074        5.086
 160:         5.098

Documentation request

Describe your documentation request clearly bellow

Write a documentation of the vfsa experiment with jupyter notebook and reproducible paper files.

Program version

Version 1.0 - beta

What kind of documentation you are requesting?

• README files.
• Wiki pages.
• Jupyter notebooks.
• Other: Reproducible paper.

🎉 Feature request

Is your feature request related to a problem? Please describe.

A new version of the vfsa program is being built 1.1.2 and it is incompatible with the current creGatherStack package version (3.0). So, a new version of this package should be done.

Describe the solution you'd like

In this new version of the vfsa the parameter optimization is done for all (t0,m0) pairs in a range. Instead of each pair at time. The output generated is a parameters cube with RN, RNIP and BETA. This new output is not compatible with the current creGatherStack input.

Describe alternatives you've considered

All the programs in this package should be changed for this new type of input (Parameters cube).

Additional context
Add any other context or screenshots about the feature request here.

🐛 Bug report

Describe the bug

Definition in aperture parameter of sfgetcregather is causing a building error in sfcrestack.

To Reproduce
Steps to reproduce the behavior:

1. Run SConstruct fullInterpolationAndStack experiment (In this experiment aperture parameter is not defined to sfgetcregather, but default of the program is 1. Though, in the sfcrestack, the aperture parameter is defined as 10).
2. See error

< creGatherTrace-m0-0.rsf /root/madagascar/bin/sfcrestack timeCurves=creTimeCurveTrace-m0-0.rsf verb=y aperture=10 | /root/madagascar/bin/sfput label1=t0 unit1=s label2=m0 unit2=Km --out=stdout > creStackedTrace-m0-0.rsf
sfcrestack: The aperture can't be > n2
Aperture=10 n2=1
sfput: build/api/c/file.c: No in= in file in: No such file or directory
scons: *** [creStackedTrace-m0-0.rsf] Error 1
scons: building terminated because of errors.

Expected behavior

Definition of the same aperture parameter value in both programs should correct the bug.

Screenshots

Desktop (please complete the following information):

• OS: CentOS
• Version [e.g. 22]

Additional context

When the same experiment is tested with aperture parameter defined as 10 for both programs the bug disapears.

sfcrestack: Active mode on!!!
sfcrestack: Input file parameters: 
sfcrestack: n1=1001 d1=0.004000 o1=0.000000
sfcrestack: n2=10 d2=0.012500 o2=0.000000
sfcrestack: n3=3 d3=0.004000 o3=1.000000
sfcrestack: n4=1 d4=0.500000 o4=3.500000
sfcrestack: Time curves file parameters: 
sfcrestack: n1=161 d1=0.012500 o1=0.000000
sfcrestack: n2=3 d2=0.004000 o2=1.000000
sfcrestack: n3=1 d3=0.500000 o3=3.500000
< creStackedTrace-m0-0.rsf /root/madagascar/bin/sfrcat axis=2 --out=stdout > stackedSection.rsf
< stackedSection.rsf /root/madagascar/bin/sfbandpass fhi=20 --out=stdout > filtStackedSection.rsf
scons: done building targets.

🎉 Feature request

Is your feature request related to a problem? Please describe.

Move pefInterpolation usage example to Madagascar package.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

🎉 Feature request

Is your feature request related to a problem? Please describe.

The amplitudes of the far offsets in the CRE stacked section in weaker than the closest ones

Describe the solution you'd like

Use a gain filter to improve amplitude in far offsets

Describe alternatives you've considered

None.

Additional context

It would improve the amplitude summation of the CMPs at the boundaries of the stacked section

🎉 Feature request

Is your feature request related to a problem? Please describe.
Repeat the test of the algorithm of CREGatherStack package. This time, applied to a multi layer model. Use CRE traveltime approximation and non-hyperbolic CRS (with CDS condition applied) as a stacking curve, compare both approximations.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

🎉 Feature request

Is your feature request related to a problem? Please describe.

The search of the optimal CRE trajectory could improve with another algorithm using semblance and local optimization.

Describe the solution you'd like
.
To get optimal CRE trajectory and gather changing the RNIP and BETA parameters and calculating the semblance.

Describe alternatives you've considered

Use the same algorithm available in the paper nonhyperbolic common reflection surface to get the minimum error (maximum semblance) of the difference between the traveltime approximation curve and the CRE gather varying RNIP and BETA.

Additional context

Use the CRE traveltime equation and calculate the derivatives of the traveltime curve in relation to the CRS parameters RNIP and BETA. The equation is in the image above:

Documentation request

Describe your documentation request clearly bellow

Some of the usage examples are no longer required, and can be substituted for two more general ones. For instance, one example of CRE stacking using CRE traveltime equation as stacking curve and another one using non-hyperbolic CRS traveltime equation (using CDS condition) as stacking curve.

CDS condition is when we use RN=RNIP

Program version

What kind of documentation you are requesting?

• README files.
• Wiki pages.
• Jupyter notebooks.
• Other (Delete useless examples)

The numerical experiments in the experiments folder should be rebuild in order to check if they are working correctly. This will allow you to rebuild the inversion step with landa88plane (next step)

Documentation request

Describe your documentation request clearly bellow

Write a documentation of the interpolation experiment with jupyter notebook and reproducible paper files.

Program version

Version 1.0 - beta

What kind of documentation you are requesting?

• README files.
• Wiki pages.
• Jupyter notebooks.
• Other: Reproducible paper.

🎉 Feature request

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

🎉 Feature request

Is your feature request related to a problem? Please describe.

No.

Describe the solution you'd like

I wish select the traveltime approximation (CRE or CRS) in the program Mgetcretimecurve.c with a flag option.

Describe alternatives you've considered

Just use a boolean flag option, it'll look like that:

if(! sf_getbool("cds",&cds)) cds=0;
/* 1: use CRS with CDS condition; 0: use CRE */

Additional context

The CRS traveltime approximation with the CDS condition can be used in place of CRE traveltime approximation to produce the stacked section with stacking of the amplitudes over CRE gathers.

One option could be used to give the user the opportunity to test both of this approximations to stacking process.

🎉 Feature request

Is your feature request related to a problem? Please describe.

The CRE Gather sections generated with the CRE traveltime curve approximation have to much numerical error, and I suspect is because of the numerical precision of the CRS parameters determination or in the determination of the CRE gather traces after the PEF interpolation.

Describe the solution you'd like

• Do the interpolation process twice, in order to improve the CMP sampling in the seismic data cube, to get the CRE gather traces precisely.

• Use variables of type double instead of float.

• Use a local optimization method to improve vfsa as referenced in the issue #8.

Describe alternatives you've considered

I've considered to use the CDS traveltime approximation. Though, I have to explain why does it work as a substitution of the CRE gather traveltime equation.

Additional context

CDS traveltime approximation is when you use the CDS condition (RN=RNIP) in the a CRS traveltime approximation, and it's usually used as a diffraction traveltime approximation. I will have to explain why this diffraction approximation can be used (and it is better) to stack reflection data.

🎉 Feature request

Is your feature request related to a problem? Please describe.

Use only one SConstruct script to build the cre stacked section from stacked traces.

Describe the solution you'd like

Use the script in the generateStackedSection directory to build the crestacked section after geting the cre stacked traces using the stack4 script

Substitute the CDS condition in the hyperbolic CRS traveltime approximation (RN = RNIP) and test if the convergency region improves. Use the equation above:

🎉 Feature request

Is your feature request related to a problem? Please describe.

The name of the package creGatherInterpolation does not focus on the purpose of the package which is to obtain the CRE stacked section. The interpolation with PEF is just a necessary step to get this result.

Describe the solution you'd like

Change the name to creGatherStack.

🎉 Feature request

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

🐛 Bug report

Describe the bug

Function 'calculateVrmsSectionFromRnipValues' is calculating wrong values of t0, and consequently is returning wrong values of vrms. Using a sf_warning function to output values used in the function, it prints as follows:

sfrnip2vrms: rnip=1.953233 vrms=0.004921 t0=242001.000000 nt0=500 i=484 ot0=-1830575641
sfrnip2vrms: rnip=1.604086 vrms=0.004455 t0=242501.000000 nt0=500 i=485 ot0=-1830575641
sfrnip2vrms: rnip=1.540000 vrms=0.004360 t0=243001.000000 nt0=500 i=486 ot0=-1830575641
sfrnip2vrms: rnip=1.495000 vrms=0.004292 t0=243501.000000 nt0=500 i=487 ot0=-1830575641
sfrnip2vrms: rnip=1.670536 vrms=0.004532 t0=244001.000000 nt0=500 i=488 ot0=-1830575641
sfrnip2vrms: rnip=2.365328 vrms=0.005387 t0=244501.000000 nt0=500 i=489 ot0=-1830575641
sfrnip2vrms: rnip=2.036424 vrms=0.004994 t0=245001.000000 nt0=500 i=490 ot0=-1830575641
sfrnip2vrms: rnip=2.735940 vrms=0.005782 t0=245501.000000 nt0=500 i=491 ot0=-1830575641
sfrnip2vrms: rnip=1.900000 vrms=0.004814 t0=246001.000000 nt0=500 i=492 ot0=-1830575641
sfrnip2vrms: rnip=2.200000 vrms=0.005174 t0=246501.000000 nt0=500 i=493 ot0=-1830575641
sfrnip2vrms: rnip=1.870098 vrms=0.004766 t0=247001.000000 nt0=500 i=494 ot0=-1830575641
sfrnip2vrms: rnip=1.890786 vrms=0.004787 t0=247501.000000 nt0=500 i=495 ot0=-1830575641
sfrnip2vrms: rnip=2.266718 vrms=0.005236 t0=248001.000000 nt0=500 i=496 ot0=-1830575641
sfrnip2vrms: rnip=3.165000 vrms=0.006181 t0=248501.000000 nt0=500 i=497 ot0=-1830575641
sfrnip2vrms: rnip=1.936337 vrms=0.004830 t0=249001.000000 nt0=500 i=498 ot0=-1830575641
sfrnip2vrms: rnip=1.613755 vrms=0.004405 t0=249501.000000 nt0=500 i=499 ot0=-1830575641

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Ubuntu
• Version 20.04

Additional context

🎉 Feature request

Is your feature request related to a problem? Please describe.

The official repository of the Madagascar package has kimodel.py and pefInterpolation.py recipes already. So, the creGatherStack package does not need to use creStack.py python script in order to define modeling and interpolation functions.

Describe the solution you'd like

Update creGatherStack experiments to use those recipes directly from Madagascar local version.

Additional context

The_common_reflecting_element_CRE_method_revisited_cruz2000.pdf

🐛 Bug report

Describe the bug

Occurs a segmentation fault when Mcrestack.c receives an input data with a number of offsets that is minor than defined in the STACK_APERTURE variable. It follows the header of the Mcrestack.c source code:

#include <rsf.h>

#define STACK_APERTURE 100

To Reproduce

Steps to reproduce the behavior:

1. Use a data cube with a number of offsets minor then 100, like that one:

~$ sfin interpolatedDataCube2.rsf 
interpolatedDataCube2.rsf:
    in="/var/tmp/creGatherInterpolation/experiments/fullInterpolationAndStack/interpolatedDataCube2.rsf@"
    esize=4 type=float form=native 
    n1=1001        d1=0.004       o1=0          label1="Time" unit1="s" 
    n2=1           d2=0.0125      o2=0          label2="Offset" unit2="Km" 
    n3=1604        d3=0.00625     o3=0          label3="CMP" unit3="Km" 
	1605604 elements 6422416 bytes

2. Try to stack with Mcrestack.c

3. See error. It will output:

sfcrestack: Active mode on!!!
sfcrestack: Input file parameters: 
sfcrestack: n1=1001 d1=0.004000 o1=0.000000
sfcrestack: n2=1 d2=0.012500 o2=0.000000
sfcrestack: n3=1 d3=0.004000 o3=1.000000
sfcrestack: n4=1 d4=0.006250 o4=3.000000
sfcrestack: Time curves file parameters: 
sfcrestack: n1=1 d1=0.012500 o1=0.000000
sfcrestack: n2=1 d2=0.004000 o2=1.000000
sfcrestack: n3=1 d3=0.006250 o3=3.000000
Segmentation fault (core dumped)
sfput: build/api/c/file.c: No in= in file in: No such file or directory
scons: *** [creStackedTrace-m0-0.rsf] Error 1
scons: building terminated because of errors.

Expected behavior

Another way to delimit the stack aperture and guarantee that is not major than the number of offsets in the input data.

Desktop (please complete the following information):

• OS: Linux Ubuntu
• Version 18.04.4

🎉 Feature request

Is your feature request related to a problem? Please describe.

The Makefile help in this directory

--- Automate experiments building ---
Use 'make' to build all experiments listed in BUILD variable
BUILD = model1
Or make your own build list with 'make BUILD=model1 model2 ...'

--- Traveltime picking ---
After building the experiment you can run traveltime picking and parameters search
Use 'make pick exp=model1 nitf=2'
Use whatever experiment you want to use in exp variable
And configure the number of model interfaces in 'nitf' variable

When I run (make pick exp=model1 nitf=2), it shows the following error:

scons -C picking -c && sfrm picking/*.rsf
scons: Entering directory `/home/rodolfo/madagascar-3.0/user/creGatherStack/experiments/constLayersModels/picking'
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Cleaning targets ...
scons: done cleaning targets.
sfrm: build/api/c/files.c: Cannot open file picking/*.rsf: No such file or directory
make: *** [Makefile:23: pick] Error 1

But the functionality traveltime picking is not working

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

🎉 Feature request

Is your feature request related to a problem? Please describe.

Program sfrnip2vrms receives the stacked section and rnip file as input. But, rnip values are defined to each (m0,t0) pairs in the stacked section, so, rnip file can be organized in the same dimensions such as the stacked section.

The program only needs the stacked section to load its geometry. If it was the same geometry as rnip file, it would be not necessary to receive the stacked section as input, only the rnip file would be needed.

Describe the solution you'd like

Establish rnip file as default input in stdin.

Describe alternatives you've considered

Additional context

🎉 Feature request

Is your feature request related to a problem? Please describe.

Test the SConstruct to stacking process using the CRE traveltime approximation as stacking curve and using non-hyperbolic CRS traveltime approximation as stacking curve in another turn.

Describe the solution you'd like

Comparison between the two ways of stacking using one or another approximation.

Describe alternatives you've considered

Use few m0's to test the script for the first time (dm0=0.5Km). When it is debugged, fell free to full stacking the section.

Additional context

• CRE stacking
• CDS stacking

🐛 Bug report

Describe the bug

A segmentation faut ocurred when I try to use sfvfsa in the multi Layer experiment. In the Flow above:

To Reproduce
Steps to reproduce the behavior:

1. Run the multi layer experiment with 'scons'
2. See error when m0=4Km.

< multiLayerDataCube.rsf /root/madagascar/bin/sfvfsacrsnh m0=4 v0=1.5 t0=1 verb=y repeat=3 > crsParameters-m0-4-t0-0.rsf
sfvfsacrsnh: Active mode on!!!
sfvfsacrsnh: Command line parameters: 
sfvfsacrsnh: m0=4.000000 v0=1.500000 t0=1.000000 c0=0.500000 temp0=10.000000 repeat=3
sfvfsacrsnh: Input file parameters: 
sfvfsacrsnh: n1=1001 d1=0.004000 o1=0.000000
sfvfsacrsnh: n2=161 d2=0.012500 o2=0.000000
sfvfsacrsnh: n3=201 d3=0.025000 o3=0.000000
sh: line 1: 13576 Segmentation fault      (core dumped) /root/madagascar/bin/sfvfsacrsnh m0=4 v0=1.5 t0=1 verb=y repeat=3 < "multiLayerDataCube.rsf" > "crsParameters-m0-4-t0-0.rsf"
scons: *** [crsParameters-m0-4-t0-0.rsf] Error 139

Desktop (please complete the following information):

• OS: Linux CentOS
• Version 7.8kvm

Additional context

This problem probably occurs because standard aperture used in Mvfsacrsnh.c to define a square of the approximated surface where to calculate the semblance is 50 samples in CMP and Offset coordinates.

To check that, I run sfin program:

sfin multiLayerDataCube.rsf 
multiLayerDataCube.rsf:
    in="/root/rsfdata/experiments/multiLayerModel/cre/multiLayerDataCube.rsf@"
    esize=4 type=float form=native 
    n1=1001        d1=0.004       o1=0          label1="Time" unit1="s" 
    n2=161         d2=0.0125      o2=0          label2="Offset" unit2="Km" 
    n3=201         d3=0.025       o3=0          label3="CMP" unit3="Km" 
	32393361 elements 129573444 bytes

The data cube CMP axis dimension is:

~$ echo "201*0.025" | bc -l
5.025

If someone try to sum up vfsa standard aperture to 4Km (m0 position):

 ~$ echo "4+50*0.025" | bc -l
5.250

🎉 Feature request

Is your feature request related to a problem? Please describe.

While doing a parallel building in scons, one thread can start to build some target that the dependency is not built yet because it's being built for another thread. For instance, in the creGatherStack process, the stacked section (stored in stackedSection file) depends of all CRE stacked traces (stored in creStackedTraces files) generated in the m0, t0 loop. If the building process is parallelized with scons, one thread will start the building of the stacked section without some CRE stacked traces and it will cause a building error.

# Very Fast Simulated Annealing loop to get 
# zero offset CRS parameters (RN, RNIP, and BETA) from the data cube

for i in range(nm0):
	for j in range(nt0):
        [...]
	# CRE stacking
	Flow(creStackedTrace,[creGatherTrace,creTimeCurveTrace],
		'''
		crestack timeCurves=${SOURCES[1]} verb=y aperture=10 |
		put label1=t0 unit1=s label2=m0 unit2=Km --out=stdout
		''')

# Build the cre stacked section
[...]
Flow('stackedSection',sortedFiles,
	'''
	rcat axis=2 ${SOURCES[1:%d]} --out=stdout
	''' % len(files))

Describe the solution you'd like

The solution would be to use explicitly dependency declaration to scons with Depends method.

Describe alternatives you've considered

The code above tells scons that interpolatedDataCube.rsf explicitly depends of dataCube.rsf. So, all the threads have to finish dataCube.rsf building to start interpolatedDataCube.rsf building.

Depends('interpolatedDataCube.rsf','dataCube.rsf')

Additional context