search

xjiang4 / ellipsoids

Automatically exported from code.google.com/p/ellipsoids
Other
0 stars 1 forks source link

make Ellipsoidal toolbox calculate ellipsoidal tubes in a parallel manner #131

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
The task is to make Ellipsoidal toolbox calculate ellipsoidal tubes in a 
parallel manner. There the following places
where the toolbox calculates the ellipsoidal tubes:

1) elltool.reach.ReachContinuous and elltool.reach.ReachDiscrete classes

a) In elltool.reach.AReach:

evolveApprox

            for il0Num = l0VecNum: -1 : 1
                probDynObj = self.getProbDynamics(atStrCMat, ...
                    btStrCMat, ptStrCMat, ptStrCVec, ctStrCMat, ...
                    qtStrCMat, qtStrCVec, x0MatArray(:, :, il0Num), ...
                    x0VecMat(:, il0Num), newTimeVec, self.relTol, ...
                    isDisturbance);
                ellTubeRelVec{il0Num} = self.makeEllTubeRel(...
                    probDynObj, l0Mat(:, il0Num), ...
                    newTimeVec, isDisturbance, self.relTol, approxType);
                ellTubeRelList{il0Num} = ...
                    ellTubeRelVec{il0Num}.getTuplesFilteredBy(...
                    APPROX_TYPE, approxType).getData();
            end

in refine (line 1320):

            for iLinSys = 2 : sysTimeVecLenght
                reachSetObj = ...
                    reachSetObj.evolve(...
                    getNewTime(outReachObj.switchSysTimeVec,...
                    outReachObj.isBackward,iLinSys),...
                    outReachObj.linSysCVec{iLinSys});
            end

b) In ReachContinuous/ReachDiscrete

in internalMakeEllTubeRel methods that are different for both ReachContinuous 
and ReachDiscrete

in ReachContinuous this method calls

gras.ellapx.lreachuncert.ExtIntEllApxBuilder
gras.ellapx.gen.EllApxCollectionBuilder
gras.ellapx.lreachplain.IntEllApxBuilder

constructors that build ellipsoidal tubes

while in ReachDiscrete they are built in

in a loop on line 133

        for iTube = 1:nTubes

2) In

gras.ellapx.lreachuncert.ExtIntEllApxBuilder (line 174)

(for building ellipsoidal tubes for both external and internal approximations 
with uncertainty)

gras.ellapx.lreachplain.ATightEllApxBuilder (line 45)

(for building ellipsoidal tubes for both external and internal approximations 
without uncertainty)

The idea of calculating the tubes in parallel is based on using 
modgen.pcalc.auxdfeval function
(see the tests for this function in modgen.pcalc.test.mlunit_test_auxdfeval)

This function has "clusterSize" property which defines how many parallel matlab 
processes can be used.

We need to introduce a patch to Ellipsoidal matlab configurations ( you can 
read about them at

http://code.google.com/p/ellipsoids/wiki/Toolbox_configuration_management ) 
that introduces

a new parallelCompProps section and nMaxParProcess property.

Also we need to create a new static class in elltool.pcalc.ParCalculator that 
upon construction 
read value of nMaxParProcess property using 
elltool.conf.Properties.getConfRepoMgr.getParam('parallelCompProps.nMaxParProces
s')
and provides eval method that internally just calls modgen.pcalc.auxdfeval with 
clusterSize=nMaxParProcess. 

Everywhere in the classes listed above in 1) and 2) one should use the 
following construct:

-----------
pCalc=elltool.pcalc.ParCalculator();
tubeList=pCalc.eval(fCalcTube,num2cell(1:nGoodDirs))

where fCalcTube is defined as 

function fCalcTube(iTube)

%calculate tube # iTube

end

-----------

instead of the loop

------

for iTube=1:nGoodDir

%calculate tube # iTube and put it into tubeList{iTube}

end 

------

Once all this is implemented one needs to run the existing tests, epspecially 
from elltool.reach.test 
and gras.ellapx.uncertcalc.test packages.

Btw - the default value of nMaxParProcess should be 1;

The functionality that elltool.conf.ConfRepoMgr class provides can be described 
as follows
a.    Providing an access to a set of configurations stored on disk in form of 
plain xml files
(\products\+elltool\+conf\confrepo). “confrepo” folder contains a set of
subfolders for each computer where a configuration is opened + a special 
_templates folder from
which the configurations are deployed into the computer-specific folders. You 
can experiment
with this by typing elltool.editconf(‘default’) to deploy a configuration 
with the
name “default” from _template folder and place it into a separate subfolder 
of
products\+elltool\+conf\confrepo folder next to _templates folder. Once the 
configuration is
deployed it is opened it Matlab editor so that you can edit it. Also you can 
copy configurations
 (run elltool.copyconf(‘default’,’myconf’)) and list all available configurations (elltool.listconf).
AdaptiveConfRepoManager class automatically selects a specific subfolder of
products\+elltool\+conf\confrepo depending on a computer name.
This way different users can commit their configurations into svn avoiding 
conflicts. 

Please note that these 3 utilities located in elltool package are just some 
examples of
how a functionality of AdaptiveConfRepoManager class can be used.

b.    Providing a simple versioning of the configurations. Along with keeping 
track of
the configurations for different machines ConfRepoMgr class also keeps track of 
configuration
versions. This is necessary to update configurations created by different users.
Example: for instance Person A creates a configuration ‘conf1’ on his 
machine ‘comp1’.
The configuration will be stored in 
products/+elltool/+conf/confrepo/comp1/conf1.xml file.
Then Person B creates the new configuration conf1 on machine comp2. It will be 
stored in
 products/+elltool/+conf/confrepo/comp2/conf1.xml.
