Opened 19 years ago
Closed 17 years ago
#90 closed enhancement (fixed)
linecatalog fails on import
| Reported by: | bugs | Owned by: | Malte Marquarding | 
|---|---|---|---|
| Priority: | low | Milestone: | ASAP 2.2 | 
| Component: | General | Version: | 2.0 | 
| Severity: | minor | Keywords: | |
| Cc: | mgb@… | 
Description
The next problem is trying to read in a line list, for instance the example below.
File: moleculelist.txt
mol1 109220 100.0 1.0 mol2 109770 100.0 1.0 mol3 109910 100.0 1.0 mol4 110190 100.0 1.0 mol5 112390 100.0 1.0 mol6 113220 100.0 1.0 mol7 115290 100.0 1.0
The line catalogue cant then be read; see sequence two below. I have been able to enter line frequencies by hand, eg
q1.set_restfreqs([109252.212,109782.173,109905.753,110201.353,112358.988,113191,115271.202],'MHz')
but this rather defeats the purpose of having a catalogue!
ASAP>mols = linecatalog('moleculelist.txt')
ASAP>mols.save('mols.tbl')
ASAP>mols=linecatalog('mols.tbl')
ASAP>mols.summary()
------------------------------------------------------------
Traceback (most recent call last):
  File "<ipython console>", line 1, in ?
  File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/asap/linecatalog.py", 
line 45, in summary
    pager(lcbase.summary(self, -1))
RuntimeError: Invalid Table data type when accessing column in 
ROScalarColumn ctor for column Column2
      Change History (5)
comment:1 by , 19 years ago
| Status: | new → assigned | 
|---|
comment:2 by , 19 years ago
| Priority: | high → low | 
|---|---|
| Severity: | major → minor | 
comment:3 by , 19 years ago
| Milestone: | ASAP 2.1 → ASAP 2.2 | 
|---|
comment:4 by , 19 years ago
| Type: | defect → enhancement | 
|---|
comment:5 by , 17 years ago
| Resolution: | → fixed | 
|---|---|
| Status: | assigned → closed | 
Fixed. This will be available in the next release (2.3.1).
  Note:
 See   TracTickets
 for help on using tickets.
    
Hi Michael,
this failure happens because 109220 is an integer not a float value. You can rectify this by appending a ".0" to those values.
We will change this behaviour sometime soon, in the meantime pleas use the above workaround.