DistSim - Revision history

Uhermann: /* Installation */

2008-02-25T17:01:19Z

Installation

← Older revision		Revision as of 17:01, 25 February 2008
Line 12:		Line 12:

	===Installation===		===Installation===
	In order to use DistSim you should set up a MySQL database. I won't go into great detail here, as there are other guides for that. You can execute the SQL script "~~tabellen~~" in the wrapper directory to create the necessary tables:		In order to use DistSim you should set up a MySQL database. I won't go into great detail here, as there are other guides for that. You can execute the SQL script "schema.sql" in the wrapper/res directory to create the necessary tables:

	mysql> source wrapper/~~tabellen~~		mysql> source wrapper/res/schema.sql

	Now you need to provide user accounts for various roles. One role is used for the configuration client, which needs write access to the configuration tables. Another one is used by the wrapper which needs write access to the results tables. You can reconfigure the database connection later, though. So if you just want to test the framework without caring much for security a simple		Now you need to provide user accounts for various roles. One role is used for the configuration client, which needs write access to the configuration tables. Another one is used by the wrapper which needs write access to the results tables. You can reconfigure the database connection later, though. So if you just want to test the framework without caring much for security a simple

Uhermann: /* defining parameters */

2008-02-25T16:55:04Z

defining parameters

← Older revision		Revision as of 16:55, 25 February 2008
Line 91:		Line 91:
	par1: 1 OR 2 OR 5.5 OR 11		par1: 1 OR 2 OR 5.5 OR 11
	par2: 0 TO 20 BY par1		par2: 0 TO 20 BY par1
	The evaluation of such a range uses the lower bound as first actual parameter for a simulation. Then it increments by the step value until the result further from the upper bound than the previous value. So if ''par1'' is 11 in the previous example, par2 will be 0, 11 and 22. All these parameters can also be referenced in the command line for the study by enclosing them in dollar signs. For example		The evaluation of such a range uses the lower bound as first actual parameter for a simulation. Then it increments by the step value until the result is further from the upper bound than the previous value. So if ''par1'' is 11 in the previous example, par2 will be 0, 11 and 22. All these parameters can also be referenced in the command line for the study by enclosing them in dollar signs. For example
	ant -f baum/jist-swans-1.0.6/build.xml $target$		ant -f baum/jist-swans-1.0.6/build.xml $target$
	would call ant with a target depending on the actual simulation. $target$ would be substituted by the value of the parameter ''target'' when the simulation is started. As our example simulation doesn't need any configuration, we only need to create one group and one "dummy" list parameter. Then one value should be assigned to the parameter so that one simulation is generated.		would call ant with a target depending on the actual simulation. $target$ would be substituted by the value of the parameter ''target'' when the simulation is started. As our example simulation doesn't need any configuration, we only need to create one group and one "dummy" list parameter. Then one value should be assigned to the parameter so that one simulation is generated.

Uhermann: /* using the configuration library */

2008-02-25T16:51:37Z

using the configuration library

