From woollard at geocom.com.au Tue Nov 3 20:48:21 2009 From: woollard at geocom.com.au (Keith Woollard) Date: Wed, 04 Nov 2009 10:48:21 +0800 Subject: [GF] copy after share - details In-Reply-To: <59773D77008AAC4898702F8231411DBF017EC0A1@HOUMSPCNMX02.corp.dvn.com> References: <4AE9477F.9020207@geocom.com.au> <59773D77008AAC4898702F8231411DBF017EC0A1@HOUMSPCNMX02.corp.dvn.com> Message-ID: <4AF0EB75.8080000@geocom.com.au> Thanks to the various people wo have provided some input. Just to clear up a few things. The copy order is definitely pseudo-random. I understand all about order of lines in surveys, the fact that they are in load order and can be re-arranged using "2d Surveys". The share process is done in this order. HOWEVER the subsequent copy process is not. In one particular case, I have a set of 117 lines loaded in order. They where in numeric order in the original project, they stayed in that order when shared to the new project, but here is the order they started to do the copy in: 117 036 041 040 039 031 043 035 044 034 033 038 037 046 etc etc etc Note that this order is repeatable. I deleted the files and redid it and it came up in the same order. I tried doing it in groups of ten lines, and within each group, the order was similar, but not identical, e.g. 9 4 3 2 8 7 6 1 and then 19 13 12 11 17 16 18 15 14 10 Secondly, I hate the concept of "make sure you have the latest patch"- the idea that you don't know what is wrong, but maybe a new version will fix it is hardly good problem solving strategy. As it turns out, I have discovered the problem and there are 3 lines, from a survey of 120, that the original IESX load failed to build a shot:trace table. I still don't know why this happened, but the key was finding what was stopping the copy. Now that I know what was stopping it, it was easy enough to identify the problem and fix prior to doing the share/copy. Thanks and regards Keith Bilyeu, Cindy wrote: >Keith, >We do tons of share/copies. We have a foreign office that does not have a seismic data loader. >We load the data from my office then create a little "traveling" project for them of the newly loaded data. I have lots of experience doing this process and I've never seen your issue before. I'd check on patches for the OS and the application. > >The sort order is not random like many think. It's actually the order the data got loaded. the last lines you loaded into a project will be at the bottom of the list. > >Kind Regards, >Cindy > >________________________________ > >From: gf-bounces at stevens.com on behalf of Keith Woollard >Sent: Thu 10/29/2009 2:42 AM >To: GF at stevens.com >Subject: [GF] copy after share - details > > > >..... and for the record, GF44 running on Linux > > > >I am having some trouble moving some data between projects. I have a >base project with some surveys and a new project with a single survey >containing about 1000 lines. In the base survey, I share in the new >survey, then use copy, and finally unshare. > >I have found that sometimes the copy process just stops, and leaves me >with both the "generate" and "close" buttons grey'ed out. The only way I >can get rid of the window is to exit the data manager. The most annoying >part is that the copy processes proceeds in a pseudo-random order, and >so it is very hard to pick out the 300 or so lines it misses. > >Does anyone know why this happens? > >-- >Keith Woollard >Senior Consultant >GeoCom Services Australia Pty Ltd (A.B.N. 63 068 362 498) >Ph 61 (08)9243 3544 fx 61 (0)8 9246 9410 >Email woollard at geocom.com.au >Web www.geocom.com.au > > > >_______________________________________________ >GF mailing list >GF at stevens.com >http://lists.stevens.com/mailman/listinfo/gf > > >Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. >If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of all or any portion of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. > > > -- Keith Woollard Senior Consultant GeoCom Services Australia Pty Ltd (A.B.N. 63 068 362 498) Ph 61 (08)9243 3544 fx 61 (0)8 9246 9410 Email woollard at geocom.com.au Web www.geocom.com.au From woollard at geocom.com.au Sun Nov 8 23:13:18 2009 From: woollard at geocom.com.au (Keith Woollard) Date: Mon, 09 Nov 2009 13:13:18 +0800 Subject: [GF] Geoframe Customer Satisfaction Survey In-Reply-To: <1A63386B4F899F47BFA77D53BB4F45F54347DE@HCMEXCH01.asia.tlm.com> References: <54E1E9E50CAA284D86B4EA28F075632901175D0453@eneperthex03> <1A63386B4F899F47BFA77D53BB4F45F54347DE@HCMEXCH01.asia.tlm.com> Message-ID: <4AF7A4EE.3010601@geocom.com.au> I know both Simon and Adam reasonably well and can see both sides. I hate being always negative but for those of us who use all the interp systems, it is hard not to bag GF from a data management point of view. Let me share two bugs that I have always known about, but never been able to isolate the exact cause. I am not sharing them to be negative to Schlumberger, it is just that once you know what causes a problem, you can avoid the suituation. Nav import bug #1 If you have a set of lines loaded with seismic and shot:trace only, and then you go to import the nav. AND the lines in order in the survey go something like:- 92DDS-01 92DDS-02 92DDS-03 92DDS-04 92DDS-05A 92DDS-05 92DDS-06 92DDS-07 92DDS-08 BUT the lines in order in the nav file go something like:- 92DDS-01 92DDS-02 92DDS-03 92DDS-04 92DDS-05 (note change of the A and non-A line) 92DDS-05A 92DDS-06 92DDS-07 92DDS-08 Then it will crash the load of the nav the first time. It will load the non-A line but come up with a carto error and not load the second line. Simple hitting the load again will make it continue past this point. Nav import bug #2 If you are importing nav where the number of digits change from 5, for example, to 6 then it may also bomb with the same carto error. Simply hitting the load button again will get past it. I have just loaded a nav file with 1150 seismic lines in it and it took approx 30 attempts to read the file. Nothing was wrong in the file, and nothing got changed during the various loads - I just had to keep trying. Regards Keith Youens, Simon wrote: Adam, If you are not happy with my postings, then why don't you contribute something? I mean that in the nicest, most constructive way. Besides my frustrations with having to get to grips with GeoFrame (because it is a "corporate standard"), I am also disappointed with the lack of a decent user forum and believe me, I could really use one. The official SLB forum is moribund and I think that is partly because you have to remember to log in to see if anything useful has been posted. This forum has the merit that any posts are pushed to the users and it is easy to scan the posts and reply if you feel the urge to do so, as you and I are demonstrating. However, as Dave Stevens has commented before, a forum like this needs a critical mass of subscribers in order to generate useful and interesting discussions and advice. I would strongly recommend that you subscribe to the SMT Kingdom forum for a while to see what I mean: ([1]http://lists.stevens.com/mailman/listinfo/3dpak) You will find a lot of useful information and quick answers to user's questions. On the other hand, there is also a lot of criticism and requests for new features or bug fixes. However, to SMT's credit, they do pay attention and frequently respond. I would also suggest that you try to get as many other GeoFrame users as possible to subscribe and start contributing. Some informed discussion here would be very useful and who knows, SLB might even pay some attention and fix some of Geoframe's problems. For some background information, I had five years of Landmark experience in the early 90s, followed by six years of pre-GeoFrame IESX experience (including managing the Unix environment) and then eight years of Kingdom experience. I have now been working with GeoFrame for four months and have come a long way up the steep learning curve, but because of the difficulties of using the software and having to rely on others to load data and fix crashes (in one case, I was down for two weeks), I estimate I am about 60-70% as efficient as I was when using Kingdom. Simon -----Original Message----- From: [2]gf-bounces at stevens.com [[3]mailto:gf-bounces at stevens.com] On Behalf Of Claxton, Adam Sent: Monday, October 26, 2009 4:43 AM To: [4]gf at stevens.com Subject: Re: [GF] Geoframe Customer Satisfaction Survey Gentlemen, I am on the email list for this forum but am not happy with its focus or supposed helpfulness. From the day it was set up it seems to be nothing more than a SLB whinge festival, with the current SLB Survey being the latest cause to chest beat. Last month's 'swear-word' email chain was its lowest point. I'll give it a few more months. Adam _______________________________________________ GF mailing list [5]GF at stevens.com [6]http://lists.stevens.com/mailman/listinfo/gf -- Keith Woollard Senior Consultant GeoCom Services Australia Pty Ltd (A.B.N. 63 068 362 498) Ph 61 (08)9243 3544 fx 61 (0)8 9246 9410 Email [7]woollard at geocom.com.au Web [8]www.geocom.com.au References 1. http://lists.stevens.com/mailman/listinfo/3dpak 2. mailto:gf-bounces at stevens.com 3. mailto:gf-bounces at stevens.com 4. mailto:gf at stevens.com 5. mailto:GF at stevens.com 6. http://lists.stevens.com/mailman/listinfo/gf 7. mailto:woollard at geocom.com.au 8. http://www.geocom.com.au/ From woollard at geocom.com.au Mon Nov 9 20:21:30 2009 From: woollard at geocom.com.au (Keith Woollard) Date: Tue, 10 Nov 2009 10:21:30 +0800 Subject: [GF] linux usb discs Message-ID: <4AF8CE2A.3000702@geocom.com.au> This question isn't about GeoFrame as such, but I am sure some of you will have seen this. When we mount some usb discs on our system, they power down after some amount of time. This causes the OS to remount them as read only. It is then a real pain to make sure there are no shells in that directory so you can umount and then mount it. Mostly seems to happen with the larger drives with external power sources. Does anyone know a way of avoiding this? I don't want to address specific disc brands, rather a more generic solution. I am guessing that a simple:- ls /usb* > /dev/null as a cron job every 10 minutes would fix it, but doesn't seem very elegant. And also with a large filesystem might add a fair bit of overhead Thanks in advance -- Keith Woollard Senior Consultant GeoCom Services Australia Pty Ltd (A.B.N. 63 068 362 498) Ph 61 (08)9243 3544 fx 61 (0)8 9246 9410 Email woollard at geocom.com.au Web www.geocom.com.au From dave at stevens.com Mon Nov 9 21:12:13 2009 From: dave at stevens.com (J. D. STEVENS) Date: Mon, 9 Nov 2009 21:12:13 -0600 Subject: [GF] linux usb discs In-Reply-To: <4AF8CE2A.3000702@geocom.com.au> References: <4AF8CE2A.3000702@geocom.com.au> Message-ID: <03ABF2E4-E12D-40C6-AB0D-184029CD5B48@stevens.com> Keith, There is an informative discussion of the issue here: http://www.debianhelp.org/node/11551 Some of the issues may be specific to Debian, but there is a comment about some drives having the spin down time coded to firmware. A light weight "exercise" program that can be run from cron is to simply touch a file on the disk on a regular basis. Dave On Nov 9, 2009, at 8:21 PM, Keith Woollard wrote: > This question isn't about GeoFrame as such, but I am sure some of you > will have seen this. > > When we mount some usb discs on our system, they power down after some > amount of time. This causes the OS to remount them as read only. It is > then a real pain to make sure there are no shells in that directory so > you can umount and then mount it. Mostly seems to happen with the > larger > drives with external power sources. > > Does anyone know a way of avoiding this? I don't want to address > specific disc brands, rather a more generic solution. I am guessing > that > a simple:- > ls /usb* > /dev/null > as a cron job every 10 minutes would fix it, but doesn't seem very > elegant. And also with a large filesystem might add a fair bit of > overhead > > Thanks in advance > > -- > Keith Woollard > Senior Consultant > GeoCom Services Australia Pty Ltd (A.B.N. 63 068 362 498) > Ph 61 (08)9243 3544 fx 61 (0)8 9246 9410 > Email woollard at geocom.com.au > Web www.geocom.com.au > > _______________________________________________ > GF mailing list > GF at stevens.com > http://lists.stevens.com/mailman/listinfo/gf -- Dave Stevens Dave at Stevens.COM STEVENS.COM, Inc. 713-419-0313 Bellville, TX, USA http://www.stevens.com