Free research methods software for linux

ResearchMaster project has been designed to make working a little easier. Specifically, the application can be either a storage facility for all of your precious, miscellaneous digital information, or for just some of it. The project began as a way for the author to [1] have a centralized library for all the papers and various snippets he collects, and [2] to have some powerful, built-in support for BibTeX, the LaTeX bibliography system ( The LaTeX bibliography system, as described in the Leslie Lamport book. ISBN 0-201-52983-1).
When the application starts up, it creates a virtual filesystem (vfs) from information contained in records. Each record appends itself under at least one folder in the vfs, and the vfs is represented by a tree-widget system of folders and records. The application is divided into folder controls (left) and record controls (right).
Each record is actually a set of three python dictionaries, stored in a flat ascii text file. The three dictionaries correspond to [1] BibTex information corresponding to the record, [2] Meta information (eg. isbn, call number, url, membership) and [3] an endless notes file. When a record is selected from the tree widget, the corresponding three dictionaries are presented in a three-tabbed notebook widget on the right side of the application.
New records are created via a button on the records toolbar. When you create a new record the application pops a filechooser and you are given the opportunity to import a single file. Perhaps the imported file is a pdf copy of a research paper that you dont want to lose. ResearchMaster is a good place to store it. First, the record and the imported file now have each other. Now you can keep a log of your involvement with the file in the notes portion of the record. The Meta portion of the record contains non-BibTex information, such as which folders the record is a member of. The application accesses the records BibTex information whenever the record has membership within the subtree of a particular folder for which a recursive bibliography is being generated.
Heres a typical example: Say you create a folder for some project. Lets say that after six months your folder now has several subtrees of folders and records, all arranged according to the scheme that happened. Now imagine there are twenty records with BibTex information strewn throughout the projects subtree, side-by-side with other records that dont have BibTex information (notes, whatever). By pushing the Create Bibliography button on the left toolbar the application will produce a perfectly formatted BibTex file with all twenty records.
Each record can be made a member of any folder simply by adding the folders path to the membership list in the Meta portion of the record. The tree widget is dynamically constructed by recursively examining a directory tree (corresponding to the folders of the tree-widget) and the membership list contained in each record. This is done so that we only have one physical copy of each record, despite the fact that the record might show up in fifty different places throughout the tree widget.
The file that gets imported with a record can be any file of any format. You can tell ResearchMaster to launch the file as an argument to any external application, based on the filenames suffix (.gif, .avi, .mpg, .mp3). Then, select the record from the tree, push the launch button (on the records toolbar), and voila! The associated application brings up your file. Thats one feature that makes working a little easier.
Enhancements:
- Small correction was needed on line 1140 of ResearchMaster_wxuser.py, where "researchmaster" needed to be "ReseaerchMaster" for preferences initialization.

GNU Archimedes is the GNU package for the design and simulation of submicron semiconductor devices. Archimedes is a 2D Fast Monte Carlo simulator which can take into account all the relevant quantum effects, thank to the implementation of the Bohm effective potential method.

The physics and geometry of a general device is introduced by typing a simple script, which makes, in this sense, GNU Archimedes a powerfull tool for the simulation of quite general semiconductor devices.

In the present release, GNU Archimedes is able to simulate electrons and heavy holes in Silicon and GaAs (Gamma and L-valleys) devices (holes are simulated by means of a simplified MEP model), and in the next release, which is in preparation, it will be able to make simulations in 1D, 2D and 3D (this release will be delivered as soon as possible).

The Scientifical and Industrial Motivations
In today semiconductor technology, the miniaturization of devices is more and more progressing. In this context, it is easy to see that numerical simulations play an important role at every level of device manufacture. In fact, the cost of designing and physically constructing prototypes for VLSI semiconductor devices is very high and without the availability of advanced simulators the efforts for devices miniaturization would, likely, be brought to a halt. From assessing the performance of individual transistors, to circuits and systems, and, consequently, with the promise of improved device performance, industries are encouraged to keep on miniaturizing with lower manufacture costs.

But, unfortunately, such simulations are not whithout their challenges... A first consequence of device miniaturization is that simulations of submicron semicondutor devices requires advanced transport models. Because of the presence of very high and rapidly varying electric field, phenomena occur which cannot be described by means of the well-known drift-diffusion models, which do not incorporate energy as a dynamical variable.