Now Person B decides to add a new configuration parameter “paramX” so he
types elltool.editconf(‘conf1’) edits his configurations by adding a 
parameter
and saves the changes. The problem now is that this changes
only products/+elltool/+conf/confrepo/comp2/conf1.xml but
products/+elltool/+conf/confrepo/comp1/conf1.xml remains unchanged. When person 
A wakes
up next day, updates svn and tries to run the toolbox for his configuration he 
gets a
failure because products/+elltool/+conf/confrepo/comp1/conf1.xml doesn’t 
contain parameter “paramX”.

ConfRepoMgr has a solution for this by having a reference to another class – 
ConfPatchRepo.
This class keeps track of versions via patches. When ConfRepoMGr is 
instantiated it
can receive a reference to an instance of ConfPathRepo class via a constructor.
The constructor is designed as follows:

 function self=ConfRepoMgr(varargin)
      self=self@modgen.configuration.AdaptiveConfRepoManager(varargin{:});
       confPatchRepo=elltool.conf.ConfPatchRepo();
            self.setConfPatchRepo(confPatchRepo);
 end

As you can see it creates an instance of ConfPathRepo class and then passes it 
into the
constructor of super-class that implements all the functionality.

ConfPatchRepo is a simple class that keeps patches in form of class methods, see
products\+elltool\+conf\@ConfPatchRepo folder. 

elltool.conf.ConfPatchRepo class has a banch of patch methods that are designed 
to upgrade the configuration up to the next version
The version number is made to a part of patch method name, here is an example:

function SInput = patch_004_add_regTol(~, SInput)
SInput.regTol = 1e-5;
end

Each patch is represented as function suffixed with a number corresponding to a 
revision.

 SInput is a structure formed from a parsed xml (products/+elltool/+conf/confrepo/comp1/conf1.xml from
the example above for instance).

ConfRepoManager uses the functions from package modgen.xml to parse xml into
 structures back and forward.  For now you do not need to worry about versions tool much,
just create ConfPathRepo class and an empty method as indicated above. You your 
configurations will
have version 1 which will be indicated in xml header like this
<?xml version="1.0"?>
<root version="1" xml_tb_version="2.0" type="struct" >

There are the unitlity functions like

 elltool.editconf, elltool.copyconf, elltool.listconf that perform copying, editing and listing the configurations.

Original issue reported on code.google.com by heartofm...@gmail.com on 19 Sep 2013 at 7:06

GoogleCodeExporter commented 8 years ago

Original comment by heartofm...@gmail.com on 19 Sep 2013 at 7:06

GoogleCodeExporter commented 8 years ago

Original comment by zilonova.e.m@gmail.com on 26 Nov 2013 at 10:41

GoogleCodeExporter commented 8 years ago

Original comment by heartofm...@gmail.com on 29 Nov 2013 at 12:51

GoogleCodeExporter commented 8 years ago

Original comment by zilonova.e.m@gmail.com on 30 Nov 2013 at 8:34

GoogleCodeExporter commented 8 years ago

Original comment by heartofm...@gmail.com on 4 Dec 2013 at 2:24

GoogleCodeExporter commented 8 years ago

Original comment by zilonova.e.m@gmail.com on 5 Dec 2013 at 9:21

GoogleCodeExporter commented 8 years ago

Original comment by heartofm...@gmail.com on 6 Dec 2013 at 3:40

GoogleCodeExporter commented 8 years ago 
Running the tests on the server produces an error which cannot be reproduced on 
a separate machine:

--------CRITICAL ERROR--------
<identifier>:  MATLAB:UndefinedFunction
<message>:  No method 'modgen.pcalc.auxdfeval' with matching signature found.
<cause>:  cell
<stack>:  struct
   (1)-------------
      <file>:  C:/SVN_Local/EllTrunk/lib/mlunitext/+mlunitext/+pcalc/auxdfeval.m
      <name>:  auxdfeval
      <line>:  12
   (2)-------------
      <file>:  C:/SVN_Local/EllTrunk/lib/mlunitext/+mlunitext/test_suite.m
      <name>:  test_suite.run
      <line>:  411
   (3)-------------
      <file>:  C:/SVN_Local/EllTrunk/lib/mlunitext/+mlunitext/text_test_runner.m
      <name>:  text_test_runner.run
      <line>:  76
   (4)-------------
      <file>:  C:/SVN_Local/EllTrunk/products/+elltool/+reach/+test/run_discr_tests.m
      <name>:  run_discr_tests
      <line>:  131
   (5)-------------
      <file>:  C:/SVN_Local/EllTrunk/products/+elltool/+reach/+test/run_tests.m
      <name>:  run_tests
      <line>:  2
   (6)-------------
      <file>:  C:/SVN_Local/EllTrunk/products/+elltool/+test/run_tests.m
      <name>:  run_tests
      <line>:  8
   (7)-------------
      <file>:  C:/SVN_Local/EllTrunk/lib/mlunitext/+mlunitext/RemoteTestRunner.m
      <name>:  RemoteTestRunner.runTestPack
      <line>:  19
   (8)-------------
      <file>:  C:/SVN_Local/EllTrunk/lib/+modgen/+mlunit/run_tests_remotely.m
      <name>:  run_tests_remotely
      <line>:  29
   (9)-------------
      <file>:  C:/SVN_Local/EllTrunk/products/+elltool/+test/run_tests_remotely.m
      <name>:  run_tests_remotely
      <line>:  26
   -------------
-------------

The decision is to consider this ticket to be completed by Ekaterina Zilonov. 
Peter Gagarinov will investigate the problem at the end of December and 
reintegrate the branch by himself.

Original comment by heartofm...@gmail.com on 9 Dec 2013 at 3:06