Dashboard > Data Handling Interface > ... > DHI 2 > The Great DHI 2 fissuresUtil Divestiture
  Data Handling Interface Log In | Sign Up   View a printable version of the current page.  
  The Great DHI 2 fissuresUtil Divestiture
 Browse Space
Added by Charlie Groves, last edited by Charlie Groves on Feb 27, 2006  (view change)
Labels: 
(None)

In the hopes of making fissuresUtil more of a general purpose library of commonly needed fissures code and less of a dumping ground for any code used by more than one South Carolina project, fissuresUtil for DHI 2 has had lots of code moved out into subprojects. In general anything USC specific has been moved out. fissuresUtil now only depends on fissuresIDL, fissuresImpl, TauP, SeedCodec and seisFile.

The package is now edu.sc.seis.fissuresUtil2 to correspond to the packages of fissuresIDL and fissuresImpl.

Unmoved contents

Package or Class Uses
bag SAC like seismogram processing
exceptionHandler Centralized exception logger and reporter
freq Seismogram filters
mseed,psn,sac Reads seismogram files into DHI objects
namingService Easy server binding and object retrieval for the name service
time Code to compare and merge DHI objects based on time

Contents moved in fissuresUtil

edu.sc.seis.fissuresUtil.simple.Initializer.java moved to edu.sc.seis.fissuresUtil2.Initializer.java It handles setting up the orb and creating a FissuresNamingService object based from the command line args.

Contents that will be moved to other projects

Packages cache, chooser, dataset, display, flow, gmt, map, mockFissures, netConnChecker, parmo3d, rt130, simple, sound, xml have all been removed from fissuresUtil.

Comments  (Hide)

I hope you'll consider making mockFissures its own library since it's purpose should be only for testing. - Joanna

Posted by Joanna Muench at Feb 27, 2006 20:03 | Permalink

Moving it out to a separate library is definitely part of the plan. If anyone else has pieces of fissuresUtil they'd like to see migrated to a new project sooner rather than later, they should say so here.

Posted by Charlie Groves at Feb 28, 2006 09:58 | Permalink

I would also suggest moving the bag library out. For two reasons. One, most clients don't do any processing. I think the fissureUtil lib should be reserved for the most common utilities. And two, the bag library is more likely to see changes/improvements than the rest of fissuresUtil.

Have you looked into other fft algorithms than the Numerical Recipes version that Anthony Lomaz uses?

Posted by Joanna Muench at Mar 21, 2006 14:11 | Permalink

I am not sure if bag will move out or not. It isn't that large, so it isn't a big deal for a client that doesn't use it and I would expect that the release cycle of fissuresUtil will continue to follow releases of our clients, and so bag would not likely cause extra releases. While I do want to avoid the "mother or all jars" that fissuesUtil seems to have become, there are also problems if the packages get broken into too many pieces, the classpath becomes challenging and circular dependencies become more likely. Bit of a judgement call I suppose.

I did look for java ffts once or twice, didn't find much out there.

Posted by Philip Crotwell at Mar 24, 2006 15:41 | Permalink
Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request - Contact Administrators