LAS file with more curves defined in ~C section than available in ~A section

[VelizarVESSELINOV]

Current exception:

  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/lasio/las.py", line 238, in read
    d = data[:, i]
IndexError: index 4 is out of bounds for axis 1 with size 4

 ~Curve Information
 DEPTH.F                : 1    DEPTH
 TVD.F                  : 2    TVD
 VS.F                   : 3    VS
 Gamma.CPM              : 6    Gamma
 ROP.Ft/Hr              : 5    ROP
 TEMP.F                 : 6    Temperature (Tool)
~ASCII LOG DATA SECTION
19160 10415.184 8974.944 57.011
19160.5 10415.19 8975.444 57.011

Suggestion:

• have LASDataError with message less curves in ~A are available than declared in ~C
• Create a warning and considered that the missing curves ~C are full with missing values

[kinverarity1]

Yes I like the suggestion and will add :

• Where there are more data columns than curves defined, the additional columns are named UNKNOWN[n]

[ghost]

Did anyone ever come up with any ideas regarding this one? I'm finding it difficult to come up with an obvious solution. Potentially could it be possible to add an option read mnemonic names from the '~A' line if present?

[kinverarity1]

Hey @harry-allerston thanks for bringing this back to our attention! Turns out lasio is a bit of a mess in this situation:

For this test file:

 ~VERSION INFORMATION
 VERS.                          2.0 :   CWLS LOG ASCII STANDARD -VERSION 2.0
 WRAP.                          NO  :   ONE LINE PER DEPTH STEP
~WELL INFORMATION 
#MNEM.UNIT              DATA                       DESCRIPTION
#----- -----            ----------               -------------------------
STRT    .F              19160                    :START DEPTH
STOP    .F              19160.5                  :STOP DEPTH
STEP    .F                 0.5                   :STEP 
NULL    .               -999.25                  :NULL VALUE
COMP    .       ANY OIL COMPANY INC.             :COMPANY
WELL    .       AAAAA_2            :WELL
FLD     .       WILDCAT                          :FIELD
LOC     .       12-34-12-34W5M                   :LOCATION
PROV    .       ALBERTA                          :PROVINCE 
SRVC    .       ANY LOGGING COMPANY INC.         :SERVICE COMPANY
DATE    .       13-DEC-86                        :LOG DATE
UWI     .       100123401234W500                 :UNIQUE WELL ID
 ~Curve Information
 DEPTH.F                : 1    DEPTH
 TVD.F                  : 2    TVD
 VS.F                   : 3    VS
 Gamma.CPM              : 6    Gamma
 ROP.Ft/Hr              : 5    ROP
 TEMP.F                 : 6    Temperature (Tool)
~ASCII LOG DATA SECTION
19160 10415.184 8974.944 57.011
19160.5 10415.19 8975.444 57.011

>>> las = lasio.read("test.las")
>>> print(las.curves)
Mnemonic  Unit   Value  Description
--------  ----   -----  -----------
DEPTH     F             1    DEPTH
TVD       F             2    TVD
VS        F             3    VS
GAMMA     CPM           6    Gamma
ROP       Ft/Hr         5    ROP
TEMP      F             6    Temperature (Tool)
>>> las["GAMMA"]
array([57.011, 57.011])
>>> las["ROP"]
array([], dtype=float64)
>>> las["TEMP"]
array([], dtype=float64)
>>> print(las.df())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\devapps\kinverarity\projects\lasio\lasio\las.py", line 810, in df
    df = pd.DataFrame(self.data, columns=[c.mnemonic for c in self.curves])
  File "c:\devapps\kinverarity\projects\lasio\lasio\las.py", line 823, in data
    return np.vstack([c.data for c in self.curves]).T
  File "<__array_function__ internals>", line 5, in vstack
  File "C:\ProgramData\miniconda3\envs\wrap\lib\site-packages\numpy\core\shape_base.py", line 283, in vstack
    return _nx.concatenate(arrs, 0)
  File "<__array_function__ internals>", line 5, in concatenate
ValueError: all the input array dimensions for the concatenation axis must match exactly, but along dimension 1, the array at index 0 has size 2 and the array at index 4 has size 0

My ideas:

• a warning should be emitted for the curves ROP and TEMP - they are defined but have no data
• the data arrays for curves ROP and TEMP should not be empty - they should be full of np.nan values
• las.df() should work and not raise an exception

However, I have a feeling you are referring to the opposite situation? Where the data section has more curves than the ~Curves definition section? In that case, lasio works fairly well but its functionality is undocumented 😬 - see #477

[ghost]

That's interesting, my problem is the same as in your example above only that the ~A line also contains the column names. Your example seems to get further than mine though.. I get a 'cannot reshape array' error on even running lasio.read(), I can't even get as far as you did with it.

[kinverarity1]

What version of lasio are you using? lasio.__version__

[ghost]

Looks like 0.24.1

[kinverarity1]

OK try upgrading, you should get 0.29. There has been quite a bit of development in the last year.

[ghost]

Thanks for looking at this so quickly - need to look at the code changes, but how would this deal with the case where the 'empty' column isn't the first or last and there's nothing in the ascii header line to label the columns? Is there a risk that assuming sequential allocation means that the wrong data gets assigned to the wrong mnemonic?

[kinverarity1]

We rely on the sequence of mnemonics in the ~C section as the definition - that's how the LAS format is defined and basically all LAS files have a ~C section even if it is not always properly used by non-conforming software... so the issues you rightly raise probably fall under a different one: if we parse any mnemonics which exist in the ~A line, what we do in the case that they conflict with those defined in the ~C section? At the moment lasio does not parse the mnemonics in the ~A section - adding that is something's that been long outstanding: #30.

[ghost]

That makes sense, I guess that this might be dangerous as implemented however.. for example in one of my files the curve section defines:

curve_a curve_b curve_c curve_d

but the ascii section defines

curve_a curve_c curve_d

in this case would the mnemonics not be assigned incorrectly on load?

[kinverarity1]

Yep, something to discuss under #30

[ghost]

I think It might be best to make this behavior optional due to the potential mess it could cause, would you agree?

[kinverarity1]

What behaviour are you referring to?