← Older revision		Revision as of 16:51, 25 February 2008
Line 101:		Line 101:
	===using the configuration library===		===using the configuration library===
	[[Image:class-hierarchy.png\|thumb\|class structure]]		[[Image:class-hierarchy.png\|thumb\|class structure]]
	The configuration library is the back end of the client GUI and performs all actual functions. It can be found in the Java package client.data. The configuration is represented as a tree of ''~~BdBackedData~~'' objects. These objects can be loaded from, updated in and saved to the database and they contain ''Saveable'' child objects which are affected by certain changes in their parent object and may again have children. You can ''add'' child objects to potential parents and ''remove'' them again. ''commit'' Applies these changes to the database. ''loadFromDb'' loads a ''DbBackedData'' object with certain characteristics from the database. This method also loads all direct children of that object but not its grandchildren. For example loading a study will load all groups for that study, but not its simulations. Like this the potentially long delay caused by loading all simulation parameters from the database into memory is avoided. ''getDependent'' and certain constructors perform the same function. Details are explained in the javadoc comments. In contrast, methods '''writing''' to the database perform their function recursively over the whole object tree. The rationale behind that is that once the data is loaded we know that the machine can handle it and we expect changes to affect all ancestors of an object. ''Group'' and ''Study'' additionally contain subobjects. Calls to the superobjects are passed on to the subobjects. For example if a ''Study'' is loaded from the database its ''StudyPackages'' are loaded, too.		The configuration library is the back end of the client GUI and performs all actual functions. It can be found in the Java package client.data. The configuration is represented as a tree of ''DbBackedData'' objects. These objects can be loaded from, updated in and saved to the database and they contain ''Saveable'' child objects which are affected by certain changes in their parent object and may again have children. You can ''add'' child objects to potential parents and ''remove'' them again. ''commit'' Applies these changes to the database. ''loadFromDb'' loads a ''DbBackedData'' object with certain characteristics from the database. This method also loads all direct children of that object but not its grandchildren. For example loading a study will load all groups for that study, but not its simulations. Like this the potentially long delay caused by loading all simulation parameters from the database into memory is avoided. ''getDependent'' and certain constructors perform the same function. Details are explained in the javadoc comments. In contrast, methods '''writing''' to the database perform their function recursively over the whole object tree. The rationale behind that is that once the data is loaded we know that the machine can handle it and we expect changes to affect all ancestors of an object. ''Group'' and ''Study'' additionally contain subobjects. Calls to the superobjects are passed on to the subobjects. For example if a ''Study'' is loaded from the database its ''StudyPackages'' are loaded, too.

	The restrictions on writing previously defined simulations aren't enforced in the library. You can actually delete existing simulations from the database, provided you don't violate a foreign key constraint. Also it's important to remember that the wrapper will execute any studies that are present in the database and not yet assigned to another instance of the wrapper. Thus, it is important to fully define all parameters of a study before committing it to the database. Writing operations as well as the wrapper's reading operation are secured by transactions, so you can write a whole study at once without caring about dirty reads.		The restrictions on writing previously defined simulations aren't enforced in the library. You can actually delete existing simulations from the database, provided you don't violate a foreign key constraint. Also it's important to remember that the wrapper will execute any studies that are present in the database and not yet assigned to another instance of the wrapper. Thus, it is important to fully define all parameters of a study before committing it to the database. Writing operations as well as the wrapper's reading operation are secured by transactions, so you can write a whole study at once without caring about dirty reads.

Uhermann at 11:34, 19 February 2007

2007-02-19T11:34:56Z