That is why some generalization has been sought in order to obtain more physically accurate models, like energy-transport and hydrodynamical models. The energy-transport models which are implemented in commercial simulators are based on phenomenological constitutive equations for the particle flux and energy flux depending on a set of parameters which are fitted to homogeneous bulk material Monte Carlo simulations. So, this is not, certainly, a satisfactory physical description of the internal electronic dynamics in a semiconductor device.

As current device technologies quickly approach the scales whereby quantum effects due to strong confinement of carriers and direct source-drain tunneling will begin to dominate, new simulation techniques are required in order to fully understand and acurately simulate the physics behind the technology operation.

Of all the simulation methods currently employed, ensemble Monte Carlo has always been, both in the accademic and industrial community, the most vigorous and trusted method for device simulation, as it is proven to be reliable and predictive, as one can easily see from the vast bibliography on this subject.

However, as Monte Carlo relies on the particle nature of the electron (in fact we consider an electron like a biliard ball), quantum effects associated with the wave-like nature of electrons cannot fully incorporated into the actual simulators, i.e. the ensemble Monte Carlo have to be lightly (or strongly, it depends on the point of view and on the methods implemented...) modified to take into account the quantum effects, at least at a first order of approximation, which is certainly enough to take into account correctly all the relevant quantum effects present in the present-day semiconductor devices (till 2015 probably...). In order to take into account the wave-like nature of electrons we use a recently introduced quantum theory, the so-called Bohm effective potential theory.

So it is challenging and very interesting to develop such a code for 2D quantum submicron semiconductor devices. This is why I have decided to implement this code, but these are not the only motivations...

The Ethical Motivations
The very sad situation you quickly observe working in a semiconductor industry, but also in all places in which researches about semiconductor devices are made, the only codes for simulation you can find are not free and are proprietary codes.

That is a very bad situation because, at the present time, if you need to develop your own code for the purpose of simulating a device it is IMPOSSIBLE to obtain an advanced one in a short time, and, trust me, this is EXTREMELY BAD for scientific research... (Immagine if you had to re-discover the Newtonian laws every time you need them...) So, you can find a huge amount of papers describing a lot of numerical methods for simulating, in a very advanced way, semiconductor devices (even in the quantum case), but nobody will give you a code on which you can construct your own method (with the unlikely exception that at least one of the programmers is a friend of yours :) ).

Even worst, if you are a semiconductor device designer and you want to simulate "realistically" a new device, you have to pay (trust me, at very high costs!) a BINARY (just a binary and not the code!) from some well-known software industry. This binary will certainly have some bugs (because it is coded by humans which are not perfect...) and you will never have the possibility of fix them on your own. Of course, you can write to the software house and tell them that there is a bug, but, how many time do you will wait for a new release without those bugs? I dont think it will be a short time...

My impression is that, after a long research on the Web for a Free Software dealing with advanced 2D semiconductor device simulation, there was not a free code for the purpose of semiconductor devices simulation (i mean under GPL license). To be sure about it, I asked to the great Richard Stallman (by mail) if it will be worth to do a code like this and he encouraged me to code it, because there wasnt a code like this as free. So I decided to write this code..

Amiga Research Operating System (AROS) is a portable and free desktop operating system aiming at being compatible with AmigaOS 3.1, while improving on it in many areas. The source code is available under an open source license, which allows anyone to freely improve upon it.

Goals

The goals of the AROS project is it to create an OS which:

1. Is as compatible as possible with AmigaOS 3.1.
2. Can be ported to different kinds of hardware architectures and processors, such as x86, PowerPC, Alpha, Sparc, HPPA and other.
3. Should be binary compatible on Amiga and source compatible on any other hardware.
4. Can run as a standalone version which boots directly from hard disk and as an emulation which opens a window on an existing OS to develop software and run Amiga and native applications at the same time.
5. Improves upon the functionality of AmigaOS.

To reach this goal, we use a number of techniques. First of all, we make heavy use of the Internet. You can participate in our project even if you can write only one single OS function. The most current version of the source is accessible 24 hours per day and patches can be merged into it at any time. A small database with open tasks makes sure work is not duplicated.

History

