over the past few decades high - performance 
 computing resources have enabled the larger simulation community to 
 push the limits of biomolecular simulations .
as more computational 
 power becomes available , researchers can tackle larger systems and 
 simulate for longer time scales .
while it was common practice to run 
 the simulations on remote clusters and bring back the resulting data 
 to the home institution , this paradigm is now beginning to break down . 

data has to be postprocessed directly at the source to minimize data 
 movements and minimize the amount of disk space necessary for storage . 

for example trajectories can be compressed and/or stripped of unnecessary 
 information ( e.g. , solvent ) before being copied over .
another approach 
 is to simply run the analysis remotely , where the data resides .
no 
 matter which approach is preferred , researchers need to deal with 
 a huge amount of data distributed over local and national resources . 

for example , molecular dynamics simulations of large biomolecules 
 with thousands of atoms can easily generate terabytes of data on the 
 microsecond time scale .
investigators need to store and catalog these 
 data sets generated by students and collaborators for multiple years 
 to comply with policies of the funding agencies , to ensure reproducibility 
 of the data , and to comply with requests to see the data by other 
 researchers .
several repository architectures have been proposed 
 to manage large biomolecular simulation data sets in a distributed 
 environment .
biosimgrid was deployed in 
 the uk to integrate several computational centers into a grid , where 
 data could be deposited , searched , and analyzed .
ibiomes on the other hand offers a distributed infrastructure that 
 allows biomolecular simulation data indexing with data deposit ( explicit 
 copy ) or in - place registration to avoid data movements .
trajectory 
 files are stored and indexed via the irods distributed file system , where metadata is represented as attribute  value 
while these approaches might work well to manage large distributed 
 environments , the deployment of such infrastructure depends on access 
 to substantial it expertise and resources , such as web servers , relational 
 databases , and distributed file systems , which may not be available 
 to many single investigators or small research groups .
many researchers 
 also depend on local or national computational and storage resources 
 that are allocated for a finite period of time .
usage of these resources 
 is usually very restrictive for security reasons , and the installation 
 of heavy components such as databases is not an option to manage the 
 data hosted at these remote locations .
another limitation of current 
 repositories is the need to copy the simulation data to a remote server 
 for publication .
this can be a tedious task that requires extra storage 
 cost if a copy of the data has to be kept at its original location . 
 in this paper
we introduce ibiomes lite , a new tool for biomolecular 
 simulation data indexing and summarization , designed to run in limited 
 settings , where the users might have limited privileges and limited 
 access to it resources .
a command - line interface allows the user to 
 summarize , publish , and search simulation data sets locally or remotely 
 via secure shell ( ssh ) .
published data sets are summarized through 
 a static web interface that describes the simulation protocols and 
 graphically represent analysis results .
ibiomes lite can be easily 
 installed on any data server to enable summarizations of old data 
 sets and figure out what their content is and what methods were used , 
 or to facilitate progress tracking by exposing current simulation 
 results .
in contrast with simple tools such as bookshelf and umm - model that 
 have been proposed to publish simulation data , but exhibit dependencies 
 on database components , ibiomes lite allows data indexing and summarization 
 while removing dependencies on external components that would require 
 root access or special support for deployment .
ibiomes lite s goal is to provide the means for individual 
 researchers or teams to index and summarize their simulation data 
 in limited settings , so they can keep track of their lab work and 
 share progress or results with collaborators .
the main user action 
 supported by ibiomes lite is the publication of experiments : the user 
 specifies a file directory or subdirectory that contains all the simulation 
 files ( input and output data ) , then with minimal input from the user , 
 the tool generates a detailed description of the computational experiment 
 workflow along with textual and graphical summaries , rendered through 
 a simple web interface .
once an experiment is published , it can be 
 searched via keywords representing the experiment metadata ( e.g. , 
 molecule name , residue sequence , computational method ) .
unlike the 
 full - fledged ibiomes repository , ibiomes 
 lite does not provide direct access to the files associated with the 
 published experiments .
all files are categorized and listed , but only 
 files presenting analysis data are made available for download .
this 
 limitation was required to keep simplicity as a key design criterion 
 for this tool .
deployment , 
 usage , and customization  as follows : the tool should be able to run in most environments , 
 independently from the operating system running on the host ( e.g. , 
 unix , windows )