← Older revision		Revision as of 11:34, 19 February 2007
Line 101:		Line 101:
	===using the configuration library===		===using the configuration library===
	[[Image:class-hierarchy.png\|thumb\|class structure]]		[[Image:class-hierarchy.png\|thumb\|class structure]]
	The configuration library is the ~~backend~~ of the client GUI and performs all actual functions. It can be found in the Java package client.data. The configuration is represented as a tree of ''BdBackedData'' objects. These objects can be loaded from, updated in and saved to the database and they contain ''Saveable'' child objects which are affected by certain changes in their parent object and may again have children. You can ''add'' child objects to potential parents and ''remove'' them again. ''commit'' Applies these changes to the database. ''loadFromDb'' loads a ''DbBackedData'' object with certain characteristics from the database. This method also loads all direct children of that object but not its grandchildren. For example loading a study will load all groups for that study, but not its simulations. Like this the potentially long delay caused by loading all simulation parameters from the database into memory is avoided. ''getDependent'' and certain constructors perform the same function. Details are explained in the javadoc comments. In contrast, methods '''writing''' to the database perform their function recursively over the whole object tree. The rationale behind that is that once the data is loaded we know that the machine can handle it and we expect changes to affect all ancestors of an object. ''Group'' and ''Study'' additionally contain subobjects. Calls to the superobjects are passed on to the subobjects. For example if a ''Study'' is loaded from the database its ''StudyPackages'' are loaded, too.		The configuration library is the back end of the client GUI and performs all actual functions. It can be found in the Java package client.data. The configuration is represented as a tree of ''BdBackedData'' objects. These objects can be loaded from, updated in and saved to the database and they contain ''Saveable'' child objects which are affected by certain changes in their parent object and may again have children. You can ''add'' child objects to potential parents and ''remove'' them again. ''commit'' Applies these changes to the database. ''loadFromDb'' loads a ''DbBackedData'' object with certain characteristics from the database. This method also loads all direct children of that object but not its grandchildren. For example loading a study will load all groups for that study, but not its simulations. Like this the potentially long delay caused by loading all simulation parameters from the database into memory is avoided. ''getDependent'' and certain constructors perform the same function. Details are explained in the javadoc comments. In contrast, methods '''writing''' to the database perform their function recursively over the whole object tree. The rationale behind that is that once the data is loaded we know that the machine can handle it and we expect changes to affect all ancestors of an object. ''Group'' and ''Study'' additionally contain subobjects. Calls to the superobjects are passed on to the subobjects. For example if a ''Study'' is loaded from the database its ''StudyPackages'' are loaded, too.

	The restrictions on writing previously defined simulations aren't enforced in the library. You can actually delete existing simulations from the database, provided you don't violate a foreign key constraint. Also it's important to remember that the wrapper will execute any studies that are present in the database and not yet assigned to another instance of the wrapper. Thus, it is important to fully define all parameters of a study before committing it to the database. Writing operations as well as the wrapper's reading operation are secured by transactions, so you can write a whole study at once without caring about dirty reads.		The restrictions on writing previously defined simulations aren't enforced in the library. You can actually delete existing simulations from the database, provided you don't violate a foreign key constraint. Also it's important to remember that the wrapper will execute any studies that are present in the database and not yet assigned to another instance of the wrapper. Thus, it is important to fully define all parameters of a study before committing it to the database. Writing operations as well as the wrapper's reading operation are secured by transactions, so you can write a whole study at once without caring about dirty reads.

Uhermann at 11:09, 19 February 2007

2007-02-19T11:09:18Z

← Older revision		Revision as of 11:09, 19 February 2007
Line 8:		Line 8:

	* The configuration library is also the back end for the '''configuration client''', a swing GUI for defining parameters of simulations.		* The configuration library is also the back end for the '''configuration client''', a swing GUI for defining parameters of simulations.

	==HOWTO==

	The following guide shows how to set up a simple simulation and touches various aspects of DistSim. It is intended to be used as a starting point for more sophisticated setups.		The following guide shows how to set up a simple simulation and touches various aspects of DistSim. It is intended to be used as a starting point for more sophisticated setups.

Uhermann: /* using the configuration library */

2007-02-19T10:58:03Z

using the configuration library

← Older revision		Revision as of 10:58, 19 February 2007
Line 102:		Line 102:

	===using the configuration library===		===using the configuration library===
	[[Image:class-hierarchy.png\|thumb\|class ~~hierarchy~~]]		[[Image:class-hierarchy.png\|thumb\|class structure]]
	The configuration library is the backend of the client GUI and performs all actual functions. The configuration is represented as a tree of ''BdBackedData'' objects. These objects can be loaded from, updated in and saved to the database and they contain ''Saveable'' child objects which are affected by certain changes in their parent object and may again have children. You can ''add'' child objects to potential parents and ''remove'' them again. ''commit'' Applies these changes to the database. ''loadFromDb'' loads a ''DbBackedData'' object with certain characteristics from the database. This method also loads all direct children of that object but not its grandchildren. For example loading a study will load all groups for that study, but not its simulations. Like this the potentially long delay caused by loading all simulation parameters from the database into memory is avoided. ''getDependent'' and certain constructors perform the same function. Details are explained in the javadoc comments. In contrast, methods '''writing''' to the database perform their function recursively over the whole object tree. The rationale behind that is that once the data is loaded we know that the machine can handle it and we expect changes to affect all ancestors of an object.		The configuration library is the backend of the client GUI and performs all actual functions. It can be found in the Java package client.data. The configuration is represented as a tree of ''BdBackedData'' objects. These objects can be loaded from, updated in and saved to the database and they contain ''Saveable'' child objects which are affected by certain changes in their parent object and may again have children. You can ''add'' child objects to potential parents and ''remove'' them again. ''commit'' Applies these changes to the database. ''loadFromDb'' loads a ''DbBackedData'' object with certain characteristics from the database. This method also loads all direct children of that object but not its grandchildren. For example loading a study will load all groups for that study, but not its simulations. Like this the potentially long delay caused by loading all simulation parameters from the database into memory is avoided. ''getDependent'' and certain constructors perform the same function. Details are explained in the javadoc comments. In contrast, methods '''writing''' to the database perform their function recursively over the whole object tree. The rationale behind that is that once the data is loaded we know that the machine can handle it and we expect changes to affect all ancestors of an object. ''Group'' and ''Study'' additionally contain subobjects. Calls to the superobjects are passed on to the subobjects. For example if a ''Study'' is loaded from the database its ''StudyPackages'' are loaded, too.

			The restrictions on writing previously defined simulations aren't enforced in the library. You can actually delete existing simulations from the database, provided you don't violate a foreign key constraint. Also it's important to remember that the wrapper will execute any studies that are present in the database and not yet assigned to another instance of the wrapper. Thus, it is important to fully define all parameters of a study before committing it to the database. Writing operations as well as the wrapper's reading operation are secured by transactions, so you can write a whole study at once without caring about dirty reads.

