Bug Reports

ref2sac incorrectly converts Ref Tek RT 130 data files to SAC. Read the report by Larry Baker of USGS on fixes to ref2sac (linked below).

31 macbook% !18 I1963rawup.trd !$ /opt/passcal/bin/125_segy I1963rawup.trd ~/unix/ant/CH/Exp/Uphole <br /><br />125_SEGY v3.00 (C) 1998-2005 Refraction Technology, Inc. All Rights Reserved <br />Bus error <br /><br />------ <br /><br />your version: <br />PASSOFT-2010-337.snowleopard.intel.dmg <br />Mac OS 10.6.5 <br />Input file available from Bob Greschke (85 MB)

Dear IRIS Passcal team We had RHEL6- ppc 64 os on IBM p4 server. Am unable to compiling the rt2ms and other python related executables in ppc 64 Machine, i am getting problem with <br />/usr/bin/env picpython. Am unable to getting the picpython for ppc64 . so kindly sent me the solution and if possible please send precompiled binaries for RHEL6 - ppc64 cheers

Dear, I'm trying to run qmerge on guralp miniseed data. <br />I've attached a pql screen shot with : <br />- 1 hour "raw guralp miniseed" on the bottom <br />- and three 20minutes miniseed files after : <br />qmerge -b256 -P 20M 2012.01.30-0500-T79-HHZ-00-CF.mseed <br /><br />So running qmerge, msrepack on these datas make appear plenty gaps. <br />If you need dataset, I can send it. <br />I've contact Guralp and here is their answer. <br /><br />"I think that your quickest route to a solution is to report the problem to PASSCAL. We are not trying to avoid responsibility here: if it turns out that the problem is with the way we are writing miniSEED then we will work hard to resolve it as soon as possible. Our problem at the moment is that, to understand why the process is failing, we would need to understand the code to qmerge, which we did not write and have not studied. The PASSCAL developers are much better placed to carry out this step." <br /><br />If you need further informations, don't hesitate to contact me. <br />Regards. <br /><br />Jean-Michel Douchain

Hi! When I run rt2ms on my Mac (10.5.8), I cannot get it to work! I get a weird error (copied below). I am searching for a solution, but <br /> rt2ms -f 114027620_0036EB79 -R -L -o MSEED -p par_rtms_edited.txt <br />Version: 2010.293 <br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Warning Will Robinson: Par file entry for this das, refchan, refstrm already exists. Using new value.<br />Processing: 114027620_0036EB79 <br />Error: Can't open 114027620_0036EB79. 'NoneType' object has no attribute 'open' 0.00 minutes <br /><br />This happens to all my ref files! I got my parameters all set set up, too. I copied a ref file into the local directory just to see why I get this. I changed permission... no luck. I am looking into the Python code, but am afraid to mess it up! I tried attaching the ref file, but it does not allow me. Ideas?

human2epoch and epoch2human are not reciprocal, but the same epoch time corresponds to a 7 hour time difference depending on which code is used. <br /><br />Expected behaviour: human2epoch and epoch2human are reciprocal functions <br /><br />/opt 158> human2epoch 2006:001:00:01 <br />human2epoch: Version 2004.100 <br />1136048460 <br /> <br />/opt 163> epoch2human 1136048460 <br />2005,365,17:01:00 <br />(Note 7 hours difference between time returned by epoch2human and time fed into human2epoch) <br /><br />Versions: <br />/opt 166> epoch2human -h <br />Version 2002.053 <br />human2epoch: Version 2004.100 <br /><br />Version of PASSCAL software used: 2010-063 <br /><br />In PASSOFT-LATEST (on 2011-07-21) epoch2human bombs with a segmentation fault, so I cannot check whether this has been updated, but this should probably be a separate bug (I tried recompiling, which works but still results in a segmentation fault) <br /><br />Fedora release 12 (Constantine) <br />Kernel 2.6.32.26-175.fc12.x86_64

Every time I click "Build Trace db" button in fixhdr window, the program freezes. I tried to use ctrl+C to stop the program but it does not work , there is still a process hanging "opt/passcal/otherbin/picpython /opt/passcal/ib/pyth". Using "kill -9 xx" would kill the process and the window of fixhdr will be closed. I wonder what is the problem. I have over 6000 miniseed traces in the data folder, would it be a problem?