. the tool should also be able to run whether a graphical 
 user interface is available or not .
this can be achieved by removing 
 dependencies on heavy - weight components such as databases , web servers , 
 or specific file systems .
the tool should be usable in a multiuser and distributed environment 
 by providing simple commands .
the command - line interface provides 
 a unix - like interface to summarize simulation data , publish them into 
 a static hypertext markup language ( html ) web site , and perform keyword 
 searches .
the 
 publication process should be easily customizable by the user so that 
 the resulting summaries provide an accurate and pertinent representation 
 of the raw data .
the entry point for the web interface is a page listing all the 
 published experiments , as shown in the ibiomes lite demonstration 
 instance presented in figure 1 .
general information 
 about the experiments ( e.g. , method , targeted molecular system , software 
 package ) is provided and can be used to sort the listing . by selecting 
 one of the listed experiments , the user can access more details .
the 
 summary page ( figure 2 ) presents a summary 
 of the experiment protocol along with possible analysis data , plots , 
 and 3d structures , rendered via jmol .
a 
 second html page provides a tree view of the protocol used in the 
 experiment , so that the user can access the details of interest , while 
 keeping the overall picture of the workflow ( figure 3 ) .
a third html page provides a tree view that allows the 
 user to browse the directory and subdirectories associated with the 
 experiment and list their content ( figure 4 ) .
finally a last html page gives 
 details about the execution of the tasks and the computing environment 
 ( figure 5 ) .
execution times and resources used 
 to run the tasks ( e.g. , number of cpus and gpus ) are reported , along 
 with hardware information ( e.g. , gpu architecture ) .
this view is intended for users 
 to track the progress of current simulations and assess the performance 
 of their simulation engine within the host environment .
example of 
 an experiment summary page within the ibiomes lite web site . in this 
 example
the page summarizes an md simulation of rna and enables graphical 
 display via jmol for 3d structure rendering and via autogenerated 
 plots to present analysis data .
the experiment simulates a solvated protein and includes 
 three processes : minimization , heating , and equilibration .
each process 
 can include multiple tasks ( or runs ) , which have method - specific parameters .
the tree view in the left panel enables directory browsing 
 while the main panel lists the files in the selected directory , grouped 
 by file format .
in this example , a list of remd runs ( 192 
 replicas each ) is presented to the user with job configuration details 
 ( e.g. , number of cpus and gpus ) .
extra computing environment information , 
 such as executable details and cpu / gpu architecture , can be displayed 
 by hovering over the associated elements .
ibiomes lite was implemented 
 in java 7 to ease the development of a platform - independent tool . 

although java 6 is arguably a more popular version , java 7 offers 
 enhanced file i / o libraries ( nio 2 ) that might prove to be useful 
 for future developments ( e.g. , file change listeners , file tree searches ) , 
 and it is still available at most us computing centers .
a set of bash 
 scripts for unix - like operating systems ( i.e. , linux and mac os - x ) 
 and win32 ( .bat ) scripts for windows were written to wrap the java 
 calls into simple commands .
these scripts can be easily called in 
 a console locally or remotely , via ssh for example .
users publish computational experiments to ibiomes 
 lite to create html summaries and index their data for searches .
a 
 user publishes a computational experiment by specifying a directory 
 or sub directory that contains all the simulation files ( input and 
 output ) and the name of the software package that was used to generate 
 these files ( figure 6 ) .
a set of file parsers 
 extract topology , method , and parameter information to generate a 
 representation of the simulation workflow , based on the data model 
 introduced in previous work .
the workflow 
 and file tree structures are stored as xml files then transformed 
 into several html pages via xsl ( extensible stylesheet language ) .
plots are generated for analysis files when 
 applicable then stored in the ibiomes lite web directory along with 
 the html files . once an experiment has been published the information 
 in the ibiomes lite web folder
the final output of the publication 
 process is a set of xml files , static html files , images , and other 
 analysis data file ( e.g. , spreadsheet ) .
