crava / crava Goto Github PK

Variogram azimuth and range CRA-795

The interval input files: Top and Base (time) surfaces should be able to read text/ASCII/DAT.files:
Ex:
zone1: Top_Horizon.txt / or / Top_Horizon.dat
zone2: BCU.txt
zone3: Base_Horizon.txt

Per today they are only able to read STORM.files and constant values.

Wavelet estimate scale by default CRA-788
Wavelet in the logfile, gain should have a more intuitive name, e.g., scale CRA-792
Wavelet Present the scaling in a more comprehensive way CRA-792

Hi,
I have two Crava projects. One is running smoothly and the second one fails reading the log data (Capture.png)
Attached are the input files. Harpoon failed and Bay did load fine.
I do not see any difference between the files. Do you have any advice on what went wrong?

Harpoon_O-85_aug16.txt
Bay_Du_Nord_C-78.txt

Horizon-tab:

• If "Number of Layers" are not set in first run (run 1), Crava makes its own number (302), dependent of the Correlation direction ==> OK! BUT: When rerunning the Crava (run 2) with the same "number of layers" (302) as Crava gave in the first run (run 1), the "number of layers" are being resampled ( to 318) due to correlation direction....but the surface direction has not been changed in run 2 compared to run 1. Shouldn't the "number of layers" then be kept the same in run 2 as it was "defaulted by Crava" in run 1? Ex:

***** Setting up multiple interval grid ***** (taken from logfile)

RUN 1: Creating extended simbox with one correlation surface for interval 'zone 1'.
Z padding sizes estimated from an assumed wavelet length for interval 'zone 1':
zPad, zPadFac, nz, nzPad : 200ms, 0.192, 302, 360

Run 2:Creating extended simbox with one correlation surface for interval 'zone 1'.
Number of layers in interval zone 1 increased from 302 to 318 because of the correlation direction.
Z padding sizes estimated from an assumed wavelet length for interval 'zone 1':
zPad, zPadFac, nz, nzPad : 200ms, 0.179, 318, 375

Proper handling of input and output temporal correlation when number of layers increases due to separate correlation direction CRA-796

I have observed in some cases the CRAVA estimated too long wavelet than what we expected. The default wavelet length in CRAVA is 200ms. And the CRAVA estimated wavelet should usually be close to 200ms. But there are some cases CRAVA estimate wavelets which are as long as 2000ms. It will easily end to an abortion because there are usually no wells have such long continuous logs.

Surfaces that are eroded, or for other reasons do not cover the whole inversion area needs to be extrapolated. Having crava do this in an automatically would be very convenient. For this to be practical, we need

• Appropriate warning messages
• A clear understanding of minimum requirements for the surface before extrapolation can take place
• A good choice of extrapolation method

Hi CRAVA developers!

I am currently testing CRAVA on Statoil's workstations (RH5 and RH6). I have succesfully built CRAVA on both, but are encountering some problems with running the test suite. According to the README file it should be possible to run the test suite from the test directory itself:

How to use the test suite:
--------------------------

1) From directory above  : make test
2) From current directory: ./TestScript.pl path-to-executable/cravarun

This is a nice feature as we don't have to copy the test suite directory (which is quite large) to all build realizations. However, when I call ./TestScript.pl path-to-executable/cravarun, I get the following error message:

Cannot open dir '../src': No such file or directory
Cannot open dir '../libs/lib': No such file or directory
Cannot open dir '../libs/boost': No such file or directory
Cannot open dir '../findgrammar': No such file or directory
Cannot open dir '../libs/nrlib/eclipsegrid': No such file or directory
...

It seems like ./TestScript.pl assumes that its parent directory is the source directory.

• Should it be possible to run the test suite out-of-source?
• If yes; Why does it fail for me?
• If no; Is it possible to implement this feature? (This will save some memory)

@ulvmoen
The build failure reported by Hudson/Jenkins on your e-mail was caused by this as I had to copy the test suite directory to the /tmp directory where the building takes place. This caused the error 'No space left on device'.

hi,
I tried installing CRAVA on cygwin, with ATLAS. But realised I need GNU/Linux. what distribution should I use ? any suggestions are welcome.
Thanks,
spj2000

There is an issues where the results of an interval is without any data, and with a rather cryptic error message (length=204 ms, required length 204 ms).

We have a case where storm surfaces works fine, but ASCII surfaces fail. @tinaek can provide data set.

Hi,

I am running a CRAVA inversion for a Statoil field, where I am setting up a multi zone inversion, which contains 8 zones.
CRAVA runs smoothly through the inversion if I set the correlation structure to base correlation structure for all but the last zone. However, it maybe better for the data if zone 3 (third from top) would use 'compaction correlation'. If I run CRAVA with setting, it stops when "blocking wells for correlation" for the first zone, where I did not change anything. The error message is:
Interval: zone 1

