Hello,
I'm not sure I ever tried a 2D Varian file but I would think that the
"varian" flag has to occur because otherwise it would misinterpret the
header information as data. And Varian data files are uniquely awful
because they have not only file header information but each block has a
header as well.
But I don't think that is the real issue with your processing (although it
would not help). And I don't think endianess is an issue (because it
doesn't look completely random). But you can (sort of) check endianess
with the Azara program utility/look_at which normally will give you a good
idea if you are dealing with data that needs swapping. (But I can't
remember, is Varian data always big endian maybe???)
I think the most likely real issue is the traces issue. I just took a
look at a VNMR manual and it is a bit unclear (to me) what this actually
means, except that it seems to be several experiments in one file (or
maybe a funny way of storing hypercomplex data???). I'm pretty sure I
never knew what it meant when #traces was not 1 so did not try to
intrepret it, hence the error message.
Is your fid around 4*1794*400 = 2870400 bytes in size (that is excluding
the headers so that is why I say "around")? Or is it much bigger? In
either case we might be lucky and the first trace is what you want and we
might be able to fool Azara into accepting it (by commenting out that
error and possibly changing the number of points in the par file). I can
take a look at it if you want (so if you email me the fid, assuming it
doesn't get bounced because of size!).
Wayne
On Thu, 9 Dec 2010, Justin Lecher wrote:
> On 09/12/10 19:03, Rasmus Fogh wrote:
>> Dear Justin,
>>
>> What happens when you try? Can you see anything that looks suspicious or
>> different in the .scr or .par file?
>>
>> Yours,
>>
>> Rasmus
>>
>
> * Lucky me the original mail wasn'T delivered due to size limitations.
> Here the smaller screenshot.
>
>
> Hi Rasmu,
>
> there are serveral things. Attached the raw files I get.
>
> First of all I still get those "row" errors. Additionally I get:
>
> Error converting 'False' to integer: set to 0.
>
> If I try to swap the data I get
>
>
> return self.func(*args)
> File
> "/usr/lib64/python2.6/site-packages/ccpn/python/ccpnmr/format/gui/ProcFilePopup.py",
> line 172, in <lambda>
> lambda : self.writeFile(self.azara,['processingPars'])],
> File
> "/usr/lib64/python2.6/site-packages/ccpn/python/ccpnmr/format/gui/ProcFilePopup.py",
> line 278, in writeFile
> self.updateAcqProcParsWidget()
> File
> "/usr/lib64/python2.6/site-packages/ccpn/python/ccpnmr/format/gui/AcqProcParsEditPopup.py",
> line 1410, in updateFromWidget
> getattr(self, parsListKey + 'Table').update()
> File
> "/usr/lib64/python2.6/site-packages/ccpn/python/memops/gui/ObjectsTable.py",
> line 189, in update
> self.callback()
> File
> "/usr/lib64/python2.6/site-packages/ccpn/python/ccpnmr/format/gui/AcqProcParsEditPopup.py",
> line 1510, in parameterUpdate
> swapApplData.value = swapState
> File
> "/usr/lib64/python2.6/site-packages/ccpn/python/memops/api/Implementation.py",
> line 2165, in setValue
> + ": %s" % (self,)
> ApiError: memops.Implementation.AppDataString.setValue:
> cannot set value, frozen: <memops.Implementation.AppDataString
> {application='allProcessing', keyword='swap', value='False'}>
>
>
>
> I the processing files there are those things which make me wonder:
>
> big_endian !Data is big endian
>
> I might be wrong, but I doubt that I have big endian data. But I might
> be from. Can I check that somehow?
>
> varian 2 !Varian data
>
> Makes azara scream with
>
> Fatal error: in "/mnt/tmpfs/fid": can only process Varian data with
> #traces = 1
>
>
> Adding "swap" to the .par and removing the big_endian I get following
> spectra (see attachment)
>
> Perhaps someone knows what is going wrong.
>
> Thanks justin
>
> --
> Justin Lecher
> Institute of Structural Biology and Biophysics
> ISB-3 Structural Biochemistry
> Research Centre Juelich
> 52425 Juelich, Germany
> phone: +49 2461 61 2117
>
>