these files can be exposed 
 via an http server such as apache ( http://httpd.apache.org/ ) or viewed locally if a graphical user interface is available .
if 
 neither option is available , the files can also be copied to a different 
 host for rendering . since the html is not generated on - the - fly by 
 server - side code the web content can always be copied without information 
 loss . in the next sections we describe in more details
the data extraction 
 step performed by the file parsers and the data transformation step 
 used to generate the html summaries .
the role of the parsers is to map a given computational experiment 
 file tree on disk to a logical representation of the protocol and 
 output of the experiment .
the data model introduced in our previous 
 work was used to guide the logical representation , 
 for both the definition of the java classes and the xml schema used 
 to represent individual computational experiments , i.e. the simulations . 

the parsers work at the file level , extracting important data or metadata 
 for file summary , and at the file tree level , trying to build the 
 logical model based on the file directory structure and the file - extracted 
 data .
an xml rule file can be used during the publication process 
 to define which parsers should be used for which files and to define 
 the way data is presented in the html summaries .
a more general configuration 
 file is used to specify default parameters for the publication process 
 ( e.g. , path to default xml rule file , default software package context , 
 console output options ) .
the file parsers are format - specific , although 
 they are expected to build certain common objects based on their type : 
 topology , parameter / method , or hybrid .
for example both the amber 
 parameter / topology and charmm protein structure file ( psf ) parsers 
 are expected to build an object representing a molecular system , composed 
 of one or multiple molecules , each represented by residues and/or 
 atoms . on the other hand the amber md input and namd configuration 
 file parsers are building objects representing the methods and parameters 
 used to run a computational task .
implementation of the parsers then 
 requires understanding of the target format and the expected object(s ) 
 to build .
all parsers target the data model introduced in previous 
 work to provide a common representation 
 of the computational protocol that is not software - specific .
the list 
 of current parsers provides different levels of support for various 
 software packages , including amber , gromacs , namd , nwchem , and gaussian .
the implementation of file tree parsers 
 is not as straightforward since unlike the structure of a file which 
 can be inferred from its format , the structure of a directory does 
 not follow any strict rule . while we can not force users to store their 
 files following a given directory structure , manual inspection of 
 files structure from many computational experiments performed in our 
 lab by numerous graduate students and post docs lead us to assume 
 that the protocol of the computational experiment can be inferred 
 by parsing certain files if the original owner can provide a description 
 of the file tree structure and the naming conventions they used to 
 organize the data .
examples of such naming conventions include mappings 
 between file format and suffix ( e.g. ,  .trj
the 
 preprocessing step in the mapping process is to parse all the files 
 in the input directory and its subdirectories using the file - specific 
 parsers .
the resulting file tree associates each file with a set of 
 descriptive data about the molecular system or computational methods . 

the second step is to build a logical representation of the computational 
 experiment protocol using these objects .
when publishing a new experiment 
 the user needs to specify the main software package that was used 
 to run the simulations ( e.g. , amber , namd , gaussian , nwchem ) . depending 
 on this argument
for example in amber , both md input and md output 
 files can be used to retrieve the methods and parameters of a run . 
 for most of the software packages
the output / log files are preferred 
 over input files to extract this type of data .
output files are typically 
 richer as they usually repeat information from the input file(s ) and 
 provide explicit values to parameters that have not been set in the 
 input , but which are used as the default values in the particular 
 software .
output files can also present some calculation details , 
 such as the evolution of the energy of system over a certain cycle 
 of iterations , that can be easily exposed and of potential value to 
 better understand the experiment protocol .
other rules can be 
 triggered based on the computational method used or the type of calculation 
 performed .
for example if minimization tasks and md tasks are detected 
 within the experiment , minimization tasks are grouped together , while 
 md tasks are divided into a  heating  process , an  equilibration  
 process and a  production md  process .
heating tasks 
 represent md runs where temperature of the system is slowly increased , 
 to eventually reach a reference temperature for the production runs . 

distinction between equilibration and production runs is currently 
 made based on the textual description of the task if it is available . 

, 
  prod  ,  equilibration  , and  equil  . for replica - exchange md ( remd ) , some extra step might be needed 
 to group replicas for the same run together . in amber for example , 

all 
 replicas for a single run are grouped together under a single remd 
 task instead of having separate md tasks representing individual replicas . 

each remd task is described like any other md task and it also has 
 a certain number of replicas and a type of exchange ( e.g. , temperature , 
 hamiltonian , multidimensional ) .
this representation helps summarizing 
 the data , especially when running remd simulations with hundreds of 
 replicas . by default remd output files stored in the same folder
this would apply 
 for example if a user stored three four - replica remd runs in three 
 different folders , each with four output files .
experience shows that 
 this approach is not unique , and some people might prefer to have 
 all remd output in a single folder .
replica identification and grouping 
 is then based on file naming conventions . using the same example , 
 a user could store all the remd output files in a single folder and 
 name the files using the pattern that identifies both the run and 
 the replica within this run , such as the user can specify this type of naming convention in the ibiomes 
 lite general configuration file or at run time using the -remd command line argument . if no run identifier is present in the name 
 pattern then grouping is solely based on the directory structure . 
 this type of rule - based grouping is currently applied to remd tasks 
 only but it could be expended to include any type of parallel enhanced 
 sampling task . after the logical model of an experiment is built within the java 
 code it is stored on disk as an xml file .
mapping between the java 
 object - oriented data model and the xml schema is performed via jaxb 
 ( java architecture for xml binding ) .
a second 
 xml file is generated based on the file tree structure , where each 
 file is associated with a set of metadata , represented as attribute - value - units 
 ( avu ) triplets .
this representation is very similar to the approach 
 used for the ibiomes repository to enable 
 indexing within irods ( integrated rule - oriented data system ) .
the avus are 
 derived from the objects extracted by the file parsers , such as molecular 
 system definitions or parameter sets .
each of these entities implement 
 a getmetadata ( ) method that translates the logical 
 entity ( object ) into a list of avus .
for example the getmetadata ( ) method for the thermostat class will generate avus 
 for the followings attributes : thermostat_algorithm ( e.g. , berendsen , 
 langevin ) and thermostat_time_constant if applicable ( e.g. , 2 ps for 
 a berendsen thermostat ) .
these xml documents provide two different 
 perspectives on the data : one that emphasizes on the experimental 
 protocol , or effectively the logical view , and another one that emphasizes 
 on the physical organization of the input and output files . while 
 the first view can provide some insight on the protocol used to run 
 the simulations , the second view enables simple data indexing via 
 keywords
another copy is pushed to the ibiomes lite web folder , in 
 a subdirectory dedicated to the experiment .
a separate xml document 
 representing the list of published experiments is also updated by 
 copying experiment - level avus from the xml document storing the experiment 
 file tree . beside the experimental 
 protocol and the file tree , ibiomes lite can present analysis data 
 in the experiment summary page .
the user can edit an xml configuration 
 file to define which piece of data should be presented and how it 
 should be presented ( see example in the supporting 
 information ) .
this is achieved by associating file name patterns 
 to analysis descriptions , as introduced in ibiomes .
any file that is marked as analysis data is copied to the 
 ibiomes lite web folder to enable display and/or download .
for example 
 pdb files that are marked as analysis data can be rendered via jmol , and image files ( e.g. , png , jpeg ) are presented 
 as thumbnails linking to a copy of the original picture . for column 
 delimited text files ( e.g. , tab- or comma - delimited files ) the tool 
 attempts to create a graphical representation of the content .
the 
 xml configuration files can be used to define the type of plot to 
 be generated ( e.g. , line plot , histogram , heatmap ) , its labels , units , 
 and title ( see example in the supporting information ) .
the resulting plot is exported as an image and copied over to 
 the ibiomes lite web folder , along with the original data file .
once the xml files and data files have been 
 copied to the ibiomes lite web directory , all data and metadata of 
 interest are ready to be visually rendered by transforming the xml 
 into html .
multiple xsl stylesheets define the mappings between the 
 xml and the various html pages necessary to list the published experiments 
 and provide details about individual experiments .
the actual xsl 2.0 
 based transformation process in the java code is performed via the 
 saxon processor . since xsl stylesheets 
 are defined as separate documents one could easily customize these 
 html templates to fit their need .
ibiomes lite allows multiple users 
 to share the same web directory to publish experiments .
this means 
 that all the members of a lab for example can publish experiments 
 stored on a shared file system to a single portal . from a user - interface 
 perspective , information about the publication event needs to be tracked : 
 each experiment is associated with a publication date ( different from 
 the data set creation date ) and a publisher ( i.e. , the file system 
 username ) . from a publication perspective , safeguards have to be created 
 to ensure data integrity when two users try to publish an experiment 
 simultaneously .
if both users try to publish the same experiment then 
 one should be blocked to allow the other user s action to parse 
 the associated directory and generate the descriptor files .
whether 
 the target experiments are different or not , the web directory containing 
 the listing and the index of experiments should not be updated concurrently . a locking system was implemented to prevent concurrent updates . 

if somehow two users are trying to publish the same experiment folder 
 concurrently , the second user s publication action is automatically 
 canceled and the user is warned .
if two users are trying to publish 
 different experiments simultaneously , updates from the second user 
 on the experiment listing will be queued until the first users 
 publication process is over .
various unix - like commands 
 are available to manage the published experiments in ibiomes lite . 

a complete description of these commands is available on the ibiomes 
 wiki ( http://ibiomes.chpc.utah.edu/mediawiki/ ) .
here we 
 only present a summary of the most important ones : the publish ( ibiomes - lite - publish ) , 
 search ( ibiomes - lite - search ) , and clean ( ibiomes - lite - clean ) commands . to publish an experiment into ibiomes lite  i.e . 
 to parse the experiment folder and generate the associated web content  or 
 to update the web content for a given experiment
, one should use the 
 following command : ibiomes lite offers a simple search function : the user provides a 
 list of keywords that are matched against the avu values in the xml 
 document listing all the published experiments .
searches are performed 
 via the ibiomes - lite - search command , defined as remove content ( xml and html ) from ibiomes lite 
 web site .
xml descriptors at the experiment directory level are conserved , 
 and can be published again .
a critical test for ibiomes lite is to demonstrate its ability 
 to work in a variety of environments , including large computational clusters hosted by national centers and single principal investigator ( pi ) laboratories .
a successful deployment here is defined by the following criteria:1.all prerequisites 
 ( i.e. , java 7 ) are installed or can be installed on the targeted system.2.the user can install ibiomes 
 lite on the targeted system , i.e. copy the files and set up the necessary 
 environment variables , and configuration parameters.3.the user can publish data sets within 
 the targeted system and visualize the generated web site within this 
 system or an external one ( e.g. , home institution ) .
all prerequisites 
 ( i.e. , java 7 ) are installed or can be installed on the targeted system .
the user can install ibiomes 
 lite on the targeted system , i.e. copy the files and set up the necessary 
 environment variables , and configuration parameters .
the user can publish data sets within 
 the targeted system and visualize the generated web site within this 
 system or an external one ( e.g. , home institution ) . to demonstrate
these capabilities ibiomes lite was deployed 
 on various machines , such as desktop computers and laptops running 
 different operating systems and at several us national science foundation 
 funded computational centers .
ibiomes 
 lite was successfully deployed on different desktop computers and 
 laptops , running the following operating systems : linux ( fedora core 
 18 ) , windows 7 , and mac os x 10 .
ibiomes lite was also deployed at 
 the following facilities : the center for high performance computing 
 ( chpc ) at the university of utah , the national center for supercomputing 
 applications ( ncsa ) petascale computing facility , the texas advanced 
 computing center ( tacc ) , and the san diego supercomputing center ( sdsc ) . 

more detailed benchmarking on the parser was performed on blue waters 
 ( ncsa ) and stampede ( tacc ) .
the data sets descriptions and associated 
 directory parsing timings are reported in table 2 .
all the reported timings were obtained by submitting several batch 
 jobs to these two clusters , using a single computational node .
the 
 reported average and standard deviation ( std dev ) for the processing 
 times were calculated based on 10 jobs for each data set .
the value reported 
 for the  trajectory length  is the aggregated length 
 of all trajectories in the input folder . the value reported as 
total 
 processed size  is the sum of the sizes of all the md output 
 files in the directory .
dependence between log file ( amber md output ) sizes and parser execution 
 times is presented in figure 7 .
as expected , 
 the larger the aggregated size of all log files the longer the execution 
 time since md output files are the main target of the parsers .
the 
 timings presented here are only presented as a rough estimate for 
 various types of amber data sets . in our example data
sets the number 
 of topology files ( e.g. , pdb , amber parameter / topology ) is fairly 
 small compared to the number of md output files but the timings are 
 still dependent on these files .
for example if a large number of pdb 
 files representing trajectory snapshots or representative structures 
 with solvent information is present in the input directory , the md 
 output might not have as much impact on the overall parsers 
 performance . note that trajectory files ( e.g. , amber netcdf , charmm 
 dcd ) are not actually parsed
since they are typically very large ( mb - tb ) , 
 and they do not provide extra information about the topology or methods 
 used in the simulation .
the parsers seem to be faster with an average execution time 
 of 94.20 s , versus 119.4 s for the equivalent batch job .
the standard 
 deviation was higher ( 14.85 vs 2.1 s ) , which can be explained by the 
 fact that the interactive node was shared with other users running 
 various tasks .
thanks to its simplicity , 
 ibiomes lite can be deployed in limited environments where users have 
 limited permissions and no access to heavy components such as database 
 system managers .
more importantly , we showed here that ibiomes lite 
 can be used at major computational centers where big data is generated .
summarization does not require bringing back the raw data to the 
 home institution : ibiomes lite can be run at the source despite the 
 limitations due to security concerns in such infrastructures . since 
 the published summaries are static and provide a compressed view of 
 the simulation , the results of the publications can be easily copied 
 to a new location for rendering via the web or simply to centralize 
 the summaries from different computing centers at a single location . 

scripts could be created to automate this process , as well as to regenerate 
 the summaries to make sure that they are up to date with the associated 
 raw data . since the publication process is performed via a command 
 line interface , the ibiomes lite summarization step
can be added to 
 a regular simulation job description when running in a cluster .
another 
 alternative when targeting data hosted at a computational center is 
 to run the publication process via an interactive session .
for very 
 large data sets with thousands of files the parsers might take over 
 half an hour to go through all the files . running such tasks on the 
 login nodes of a cluster
is usually not recommended by the hosting 
 institution as other users might observe a dramatic slowdown when 
 trying to access their data or submit a job .
most computing centers 
 allow users to request interactive sessions , which are usually provided 
 within minutes , unlike batch job submissions which might stay queued 
 for hours or days .
data publication is done through a simple 
 command - line interface that controls the software - specific parsers 
 to build the summaries .
the user only needs to specify the input folder 
 and the software package that was used to generate the data to create 
 summaries that can be exposed on the web .
the specification of the 
 software package version is not necessary since the parsing process 
 favors output / log files over input files to avoid the use of default 
 values that might change between versions .
moreover , several parsers 
 already include parsing functions for different format versions where 
 keywords or structure might change ( e.g. , amber md output , sdf file ) .
one of the current limitations of ibiomes lite is that only simple 
 or common directory structures will provide an accurate representation 
 of the simulation workflow . since there is no input from the user 
 regarding the file tree structure certain assumptions have to be made 
 about the workflow and the directory structure to build a representation 
 of the workflow .
an example of constraint that is currently imposed 
 at the workflow level is the sequence minimization  heating  equilibration 
production 
 that has to be followed by all md experiments ( with each component 
 being optional ) .
an example of directory structure assumption is for 
 multicopy simulations , where each copy should be in a different subfolder . 

therefore , our current parsers and protocol model builders will not 
 be adapted to all types of experiments and directory structures , but 
 this limitation should be circumvented in the future by including 
 more configurable rules based on naming conventions , file content , 
 computational methods , and textual descriptions to enable an accurate 
 representation of the experiment protocol with minimal input from 
 the user . although most demonstrations for ibiomes lite have been 
 done through the publication of amber - generated data sets , the parsers 
 support data sets generated by other md engines such as gromacs and 
 namd .
the development of the data model and parsers has been guided 
 by our experience with amber but the support for other software packages 
 has allowed us to avoid software - specific data representations and 
 parsing rules .
parsers for files associated with md 
 engines that use static configuration files ( versus script - based input ) 
 can be implemented with minimal effort if the formats are well - defined 
 and data is available to the developers for testing .
parsers for qm 
 data sets ( e.g. , gaussian , nwchem ) were also developed to demonstrate 
 the generalizability of the data model and the web interface .
although 
 nowadays md is a de facto standard approach to run biomolecular simulations , 
 qm can not be excluded from this realm . first md can be dependent on 
 qm when new force field parameters have to be created for nonstandard 
 residues or small ligands .
then qm has promises in the study of biomolecules , 
 at least for small systems .
moreover , 
 we note that we spent considerable initial effort on generating qm 
 data parsers for the prototype ibiomes repository implementation . unfortunately , due to serious limitations and 
 restrictions on the release or publication of raw gaussian output 
 by gaussian , inc . , open
however , use of the functional parsers 
 in ibiomes lite provides a simple way to summarize and track these 
 data sets without having to provide access to the raw data . the inclusion of less common or more complex methods in the data 
 model such as replica - exchange md , qm / mm , and quantum md has proven 
 the decomposition of parameters into sets of method - specific parameters 
 to be fairly generalizable .
these methods are currently supported 
 only for the amber software package , which enables qm / mm md , semiempirical born  oppenheimer md ( sebomd ) , and multidimensional replica - exchange md .
a current list of the file formats and computational 
 methods supported by the parsers is available on the wiki at http://ibiomes.chpc.utah.edu/mediawiki/index.php/ibiomes_parsers .
the initial rationale behind the development of ibiomes lite was 
 the need for a simple tool that would be able to mimic the features 
 offered by the ibiomes repository in a 
 nondistributed environment controlled by a strict security policy . 

this has been a successful attempt as ibiomes lite can create rich 
 summaries with graphical rendering ( 3d structures , data plots ) and 
 basic search capabilities .
one advantage of ibiomes lite over the 
 distributed repository is the ability to provide a detailed and logical 
 description of the computational experiment protocol via xml transformation . 

the current avu model used by the ibiomes repository to index data 
 is very flexible but relationships between data elements can not be 
 described .
the addition of a relational database to the repository 
 architecture to keep track of the experiment workflow is part of our 
 effort to provide a generic infrastructure for biomolecular simulation 
 data sharing .
one of the major limitations 
 of ibiomes lite , by design , is the fact that the web interface does 
 not provide access to the raw data .
instead it should be seen as a way for researchers 
 to summarize data at the source for progress tracking and result sharing . 

our end - goal is to enable the integration of ibiomes lite summaries 
 into the ibiomes repository .
researchers would be able to summarize 
 their data within a computational center that does not support irods - based 
 data transfers , and publish the summary into the ibiomes repository . 

the raw data would not be available for download but users would be 
 able to search for both full experiments data sets and experiment 
 summaries via a single entry point : the repository web portal .
this 
 effort is currently supported by a common data model , a common set 
 of parsers , and similar web interfaces .
ibiomes 
 lite provides the means for researchers to track and share biomolecular 
 simulation data sets via automatic summarization .
summaries are supported 
 by a software - independent data model that can describe quantum chemistry , 
 classical and quantum md , remd , and qm / mm data sets .
thanks to a simple 
 design , the tool can be easily installed on machines where users have 
 limited privileges , whether they are hosted locally or at a national 
 computing center .
ibiomes lite is an open - source project and is part 
 of the ibiomes distribution , available at https://github.com/jcvthibault/ibiomes .
 as 
 the amount of data generated by biomolecular simulations dramatically 
 increases , new tools need to be developed to help manage this data 
 at the individual investigator or small research group level . in this 
 paper , we introduce ibiomes lite , a lightweight tool for biomolecular 
 simulation data indexing and summarization . the main goal of ibiomes 
 lite is to provide a simple interface to summarize computational experiments 
 in a setting where the user might have limited privileges and limited 
 access to it resources . 
 a command - line interface allows the user to 
 summarize , publish , and search local simulation data sets 
 . published 
 data sets are accessible via static hypertext markup language ( html ) 
 pages that summarize the simulation protocols and also display data 
 analysis graphically . 
 the publication process is customized via extensible 
 markup language ( xml ) descriptors while the html summary template 
 is customized through extensible stylesheet language ( xsl ) . 
 ibiomes 
 lite was tested on different platforms and at several national computing 
 centers using various data sets generated through classical and quantum 
 molecular dynamics , quantum chemistry , and qm / mm . 
 the associated parsers 
 currently support amber , gromacs , gaussian , and nwchem data set publication . 
 
 the code is available at https://github.com/jcvthibault/ibiomes . 
Background
Design
Implementation
Tests in Limited Settings
Discussion
Conclusion