There are no nonsynthetic Vs logs available. Corr(Vp,Vs) is set to 0.7 and Corr(Vs,Rho) is set to 0.
cravarundaily: ../libs/flens/fullstorage.tcc:869: T& flens::FullStorage<T, Order>::operator()(int, int)
[with T = double, flens::StorageOrder Order = (flens::StorageOrder)1u]: Assertion `row>=_firstRow' failed.

It is correct that the Vs log is synthetic, but should not cause any problems here, I assume?"

Hope you can help!

Best regards,
uli

I find there is a bug on estimation multizone background model by choosing the mode 'compaction' for . It will always stop running by an error called 'Out of memory: St9bad_alloc'.

I haven't tested horizon import for format XYZIlXl in cases where the survey is not NS-EW oriented. I have such a case here, and the geometry of the inversion becomes all wrong. I compared the input and output surfaces in RMS, and as the ilustration shows they seem to be transposed, but in addition the time scale is also wrong. I have a hard time understanding this, as the format should be the same as that which was tested on OseEast last year.

We have a case where single surface inversion runs through, but using separate correlation surface fails. Rainer can provide input for reproduction.

Ensure that deprecated tags are removed, while new or changed tags have up-to-date information. Bring version numbering into sync with CRAVA.

Program execution stops when estimating background model with the following message:
Resampling background model...
crava: ../libs/nrlib/stormgrid/../grid/grid.hpp:233: size_t NRLib::Grid::GetIndex(size_t, size_t, size_t) const [with A = float]: Assertion `i < GetNI() && j < GetNJ() && k < GetNK()' failed.

Time shift for SegY CRA-793

@RagnarHauge and @hgolsen: I have run Crava with otherwise otherwise identical cases:

1. One in which I import wavelets from RokDoc and set yes
2. One in which I let Crava estimate the wavelet
3. One in which I use the wavelets estimated by Crava in the previous setup and set yes

Runs number 1 and 3 fail and number 2 succeeds.
The error message is identical in the two cases:

****************************************************************************************************
*****    Loading and processing data failed. CRAVA has to stop due to the following errors:    *****
****************************************************************************************************
Error when setting up wavelets: 

ERROR: Cannot find global wavelet scale. The maximum reflection
       coefficient of 50141.11  is outside valid range of [-1, +1].

ERROR: Cannot find global wavelet scale. The maximum reflection
       coefficient of 51558.45  is outside valid range of [-1, +1].

ERROR: Cannot find global wavelet scale. The maximum reflection
       coefficient of 54677.69  is outside valid range of [-1, +1].

ERROR: Cannot find global wavelet scale. The maximum reflection
       coefficient of 59915.95  is outside valid range of [-1, +1].

ERROR: Cannot find global wavelet scale. The maximum reflection
       coefficient of 68056.80  is outside valid range of [-1, +1].

ERROR: Cannot find global wavelet scale. The maximum reflection
       coefficient of 80526.41  is outside valid range of [-1, +1].

The amplitude values in the wavelets from RokDoc and Crava have a ratio of about 10:1. Still the reflection coefficient is given with identical values in the two runs. The estimated scaling factors are not shown in the log files.

Especially in relation to the multizone inversion, there are opaque error messages that leaves the user clueless. Error messages should specify (if applicable) zone, well, data type and specific description of the problem. Ideally, a hint towards how to solve the problem should be provided too.

Description of output files, e.g. which logs in which column for output logs and how to read rock physics distribution and covariance matrix CRA-794

These interval inputs: Top and Base (time) surfaces should be able to read text/ASCII.files, or constant values.
Ex:
Time Top Surface (ms): 1500 / or / Top_Horizon.txt
Time Base Surface (ms): 3000 / or / Base_Horizon.txt

Per today they are only able to read STORM.files.

Inversion stops when reading surface, this is the terminal output, the surface is in xyz-ASCII format with a header included:

Setting top and base surfaces for the entire inversion volume:
Top surface: Flat surface at depth 1500.00
Base surface file name: /project/path/tinek_PRM_temp/SimSource/CRAVA/INPUT/Horizons/ML_SimsorXYZ.txt
crava: ../libs/nrlib/surface/../grid/grid2d.hpp:147: size_t NRLib::Grid2D::GetIndex(size_t, size_t) const [with A = double]: Assertion `j < nj_' failed.

Missing values in surfaces can be handled much more generally than today. Ideally, crava should be able to fill in any missing value in a surface by interpolation.

Seems like a bug, with frequent crashes. Harald can provide input and data set for reproduction.

One of the Crava improvements from 2016 was that the output grid sampling should be an exact match of the input grid in the case where the number of layers were not given for the zones. I have a case at hand where this does not happen:

The resulting sampling rate is set to slightly less than 4 ms, and the segy file is writen with 3 ms sampling.

Warning: The input segy dz (4) does not match the output dz (3.96238). The output segy grid can therefore not be matched with input segy grid. The output dz will be used.

Is there any explanation to this?

Same cube exported from OpenWorks loads fine. Seems to be wrongly detected header information at fault. Cube already transferred.

Dear Crava

I am trying to install a Crava package on my personal computer. I install Intel C package, C ++ and Atlas. The comand make output this message. A problem in kringinadmin.cpp. How can I fix this.

make
cd src && make
make[1]: Entering directory '/home/anderson/Área de Trabalho/crava-master/src'
g++ -c -O2 -DFLENS_FIRST_INDEX=0 -I.. -I../libs/fft/include -I../libs -Wall -pedantic -Werror -Woverloaded-virtual -Wno-long-long -fno-strict-aliasing -Wno-deprecated-declarations -Wno-unused-but-set-variable krigingadmin.cpp -o ../obj/krigingadmin.o
krigingadmin.cpp: In member function ‘void CKrigingAdmin::CalcSmoothWeights(CKrigingAdmin::Gamma, int)’:
krigingadmin.cpp:1247:25: error: catching polymorphic type ‘class NRLib::IOError’ by value [-Werror=catch-value=]
1247 | catch (NRLib::IOError e) {
| ^
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:12: ../obj/krigingadmin.o] Error 1
make[1]: Leaving directory '/home/anderson/Área de Trabalho/crava-master/src'
make: *** [Makefile:61: src] Error 2

Best Regards

Anderson Luiz Pimentel