Uhermann: /* using the configuration library */

2007-02-19T10:17:29Z

using the configuration library

← Older revision		Revision as of 10:17, 19 February 2007
Line 103:		Line 103:
	===using the configuration library===		===using the configuration library===
	[[Image:class-hierarchy.png\|thumb\|class hierarchy]]		[[Image:class-hierarchy.png\|thumb\|class hierarchy]]
	The configuration library is the backend of the client GUI and performs all actual functions. The configuration is represented as a tree of ''BdBackedData'' objects. These objects can be loaded from and saved to the database and they contain ''Saveable'' ~~subobjects~~ which are affected by certain changes in their parent object and may again have ~~subobjects~~.		The configuration library is the backend of the client GUI and performs all actual functions. The configuration is represented as a tree of ''BdBackedData'' objects. These objects can be loaded from, updated in and saved to the database and they contain ''Saveable'' child objects which are affected by certain changes in their parent object and may again have children. You can ''add'' child objects to potential parents and ''remove'' them again. ''commit'' Applies these changes to the database. ''loadFromDb'' loads a ''DbBackedData'' object with certain characteristics from the database. This method also loads all direct children of that object but not its grandchildren. For example loading a study will load all groups for that study, but not its simulations. Like this the potentially long delay caused by loading all simulation parameters from the database into memory is avoided. ''getDependent'' and certain constructors perform the same function. Details are explained in the javadoc comments. In contrast, methods '''writing''' to the database perform their function recursively over the whole object tree. The rationale behind that is that once the data is loaded we know that the machine can handle it and we expect changes to affect all ancestors of an object.

Uhermann at 09:41, 19 February 2007

2007-02-19T09:41:22Z

← Older revision		Revision as of 09:41, 19 February 2007
Line 100:		Line 100:

	When you are done with parameter definition, you can save and generate simulations from the group you have created. This will switch you to the monitoring tab. You may need to refresh the table in order to see the newly created simulation. Now the wrapper should find the simulation and execute it. After this is done, you can view the result in the evaluation tab.		When you are done with parameter definition, you can save and generate simulations from the group you have created. This will switch you to the monitoring tab. You may need to refresh the table in order to see the newly created simulation. Now the wrapper should find the simulation and execute it. After this is done, you can view the result in the evaluation tab.

			===using the configuration library===
			[[Image:class-hierarchy.png\|thumb\|class hierarchy]]
			The configuration library is the backend of the client GUI and performs all actual functions. The configuration is represented as a tree of ''BdBackedData'' objects. These objects can be loaded from and saved to the database and they contain ''Saveable'' subobjects which are affected by certain changes in their parent object and may again have subobjects.

Uhermann at 09:17, 19 February 2007

2007-02-19T09:17:09Z

