help-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] How to structure a GNU scientific project


From: Dale Lukas Peterson
Subject: Re: [Help-gsl] How to structure a GNU scientific project
Date: Tue, 9 Nov 2010 10:16:13 -0800
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Nov 09, 2010 at 10:21:33PM +0800, Jerome BENOIT wrote:
> Hello Luke,
> 
> this is not really a GSL issue:
> any GNU scientific project is a GNU project:
> have you look at the GNU hello program project ( 
> http://www.gnu.org/software/hello ) ?
> 
> Of course, you can take as example the GSL source.
> 

Thank you for you response.  The hello project is an excellent example
of many things, but one thing it doesn't seem to address is where to
install input data files, especially ones that a user would want to
use as templates for their own.  I realize that this isn't an issue
specific to GSL, but I was hoping that users of GSL might be familiar
with the issue I am facing, especially if they have experience
distrubting their products.

I'm still searching for a solution, it seems like my best option so
far is to install in /opt (or suggest that users install in their home
directory) and use the directory structure that matches the way I use
my tool.

Many thanks,
~Luke

> hth,
> Jerome
> 
> On 09/11/10 02:36, Luke wrote:
> >I'm trying to organize the directory and file structure of my project
> >and figure out how everything should be installed in a way that
> >complies with the GCS and FHS.  Currently, my project provides several
> >command line binary executables that do some numerical number
> >crunching using GNU GSL.  The inputs to these binaries are a few human
> >readable text files which specify some simulation parameters and
> >settings.  The outputs of the executables are a couple of data files
> >(time histories, level curves, etc.) and a couple of text files that
> >show the simulation settings that were actually used and specify the
> >format of the output data.  On top of this, I have some Python scripts
> >which generate plots from the data files, and save them as pdfs.  The
> >python scripts call os.system to specify the simulation inputs, run
> >the simulation, and process output data to make some plots.  It also
> >takes all inputs and outputs (input text files + output data + plots)
> >and bundles them into a time-stamped tar.gz file so that multiple
> >simulation runs don't overwrite each other, and to provide a way to go
> >back and look at simulation results and know exactly what conditions
> >created them.
> >
> >I have several sets of example input text files that allow a user to
> >run the simulations with some default parameters.  I'm not clear on
> >where these files should be placed in the source distribution and
> >where they should be installed during 'make install'.  I would like a
> >user to be able to easily find and open these text files so they can
> >use them as templates for running simulations with different
> >parameters.
> >
> >My questions are:
> >1)  Where should I put these text simulation configuration files
> >within my source distribution, and where should they be installed to
> >by default?
> >2)  How should I make my application and/or user aware of where they
> >are installed?  The way these files are used is by specifying a
> >command line flag that directs the executable to parse a particular
> >input file, so in order for this to be useful, the directory they are
> >installed into must be known.
> >3)  Should the python scripts go in site-packages, or would it make
> >more sense for them to be installed alongside the binary executables?
> >4)  I use the python scripts to save everything in a results/ folder
> >(and I'm often working with my source directory, so this is
> >src/results).  It seems like this folder ought to be in the users home
> >directory somewhere, but maybe there are other places it would make
> >sense to put this type of output data?
> >
> >It seems like the text input files should go in a subdirectory of
> >/usr/local/share, or maybe the whole project should go into a
> >subdirectory of /opt.  The way I'm using the tools is by having
> >everything within a folder in my home directory, but this is probably
> >not a good way to distribute.
> >
> >The basic source layout is:
> >top-level -- has the standard GCS files and Autotools files
> >     src -- sources files which compile to executables, also has some
> >python scripts for postprocessing the data
> >     src/common -- convenience libraries that are used by executables
> >     src/intialconditions -- text files for controlling initial
> >simulation conditions
> >     src/parameters -- text files for specify different numerical
> >values for simulation parameters
> >     src/integrationsettings -- text files for choosing different
> >numerical integration settings
> >
> >There are anywhere from 5-20 text files in each of the
> >src/initialconditions, src/parameters, src/integrationsettings folders
> >that I want to distribute in some logical fashion.
> >
> >Any thoughts?  Also, I'm using Autotools (Autoconf and Automake), so
> >if there are good ways to do this automagically with these tools, that
> >would be ideal.
> >
> >Thanks,
> >~Luke
> >
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]