Some time back in the year 1993, the situation for the Amiga looked somewhat worse than usual and some Amiga fans got together and discussed what should be done to increase the acceptance of our beloved machine. Immediately the main reason for the missing success of the Amiga became clear: it was propagation, or rather the lack thereof. The Amiga should get a more widespread basis to make it more attractive for everyone to use and to develop for. So plans were made to reach this goal. One of the plans was to fix the bugs of the AmigaOS, another was to make it an modern operating system. The AOS project was born.

But exactly what was a bug? And how should the bugs be fixed? What are the features a so-called modern OS must have? And how should they be implemented into the AmigaOS?

Two years later, people were still arguing about this and not even one line of code had been written (or at least no one had ever seen that code). Discussions were still of the pattern where someone stated that "we must have ..." and someone answered "read the old mails" or "this is impossible to do, because ..." which was shortly followed by "youre wrong because ..." and so on.

In the winter of 1995, Aaron Digulla got fed up with this situation and posted an RFC (request for comments) to the AOS mailing list in which I asked what the minimal common ground might be. Several options were given and the conclusion was that almost everyone would like to see an open OS which is compatible to AmigaOS 3.1 (kickstart 40.68) on which further discussions could be based upon to see what is possible and what is not.

So the work began and AROS was born.

EnsEMBL::Web::Record is a family of modules used for managing a users persistant data in a database.

SYNOPSIS

Many web sites now encourage users to register and login to access more advanced features, and to customise a site to their needs.

The EnsEMBL::Web::Record group of Perl modules is design to manage any arbitrary type of user created data in an SQL database. This module follows the Active Record design pattern, in that each new instantiated Record object represents a single row of a database.

That object can be manipulated programatically, and any changes made can be stored in the database with a single record->save function call.

Because arbitrary Perl data structures can be stored in this manner, EnsEMBL::Web::Record allows user preferences to be easily saved, and allows developers to implement new featurs quickly.

