Closed calum-chamberlain closed 8 years ago
Issue in Sfile_util.readpicks: For a pick at a time hr:mn:sc, if sc is in [0,10), i.e. it is only one digit long, then it gets read as hh:mn+1:00. It looks like it stems from the following lines:
try:
time=UTCDateTime(evtime.year,evtime.month,evtime.day,
int(line[18:20]),int(line[20:22]),int(line[23:25]),
int(line[26:28])*10000)
except (ValueError):
time=UTCDateTime(evtime.year,evtime.month,evtime.day,
int(line[18:20]),int(line[20:22]),0,0)
time+=60 # Add 60 seconds on to the time, this copes with s-file
Curious, could you email me an example s-file. I haven't noticed this yet. Could you also, for that s-file, tell me what time you got?
It looks like the line highlighted is still in the develop branch here, so I should fix it.
By the way. When highlighting bugs it is really helpful to attach a link to the line in question, or the file. To link to a line, click on the line and copy the url. You have make links to things using square brackets for what you want the text to be, and round brackets for the link.
Sure thing! Here is an example of an s-file.
Thanks for the tip about bug highlighting! That is very helpful. I will make sure to do that next time.
On Fri, Feb 12, 2016 at 5:55 PM, Calum Chamberlain <notifications@github.com
wrote:
Curious, could you email me an example s-file. I haven't noticed this yet. Could you also, for that s-file, tell me what time you got?
It looks like the line highlighted is still in the develop branch here https://github.com/calum-chamberlain/EQcorrscan/blob/develop/eqcorrscan/utils/Sfile_util.py#L443, so I should fix it.
By the way. When highlighting bugs it is really helpful to attach a link to the line in question, or the file. To link to a line, click on the line and copy the url. You have make links to things using square brackets for what you want the text to be, and round brackets for the link.
— Reply to this email directly or view it on GitHub https://github.com/calum-chamberlain/EQcorrscan/issues/25#issuecomment-183180082 .
Grand - how did you generate this s-file? I guess in seisan? The reason it isn't reading that properly is that the SECON column should read more like this example... As such I haven't seen this before. 12-0848-03L.S200903.txt
If it is a seisan generated file, then the patch to S-file_utils would be to replace:
time=UTCDateTime(evtime.year,evtime.month,evtime.day, int(line[18:20]),int(line[20:22]),int(line[23:25]), int(line[26:28])*10000)
with:
time=UTCDateTime(evtime.year,evtime.month,evtime.day, int(line[18:20]),int(line[20:22]),int(line[23:28].split('.')[0]), int(line[23:28].split('.')[1])*10000)
This should read in the whole SECON column and split that on the decimal point.
This patch will need to be applied to the current development version here.
@gabematson can you confirm that you generated the s-file in question using seisan?
Interesting. I generated this s-file with the LFE_ssearch_imporved.m, the matlab equivalent to lag_calc. So it looks like S-file_util was unable to convert '7.' (for example) into an int by int(line[23:25]). Good call on reading in the whole second entry and splitting it up by the decimal.
On Sat, Feb 13, 2016 at 9:46 AM, Calum Chamberlain <notifications@github.com
wrote:
If it is a seisan generated file, then the patch to S-file_utils would be to replace:
time=UTCDateTime(evtime.year,evtime.month,evtime.day, int(line[18:20]),int(line[20:22]),int(line[23:25]), int(line[26:28])*10000)
with:
time=UTCDateTime(evtime.year,evtime.month,evtime.day, int(line[18:20]),int(line[20:22]),int(line[23:28].split('.')[0]), int(line[23:28].split('.')[1])*10000)
This should read in the whole SECON column and split that on the decimal point.
I won't apply this patch to EQcorrscan as we have made major changes to Sfile_util. But I will check how this bug effects the new version. Let me know how you generated the s-file.
— Reply to this email directly or view it on GitHub https://github.com/calum-chamberlain/EQcorrscan/issues/25#issuecomment-183482850 .
Okay, so it looks like an issue with that matlab file - although if seisan was able to read and locate the event then that means this patch should be applied globally.
Grand!
Bug fixed in quakeML feature branch prior to merge with develop here.
The Sfile_util patch is working great.
I am noticing something that may be a bug. In mag_calc.SVD_moments here, it looks like the number of events is getting compared to the V matrix. I am wondering if the number of events should actually be compared to the U matrix, which holds the weights for each wave form, whereas V holds the basis vectors. I very well could just be confused, but I thought I would ask.
Here is where the numpy.linalg.SVD gets called within clustering.SVD The flag 'fullmatrices = False' ensures that the V and U matrices are rectangular.
Here is the numpy documentation on the SVD method which talks about the fullmatrices flag. I actually think it might be fine to calculate rectangular matrices as long as the comparison is len(ev_list) to len(U_working) in this line.
That should be fixed in this commit.
This bug occurs only when you have more events than you use samples. I would recommend using long time windows (Rubenstein & Ellsworth use 10.5s), however you should now be able to work around it.
This issue thread will be kept open to track bugs found before release 0.0.10. Please add bugs here, even if you have fixed them as they will not be included in the master until the next release.