← Older revision		Revision as of 09:17, 19 February 2007
Line 83:		Line 83:

	Again, this only works with ant 1.6.5 or newer. When you have done all that, you can ''save'' your changes and switch to the next tab. If you save too early you won't be able to change the command or the packages as the client doesn't let you overwrite existing simulations in order to prevent a loss of association between parameters and results of simulations.		Again, this only works with ant 1.6.5 or newer. When you have done all that, you can ''save'' your changes and switch to the next tab. If you save too early you won't be able to change the command or the packages as the client doesn't let you overwrite existing simulations in order to prevent a loss of association between parameters and results of simulations.

			===defining parameters===
			The same principle applies to parameter definition. The only exception is that you can define '''additional''' simulations even after saving the first time. The tables in the simulation tab allow you to define parameters in two different ways. Either you define a list of literals or you define a range of expressions. Literals can be numerical or strings, expressions are always numerical. Each column of the table represents one group of simulations which contains simulations for each possible combination of the specified parameters. For example, if you define parameter ''par1'' to be ''a OR b'' and ''par2'' to be ''5 TO 10 BY 5''. The result will be four simulations:
			sim1: a, 5
			sim2: a, 10
			sim3: b, 5
			sim4: b, 10
			You can use arbitrary mathematical expressions and reference other parameters, literals or expressions, here. For example the following would be valid:
			par1: 1 OR 2 OR 5.5 OR 11
			par2: 0 TO 20 BY par1
			The evaluation of such a range uses the lower bound as first actual parameter for a simulation. Then it increments by the step value until the result further from the upper bound than the previous value. So if ''par1'' is 11 in the previous example, par2 will be 0, 11 and 22. All these parameters can also be referenced in the command line for the study by enclosing them in dollar signs. For example
			ant -f baum/jist-swans-1.0.6/build.xml $target$
			would call ant with a target depending on the actual simulation. $target$ would be substituted by the value of the parameter ''target'' when the simulation is started. As our example simulation doesn't need any configuration, we only need to create one group and one "dummy" list parameter. Then one value should be assigned to the parameter so that one simulation is generated.

			In the input and output files tables you can specify additional configuration and results files that should be stored in the database. We don't need them for now.

			When you are done with parameter definition, you can save and generate simulations from the group you have created. This will switch you to the monitoring tab. You may need to refresh the table in order to see the newly created simulation. Now the wrapper should find the simulation and execute it. After this is done, you can view the result in the evaluation tab.

Uhermann: /* defining a study */

2007-02-19T08:50:30Z

defining a study

← Older revision		Revision as of 08:50, 19 February 2007
Line 79:		Line 79:
	Now you can add the package to the study and define the path where it should be unpacked. You should pick a '''relative''' and '''unique''' path here because it will be deleted after the simulation. Each instance of the wrapper is running in its own directory, so if as long as a relative path is chosen here you can operate multiple wrappers in the same file system. You can actually place multiple packages in the same directory as they are all deleted after the simulation anyway. You shouldn't use the directory for anything else, though.		Now you can add the package to the study and define the path where it should be unpacked. You should pick a '''relative''' and '''unique''' path here because it will be deleted after the simulation. Each instance of the wrapper is running in its own directory, so if as long as a relative path is chosen here you can operate multiple wrappers in the same file system. You can actually place multiple packages in the same directory as they are all deleted after the simulation anyway. You shouldn't use the directory for anything else, though.

	If you chose the path ''baum'' for our test package you can now specify the command to be executed in order to start the actual simulation. It would be		If you chose the path ''baum'' for our test package you can now specify the command to be executed in order to start the actual simulation. You do that by editing the respective cell in the studies table. The command would be
	ant -f baum/jist-swans-1.0.6/build.xml run		ant -f baum/jist-swans-1.0.6/build.xml run

			Again, this only works with ant 1.6.5 or newer. When you have done all that, you can ''save'' your changes and switch to the next tab. If you save too early you won't be able to change the command or the packages as the client doesn't let you overwrite existing simulations in order to prevent a loss of association between parameters and results of simulations.
	Again, this only works with ant 1.6.5 or newer.