This module was first used (and has been abstracted from) the Ensembl genome browser (http://www.ensembl.org).

New user data can be added to the database:

use EnsEMBL::Web::Record;

my $bookmark = EnsEMBL::Web::Record->new();
$bookmark->url(http://www.ensembl.org);
$bookmark->name(Ensembl);
$bookmark->save;
...

The Record can be associated with an user id:

$record->user($id);

The same record can also be removed:

$bookmark->delete;

EnsEMBL::Web::Record also provides a number of methods for getting collections of records from the database, using a field selector.

EnsEMBL::Web::Record::find_bookmarks_by_user_id($id).

WebService::MusicBrainz is a Perl module that will act as a factory using static methods to return specific web service objects.

SYNOPSIS

use WebService::MusicBrainz;

my $artist_ws = WebService::MusicBrainz->new_artist();
my $track_ws = WebService::MusicBrainz->new_track();
my $release_ws = WebService::MusicBrainz->new_release();

METHODS

artist_new()

Return new instance of WebService::MusicBrainz::Artist object.

new_track

Return new instance of WebService::MusicBrainz::Track object.

new_release

Return new instance of WebService::MusicBrainz::Release object.

Method::Declarative is a Perl module to create methods with declarative syntax.

SYNOPSIS

use Method::Declarative
(
--defaults =>
{
precheck =>
[
[ qw(precheck1 arg1 arg2) ],
# ...
],
postcheck =>
[
[ qw(postcheck1 arg3 arg4) ],
# ...
],
init =>
[
[ initcheck1 ],
# ...
],
end =>
[
[ endcheck1 ],
# ...
],
once =>
[
[ oncecheck1 ],
] ,
package => __CALLER__::internal,
},
method1 =>
{
ignoredefaults => [ qw(precheck end once) ],
code => __method1,
},
) ;

The Method::Declarative module creates methods in a using class namespace. The methods are created using a declarative syntax and building blocks provided by the using class. This class does not create the objects themselves.

The using class invokes Method::Declarative, passing it list of key-value pairs, where each key is the name of a method to declare (or the special key --default) and a hash reference of construction directives. The valid keys in the construction hash refs are:

code

The value corresponding to code key is a method name or code reference to be executed as the method. It is called like this:

$obj->$codeval(@args)

where $obj is the object or class name being used, $codeval is the coresponding reference or method name, and @args are the current arguments for the invocation. If $codeval is a method name, it needs to be reachable from $obj.

A code key in a method declaration will override any code key set in the --defaults section.

end

The value corresponding to the end key is an array reference, where each entry of the referenced array is another array ref. Each of the internally referenced arrays starts with a code reference or method name. The remaining elements of the array are used as arguments.
Each method declared by the arrays referenced from end are called on the class where the declared method resides in an END block when Method::Declarative unloads.

Each method is called like this:

$pkg->$codeval($name[, @args]);

where $pkg is the package or class name for the method, $name is the method name, and @args is the optional arguments that can be listed in each referenced list.

end blocks are run in the reverse order of method declaration (for example, if method1 is declared before method2, method2s end declaration will be run before method1s), and for each method they are run in the order in which they are declared.

Note that this is not an object destructor, and no objects of a particular class may still exist when these methods are run.

ignoredefaults

The value corresponding to the ignoredefaults key is an array reference pointing to a list of strings. Each string must corespond to a valid key, and indicates that any in-force defaults for that key are to be ignored. See the section on the special --defaults method for details.

init

The value corresponding to the init key is identical in structure to that corresponding to the end key. The only difference is that the declared methods/code refs are executed as soon as the method is available, rather than during an END block.

once

The value corresponding to the once key is identical in structure to that corresponding to the end key. The values are used when the method is invoked, however.

If the method is invoked on an object based on a hash ref, or on the class itself, and it has not been invoked before on that object or hash ref, the methods and code refs declared by this key are executed one at a time, like this:

$obj->$codeval($name, $isscalar, $argsref[, @args ]);

where $obj is the object or class on which the method is being invoked, $codeval is the method name or code reference supplied, $name is the name of the method, $isscalar is a flag to specify if the declared method itself is being executed in a scalar context, $argsref is a reference to the method arguments (@_, in other words), and @args are any optional arguments in the declaration.

The return value of each method or code reference call is used as the new arguments array for successive iterations or the declared method itself (including the object or class name). Yes, that means that these functions can change the the object or class out from under successive operations.

Any method or code ref returning an empty list will cause further processing for the method to abort, and an empty list or undefined value (as appropriate for the context) will be returned as the declared methods return value.

package

The value coresponding to the package key is a string that determines where the declared method is created (which is the callers package by default, unless modified with a --defaults section). The string __CALLER__ can be used to specify the callers namespace, so constructions like the one in the synopsis can be used to create methods in a namespace based on the calling package namespace.

postcheck

The value coresponding to the postcheck key is identical in structure to that coresponding to the end key. The postcheck operations are run like this:

$obj->$codeval($name, $isscalar, $vref[, @args ]);

where $obj is the underlying object or class, $codeval is the method or code ref from the list, $name is the name of the declared method, $isscalar is the flag specifying if the declared method was called in a scalar context, $vref is an array reference of the currently to-be-returned values, and @args is the optional arguments from the list.

Each method or code reference is expected to return the value(s) it wishes to have returned from the method. Returning a null list does NOT stop processing of later postcheck declarations.

precheck

The precheck phase operates similarly to the once phase, except that its triggered on all method calls (even if the underlying object is not a hash reference or a class name).
Any illegal or unrecognized key will cause a warning, and processing of the affected hashref will stop. This means a --defaults section will be ineffective, or a declared method wont be created.

dtRdr::User.pm is a user class as a Perl module.

Constructor

new

$user = dtRdr::User->new($username);

Methods

init_config

$user->init_config($filename);

Greensocs project is a development kit for producing systems on a chip using SystemC (a C++ derivative) as opposed to Verilog or VHDL.
GreenSocs mission is to encourage SystemC to be used by designers. It will do this by engineering SystemC infrastructure to compliment the capabilities developed by OSCI and commercial EDA providers, promoting and utilising academic research. The aim is to extend the use and applicability of SystemC, by co-ordinating and promoting collaboratively developed models, methods and utilities, prioritised by designers needs.
The principle benefits are:
- To lower infrastructure development, training and adoption costs.
- To enable higher degrees of IP reuse and interchange.
- To enable EDA companies to build tools in support of the standards.
GreenSocs runs a SourceForge project called the GreenSocs project. Its aims are to develop SystemC infrastructure, basic IP, patches and add on library code for eventual standardisation. The GreenSocs project is made up of a number of contributions (sub projects).
In order to facilitate the use of SystemC and the infrastructure, patches and extensions that GreenSocs develops, pre-built binary packages including all of the stable GreenSocs patches and basic building blocks are available from the downloads area.
Enhancements:
- Assorted minor updates and bugfixes.